Voir la source de IPv6

{{à actualiser|date=28 septembre 2023}}
L''''IPv6''' ({{langue|en|''Internet Protocol version 6''}}) est un [[protocole réseau]] [[Transmission en mode sans connexion|sans connexion]] de la [[couche réseau|couche 3]] du [[modèle OSI]] (Open Systems Interconnection).

IPv6 est l'aboutissement des travaux menés au sein de l'[[Internet Engineering Task Force|IETF]] au cours des années 1990 pour succéder à [[IPv4]] et ses spécifications ont été finalisées dans la {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}} en {{date-|décembre 1998}}. IPv6 a été standardisé dans la {{RFC|8200|titre=Internet Protocol, Version 6 (IPv6) Specification, Request for Comments 8200|date=juillet 2017}} en {{date-|juillet 2017}}.

Grâce à des adresses de {{nobr|128 bits}} au lieu de {{nobr|32 bits}}, IPv6 dispose d'un espace d'adressage bien plus important qu'IPv4 (plus de 340 [[sextillion]]s, ou <math>3,4\times10^{38}</math>, soit près de {{unité|7.9|e=28}} de fois plus que le précédent). Cette quantité d'adresses considérable permet une plus grande flexibilité dans l'attribution des adresses et une meilleure agrégation des routes dans la [[default-free zone|table de routage d'Internet]]. La [[Network address translation|traduction d'adresse]], qui a été rendue populaire par le manque d'adresses IPv4, n'est plus nécessaire. Pour avoir une idée à l'échelle humaine, on pourrait adresser chaque grain de sable sur la Terre, plusieurs fois<ref name=":0">{{Lien web |langue=fr-FR |titre=IPv6: Tout savoir sur ce nouveau standard Internet |url=https://www.ionos.fr/digitalguide/serveur/know-how/quels-sont-les-avantages-de-ipv6/ |site=IONOS Digital Guide |date=2019-02-06 |consulté le=2024-02-26}}</ref>.

IPv6 dispose également de mécanismes d'attribution automatique des adresses et facilite la renumérotation. La taille du [[sous-réseau]], variable en IPv4, a été fixée à 64 bits en IPv6. Les mécanismes de sécurité comme [[IPsec]] font partie des spécifications de base du protocole. L'en-tête du paquet IPv6 a été simplifié et des types d'adresses locales facilitent l'interconnexion de réseaux privés.

Le déploiement d'IPv6 sur [[Internet]] est compliqué en raison de l'incompatibilité des adresses IPv4 et IPv6. Les traducteurs d'adresses automatiques se heurtent à des problèmes pratiques importants ({{RFC|4966|titre=Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status|date=juillet 2007}}). Pendant une phase de transition où coexistent IPv6 et IPv4, les hôtes disposent d'une ''double pile'', c'est-à-dire qu'ils disposent à la fois d'adresses IPv6 et IPv4, et des [[Tunnel (réseau informatique)|tunnels]] permettent de traverser les groupes de [[routeur]]s qui ne prennent pas encore en charge IPv6.

En 2011, seules quelques sociétés ont entrepris de déployer la technologie IPv6 sur leur réseau interne, [[Google]]<ref>Jean Elyan avec IDG News Service, [http://www.lemondeinformatique.fr/actualites/lire-google-teste-ipv6-sur-son-reseau-interne-47010-page-1.html Google teste IPv6 sur son réseau interne], ''Le Monde informatique'', 12 décembre 2011</ref> notamment<!-- ou encore [[Neo Telecoms]] /!\ il manque une source-->.

Au début de l'année 2016, le déploiement d'IPv6 est encore limité, la proportion d'utilisateurs Internet en IPv6 étant estimée à 10 %<ref name="Googleipv6stats">{{en}} [http://www.google.com/intl/en/ipv6/statistics/ Google IPv6 statistics]</ref>, et ce en dépit d'appels pressants à accélérer la migration adressés aux [[fournisseur d'accès à Internet|fournisseurs d'accès à Internet]] et aux fournisseurs de contenu de la part des [[registre Internet régional|registres Internet régionaux]] et de l'[[Internet Corporation for Assigned Names and Numbers|ICANN]], l'[[épuisement des adresses IPv4]] publiques disponibles étant imminent.

En 2022, le taux d'implémentation en France serait de plus de 75 % et la couverture chez les opérateurs français serait très élevée (à l'exclusion de [[SFR]]). Près d'un site sur deux serait accessible en IPv6<ref>{{Lien web |langue=fr-FR |titre=Baromètre annuel de la transition vers IPv6 en France |url=https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html |site=Arcep |consulté le=2023-02-25}}</ref>.

En 2023, le taux d’utilisation mondial d'IPv6 serait d'environ 40 %<ref>{{Lien web |langue=en |titre=IPv6 adoption – Google |url=https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption |site=www.google.com |consulté le=2023-11-10}}</ref>.

== Raisons du développement d'un nouveau protocole IP ==
{{Distribution de l'espace d'adressage IPv4}}
[[Fichier:Ipv4-exhaust.svg|thumb|upright=1.3|Épuisement des adresses IPv4 depuis 1995.]]
Le protocole IPv4 permet d'utiliser un peu plus de quatre milliards d'adresses différentes pour connecter les ordinateurs et les autres appareils reliés au réseau. Au début d'Internet, dans les années 1970, il était pratiquement inimaginable qu'il y aurait un jour suffisamment de machines sur un unique réseau pour que l'on commence à manquer d'adresses disponibles.

Une partie des quatre milliards d'adresses IP théoriquement disponibles ne sont pas utilisables pour numéroter des machines, soit parce qu'elles sont destinées à des usages particuliers (par exemple, le {{langue|en|''[[multicast]]''}} ou les [[réseau privé|réseaux privés]]), soit parce qu'elles ont été attribuées de façon inefficace.

Jusqu'aux années 1990, les adresses sont distribuées sous forme de ''[[classe d'adresse IP|classes]]'', des blocs de {{nombre|16|millions}} (''Classe A''), {{formatnum:65536}} (''Classe B'') ou 256 adresses (''Classe C'') sont attribués aux demandeurs, parfois bien au-delà des besoins réels. Par exemple les premières grandes organisations connectées à Internet se sont vu attribuer {{nombre|16|millions}} d'adresses.

Au début des années 1990, devant l'épuisement de l'espace d'adressage, notamment des réseaux de classe B ({{RFC|1338|titre=Supernetting: an Address Assignment and Aggregation Strategy|date=juin 1992}}), les [[registre Internet régional|registres Internet régionaux]] font leur apparition et le découpage des adresses en classes est aboli au profit du plus flexible [[Adresse IP#Agrégation des adresses|CIDR]]. L'attribution des adresses est rendue plus efficace et tient compte des besoins réels, tout en permettant un certain niveau d'agrégation, nécessaire au bon fonctionnement du routage sur Internet, ces deux principes étant antagonistes.

La demande croissante en adresses pour les nouvelles applications, les équipements mobiles et les équipements connectés en permanence conduisent à l'utilisation de plus en plus fréquente des [[réseau privé|adresses privées]], de la [[Network address translation|traduction d'adresse réseau]] (NAT) et à l'attribution dynamique des adresses.

En dépit de ces efforts, l'épuisement des adresses IPv4 publiques est inévitable. C'est la raison principale du développement d'un nouveau protocole Internet mené au sein de l'[[Internet Engineering Task Force]] (IETF) dans les années 1990.

Le {{date-|3 février 2011}}, l'[[Internet Assigned Numbers Authority]] (IANA) annonce que les cinq derniers blocs d'adresses ont été distribués de façon égale aux cinq [[registre Internet régional|registres Internet régionaux]] (RIR) et que, par conséquent, elle ne dispose plus de blocs d'adresses libres<ref>[http://www.nro.net/news/ipv4-free-pool-depleted Free Pool of IPv4 Address Space Depleted]</ref>. Le {{date-|15 avril 2011}}, [[APNIC]], le RIR qui dessert la zone Asie-Pacifique, a annoncé qu'il ne disposait plus que d'un bloc [[Masque de sous-réseau|/8]] ({{nombre|16.7|millions}} d'adresses) et ne distribue désormais qu'une quantité limitée d'adresses aux demandeurs<ref>[http://www.apnic.net/publications/news/2011/final-8 APNIC IPv4 Address Pool Reaches Final /8], APNIC, 15 avril 2011</ref>. Le RIPE NCC, qui dessert l'Europe et le Moyen-Orient, a fait de même le {{date-|14 septembre 2012}}<ref>[http://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8 RIPE NCC Begins to Allocate IPv4 Address Space From the Last /8], 14 septembre 2012</ref>.
Les autres RIR épuiseront les allocations d'adresses IPv4 pour les [[Registre Internet local|registres Internet locaux]] (LIR) entre 2013 et 2015.
Les LIR commenceront à manquer d'adresses IPv4 à attribuer à leurs clients en 2012.

IPv6 améliore aussi certains aspects du fonctionnement d'IP, à la lumière de l'expérience acquise.

Les spécifications principales d'IPv6 sont publiées en 1995 par l'IETF. Parmi les nouveautés, on peut citer :
* l'augmentation de 2{{exp|32}} (soit environ 4,3 × 10{{exp|9}})<ref>Exactement {{formatnum:4294967296}}</ref> à 2{{exp|128}} (soit environ 3,4 × 10{{exp|38}})<ref>Exactement {{unité|340282366920938463463374607431768211456}}</ref> du nombre d'adresses disponibles. Pour épuiser la totalité de ce stock d'adresses, il faudrait placer {{nombre|667|millions}} de milliards d'appareils connectés sur chaque millimètre carré de la surface concrète de la Terre ; en 2025, le nombre d'appareils connectés à Internet serait d'environ 75 milliards<ref>{{Lien web |langue=en |titre=IoT devices installed base worldwide 2015-2025 |url=https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/ |site=Statista |consulté le=2023-02-25}}</ref>.
* des mécanismes de configuration et de renumérotation automatique ;
* [[IPsec]], [[Qualité de service|QoS]] et le {{langue|en|[[multicast]]}} font partie de la spécification d'IPv6, au lieu d'être des ajouts ultérieurs comme en [[IPv4]] ;
* la simplification des en-têtes de paquets, qui facilite notamment le routage.

{{-}}

== Historique ==
{{Article détaillé|Histoire d'IPv6}}

Au début des années 1990, il est devenu clair que le développement d'Internet allait aboutir à l'épuisement des adresses disponibles ({{RFC|1752|auteur=Scott Bradner, A. Mankin|titre=The Recommendation for the IP Next Generation Protocol|date=janvier 1995}}). En 1993, l'[[Internet Engineering Task Force|IETF]] lance un appel à propositions ({{RFC|1550|auteur=Scott Bradner, A. Mankin|titre=IP: Next Generation (IPng) White Paper Solicitation|date=décembre 1993}}) et annonce la création d'un groupe de travail ''IP Next Generation (IPng)''<ref>{{en}} [http://playground.sun.com/ipv6/doc/history.html History of the IPng effort]</ref>.

D'abord nommé ''Simple Internet Protocol Plus'' (SIPP, {{RFC|1710|auteur=Robert Hinden|titre=Simple Internet Protocol Plus White Paper|date=octobre 1994}}), puis ''IP Next Generation'' (IPng), celui-ci a été choisi en [[1994 en informatique|1994]] parmi plusieurs candidats et a reçu en [[1995 en informatique|1995]] son nom définitif d'IPv6 (IP version 6<ref>[http://www.iana.org/assignments/version-numbers/version-numbers.xml#version-numbers-1 IANA IP Version Numbers Registry], IANA</ref>), la version 5 d'IP ayant été réservée pour le ''Internet Stream Protocol Version 2 (ST2)'' par la {{RFC|1819|titre=Internet Stream Protocol Version 2 (ST2)|auteur=L. Delgrossi et L. Berger|date=août 1995}}. Les spécifications d'IPv6 sont initialement publiées en décembre 1995 dans la {{RFC|1883|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, Version 6 (IPv6) Specification|date=décembre 1995}} et finalisées dans la {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}} en {{date-|décembre 1998}}.

== Fonctionnement d'IPv6 ==
Le fonctionnement d'IPv6 est très similaire à celui d'IPv4. Les protocoles TCP et UDP sont pratiquement inchangés. Ceci est résumé par la formule « 96 bits de plus, rien de magique »<ref>''{{Citation|96 More Bits, No Magic.}}'' Gaurab Upadhaya.</ref>.

=== Adresse IPv6 ===
{{Article détaillé|Adresse IPv6}}

Une adresse IPv6 est longue de 128 [[Bit (informatique)|bits]], soit {{unité|16|[[octet]]s}}, contre {{unité|32|bits}} / {{unité|4|octets}} pour IPv4.
La [[Système décimal|notation décimale]] pointée employée pour les adresses IPv4 (par exemple 172.31.128.1) est abandonnée au profit d’une écriture [[Système hexadécimal|hexadécimale]], où les {{nombre|8|groupes}} de {{unité|2|octets}} ({{unité|16|bits}} par groupe) sont séparés par un signe deux-points :
: 2001:0db8:0000:85a3:0000:0000:ac1f:8001

Il est permis d’omettre de un à trois chiffres zéros non significatifs dans chaque groupe de quatre chiffres hexadécimaux. Ainsi, l’adresse IPv6 ci-dessus est équivalente à la suivante :
: 2001:db8:0:85a3:0:0:ac1f:8001

De plus, une unique suite de un ou plusieurs groupes consécutifs de 16 bits tous nuls peut être omise, en conservant toutefois les signes deux-points de chaque côté de la suite de chiffres omise, c’est-à-dire une paire de deux-points « :: » ({{RFC|2373|titre=Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status|date=juillet 2007}} et {{RFC|4291|titre=IP Version 6 Addressing Architecture}}). Ainsi, l’adresse IPv6 ci-dessus peut être abrégée en la suivante :
: 2001:db8:0:85a3::ac1f:8001

Une même adresse IPv6 peut être représentée de plusieurs façons différentes, ainsi, les deux adresses 2001:db8::1:0:0:1 et 2001:db8:0:0:1::1 sont équivalentes après développement, bien que différentes dans leur structure. Les blocs de 16 bits d'une adresse IPv6 sont ordonnés de gauche à droite. La {{RFC|5952|titre=A Recommendation for IPv6 Address Text Representation|date=août 2010}} recommande une [[Canonique (informatique)|représentation canonique]]. 

Il est à noter que l'on ne peut omettre qu'une seule suite de bits nuls dans une adresse IPv6. Autrement, il serait impossible d'identifier le nombre de bits nuls entre chaque paire de deux points "::".

Les réseaux sont identifiés en utilisant la [[Adresse IP#Agrégation des adresses|notation CIDR]] : la première adresse du réseau est suivie par une [[barre oblique]] « / » puis par un entier compris entre 0 et 128, lequel indique la longueur en bits du ''préfixe'' du réseau, à savoir de la partie commune des adresses déterminées par ledit réseau.

Voici des exemples d’adresses réseau IPv6 avec leurs ensembles d’adresses déterminées :
* Le préfixe 2001:db8:1f89::/48 représente l’ensemble des adresses qui commence à 2001:db8:1f89:0:0:0:0:0 et finit à 2001:db8:1f89:ffff:ffff:ffff:ffff:ffff.
* Le préfixe 2000::/3 représente les adresses de 2000:0:0:0:0:0:0:0 à 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff<ref group="Ex">Le premier octet de l’adresse 2000::/3 s’écrit en binaire 0010 0000. Le masque /3 implique que seuls les 3 bits de poids forts sont figés. L’adresse haute correspondant à ce préfixe s’écrit ainsi en binaire de la manière suivante : 0011 1111 suivi de 8+7×16 "1" soit 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.</ref>.
* Le préfixe fc00::/7 représente les adresses de fc00:0:0:0:0:0:0:0 à fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
* Le préfixe fe80::/10 représente les adresses de fe80:0:0:0:0:0:0:0 à febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
* Le préfixe ::1/128 correspond à la seule adresse 0:0:0:0:0:0:0:1.

Certains préfixes d’adresses IPv6 jouent des rôles particuliers :

{| class="wikitable"
! Description !! Terme anglais !! Détail 
! Préfixe IPv6 !! Équivalent IPv4
|+ Type d’adresses IPv6
|-
|Boucle Locale
|Node-local
Loopback
|Adresse de bouclage, utilisée lorsqu'un hôte se parle à lui-même (ex : envoi de données entre 2 programmes sur cet hôte).
|::1/128
|127.0.0.0/8 (principalement 127.0.0.1)<ref>On note que, en termes d’adressage IPv4, 127.0.0.0/8 forme la plage des adresses possibles de boucle locale. Cela représente 2{{exp|24}}-2 adresses potentielles de cette nature en IPv4 contre « une seule » en IPv6.</ref>
|-
|Liaison Locale
|Link-Local
|Envoi individuel sur liaison locale ({{RFC|4291}}). Obligatoire et indispensable au bon fonctionnement du protocole.
|fe80::/10
|169.254.0.0/16
|-
|Monodiffusion Mondiale
|Global Unicast
|Plage d'adresse publique, routable sur Internet, globalement uniques (doublon impossible) - Hors exceptions mentionnées ci-dessous.
|2000::/3
|
|-
|Localement Unique
|Unique Local
|Plage d'adresse privée, réservée à l'utilisation sur les réseaux locaux domestiques et d'entreprises. Elles ne sont pas globalement uniques (doublon possible, réutilisées sur plusieurs réseaux IP privés).
|fc00::/7
|10.0.0.0/8
172.16.0.0/12

192.168.0.0/16
|-
| Multidiffusion
|Multicast
| Diffusion groupée ({{RFC|4291}})
| ff00::/8 
|224.0.0.0/4
|-
|Non spécifié
|Unspecified
|Utilisée comme adresse source par un hôte en cours d'acquisition de son adresse réseau.
|::/128
|0.0.0.0
|-
|Documentation
|Documentation
|Plage réservée pour utilisation comme valeurs d'exemple ou dans de la documentation technique. Ne devrait jamais être utilisée sur de vrais réseaux.
|2001:db8::/32
|192.0.2.0/24
198.51.100.0/24

203.0.113.0/24
|-
|Réservé
|Reserved
|
|::/8
|
|}

Source : [https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types IPv6 Address Types - RIPE] et [https://cisco.goffinet.org/ccna/ipv6/adresses-ipv6-unicast/ cisco.goffinet.org] 

Deux des adresses réservées de ::/128 peuvent être remarquées :
* ::/128 est l’adresse non spécifiée. On peut la trouver comme adresse source initiale, à l'instar de 0.0.0.0 en IPv4, dans une phase d’acquisition de l’adresse réseau ;
* ::1/128 est l’adresse de boucle locale (dite aussi [[localhost]]). Elle est semblable à 127.0.0.1 en IPv4.

Les adresses de 2000::/3 peuvent être distinguées comme suit :
* Les adresses permanentes (2001::/16) sont ouvertes à la réservation depuis [[1999]] :
** La plage 2001::/32 est utilisée pour [[Teredo (protocole)|Teredo]];
** La plage 2001:db8::/32 est dédiée à un adressage de réseau IPv6 au sein de la documentation technique impliquant de tels réseaux. Cet usage réservé est spécifié dans la {{RFC|3849|titre=IPv6 Address Prefix Reserved for Documentation|date=juillet 2004}} ;
* Les adresses [[6to4]] (2002::/16) permettent d’acheminer le trafic IPv6 ''via'' un ou plusieurs réseaux [[IPv4]] (obsolète par {{RFC|7526}});
* Toutes les autres adresses routables (plus des trois quarts de la plage 2000::/3) sont assignées aux opérateurs en fonction des besoins.

==== Structure de l'adresse IPv6 unicast globale ====
{| class="wikitable" style="width: 750px"
|+ Structure des adresses unicast globales
|-
!style="width: 0%"|champ
|style="text-align: center;"| ''préfixe de routage global''
|style="text-align: center;"| ''identificateur de sous-réseau''
|style="text-align: center;"| ''identificateur d'interface''
|-
!style="width: 0%"|bits
|style="text-align: center; width: 37.5%;"| n
|style="text-align: center; width: 12.5%;"| 64-n
|style="text-align: center; width: 50%;"| 64
|}

Le préfixe de routage global, de taille variable, représente la ''topologie publique'' de l'adresse, autrement dit celle qui est vue à l'extérieur d'un site. La partie ''sous-réseau'' constitue la ''topologie privée''.
La {{RFC|4291|auteur=R. Hinden, S. Deering|titre=IP Version 6 Addressing Architecture|date=février 2006}} indique que toutes les adresses [[unicast]] globales doivent avoir une taille d'identificateur d'interface (IID) égale à 64 bits, à l'exception de celles qui débutent par 000 en binaire. Pour les liens point-à-point, il est cependant possible d'utiliser un /127 ({{RFC|6164|auteur=M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten|titre=Using 127-Bit IPv6 Prefixes on Inter-Router Links|date=avril 2011}}).
La {{RFC|7421|titre=Analysis of the 64-bit Boundary in IPv6 Addressing|date=janvier 2015}} explique le choix architectural de cette taille uniforme d'identificateur d'interface qui semble dépasser largement les besoins d'adressage dans un sous-réseau.

==== Portée ====
La portée (en anglais, le ''scope'') d'une adresse IPv6 consiste en son domaine de validité et d'unicité, d'après la {{RFC|4007}}.

On distingue :
* Les adresses d'envoi individuel ({{RFC|4291}}) (unicast)
** L'adresse ''loopback'' ::1/128 a une validité limitée à l'hôte; c'est l'adresse de bouclage ({{RFC|4291}}) (loopback en anglais);
** Les adresses link-local, uniques sur un lien donné ;
** Les autres adresses, y compris les adresses locales uniques, ont une portée ''global'', c'est-à-dire qu'elles sont uniques dans le monde et peuvent être utilisées pour communiquer avec d'autres adresses globalement uniques, ou des adresses link-local sur des liens directement connectés,
* Les adresses d'envoi à la cantonade ({{RFC|4291}}) (anycast), dont la portée est identique aux adresses unicast ;
* Les adresses d'envoi en diffusion groupée ({{RFC|4291}}) (multicast) ff00::/8, pour lesquels les bits 13 à 16 déterminent la portée : local, lien, organisation ou global.

Toutes les interfaces où IPv6 est actif ont au moins une adresse de portée link-local (fe80::/10); l'adresse notée fe80::/10 désigne l'envoi individuel sur liaison locale ({{RFC|4291}}).

==== Indice de zone ====
Il peut exister plusieurs adresses link-local sur des liaisons différentes d'une même machine, on lève les ambiguïtés en fournissant un ''indice de zone'' ({{RFC|4007|titre=IPv6 Scoped Address Architecture|date=mars 2005}}) qu'on ajoute à l'adresse après un signe pour cent : fe80::3%eth0 correspondra à l'adresse link-local fe80::3 sur l'interface eth0 par exemple.

==== Attribution des blocs d'adresses IPv6 ====
Dans l'espace d'adresse unicast global (2000::/3), l'[[Internet Assigned Numbers Authority|IANA]] attribue des blocs dont la taille varie de /12 à /23 aux [[registre Internet régional|registres Internet régionaux]]<ref>[http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml IPv6 Global Unicast Address Assignments], IANA</ref>, comme le [[RIPE NCC]] en Europe. Ces derniers distribuent des préfixes /32 aux ''[[registre Internet local|registres Internet locaux]]'' qui les attribuent ensuite sous forme de bloc /48 à /64 aux utilisateurs finaux ({{RFC|6177|titre=IPv6 Address Assignment to End Sites|auteur=T. Narten, G. Huston, L. Roberts|date=mars 2011}})<ref>La taille fixe de bloc /48 était autrefois considérée comme standard par la RFC {{n°|3177}}, la politique concernant les tailles des blocs à assigner à l'utilisateur final est désormais laissée à l'appréciation du RIR.</ref>.

Chaque utilisateur final se voit attribuer un bloc dont la taille varie de /64 (un seul [[sous-réseau]]) à /48 ({{Nombre|65536}} sous-réseaux), chacun des sous-réseaux pouvant accueillir un nombre d'hôtes virtuellement illimité (2{{exp|64}}). Dans le bloc 2000::/3 qui représente ⅛{{e}} de l'espace d'adressage disponible en IPv6, on peut donc créer 2{{exp|29}}, soit {{unité|500|millions}} de blocs /32 pour des fournisseurs d'accès à Internet, et 2{{exp|45}}, soit {{unité|35000|milliards}} de réseaux d'entreprise typiques (/48).

=== En-tête IPv6 ===
[[Fichier:Ipv6 header.svg|thumb|upright=1.3|En-tête IPv6.]]
[[Fichier:Ipv4 header.svg|thumb|upright=1.3|En-tête IPv4.]]
L'en-tête du paquet IPv6 est de taille fixe à {{unité|40|octets}}, tandis qu'en IPv4 la taille minimale est de {{unité|20|octets}}, des options pouvant la porter jusqu'à {{unité|60|octets}}, ces options demeurant rares en pratique.

La signification des champs est la suivante :
* ''Version'' ({{nombre|4|bits}}) : fixé à la valeur du numéro de protocole internet, 6
* ''{{langue|en|texte=Traffic Class}}'' ({{nombre|8|bits}}) : utilisé dans la [[qualité de service]].
* ''{{langue|en|Flow Label}}'' ({{nombre|20|bits}}) : permet le marquage d'un flux pour un traitement différencié dans le réseau.
* ''{{langue|en|Payload length}}'' ({{nombre|16|bits}}) : taille de la charge utile en octets.
* ''{{langue|en|Next Header}}'' ({{nombre|8|bits}}) : identifie le type de {{langue|en|header}} qui suit immédiatement selon la même convention qu'IPv4.
* ''{{langue|en|Hop Limit}}'' ({{nombre|8|bits}}) : décrémenté de 1 par chaque routeur, le paquet est détruit si ce champ atteint 0 en transit.
* ''{{langue|en|Source Address}}'' ({{nombre|128|bits}}) : adresse source
* ''{{langue|en|Destination Address}}'' ({{nombre|128|bits}}) : adresse destination.

Il est possible qu'un ou plusieurs en-têtes d'extension suivent l'en-tête IPv6. L'en-tête de routage permet par exemple à la source de spécifier un chemin déterminé à suivre.

==== Comparaison avec IPv4 ====
* La taille de l'en-tête est fixe, le champ IHL ({{langue|en|IP Header Length}}) est donc inutile.
* Le champ ''Durée de vie'' ({{RFC|0791}}), ''{{langue|en|[[Time to Live]]}}'' (TTL) est renommé en ''{{langue|en|Hop Limit}}'', reflétant la pratique, la {{RFC|791|titre=INTERNET PROTOCOL|date=septembre 1981}} prévoyait en effet que le champ ''TTL'' reflétait le ''temps'' en secondes.
* Il n'y a pas de [[somme de contrôle]] sur l'en-tête. En IPv4, cette somme de contrôle inclut le champ TTL et oblige les routeurs à le recalculer dans la mesure où le TTL est décrémenté. Ceci simplifie le traitement des paquets par les routeurs.
* Le champ ''{{langue|en|Payload length}}'' n'inclut pas la taille de l'en-tête standard, contrairement au champ ''{{langue|en|Total length}}'' d'IPv4. Tous les en-têtes optionnels sont inclus dans la ''{{langue|en|payload length}}'' tel que définit dans la {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}} dont la version française indique « Certains champs de l’en-tête IPv4 ont été enlevés ou rendus optionnels, pour réduire dans les situations classiques le coût (en ressources de traitement) de la gestion des paquets et pour limiter le surcoût en [[bande passante]] de l’en-tête IPv6. » ({{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}).
* Les éventuelles informations relatives à la fragmentation sont repoussées dans un en-tête qui suit.
* Les en-têtes optionnels IPv6 doivent tous être analysés un par un pour en déterminer la fin et savoir où commence la charge utile (''{{langue|en|payload}}'') de {{nobr|niveau 4}} dans le paquet IPv6 ; en conséquence, les décisions de routage basées sur le contenu des en-têtes de paquets au {{nobr|niveau 4}} (par exemple l'identification du numéro de port TCP, UDP, ou type de requête ICMPv6) ne peut se faire sans avoir analysé la chaîne complète des en-têtes optionnels (même seulement pour ne pas en tenir compte) ; ceci inclut notamment les options de fragmentation qui pourraient avoir été insérées par l'émetteur du paquet. Cela pose des difficultés de mise en œuvre dans certains routeurs ou pare-feux pouvant notamment conduire à des problèmes de performance<ref>{{Lien web|langue=en |titre=If unchecked, IPv6 extension headers may affect router performance |url=http://searchenterprisewan.techtarget.com/feature/If-unchecked-IPv6-extension-headers-may-affect-router-performance |site=TechTarget |date=août 2011 }}.</ref>{{,}}<ref>{{Lien web|langue=en |titre=IPv6 Extension Headers Review and Considerations&nbsp; [IP Version 6 (IPv6)] |url=https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html |site=Cisco |consulté le=2018-03-12}}.</ref>.
* Le protocole de résolution de {{nobr|niveau 2}} ([[Address Resolution Protocol|ARP]]) de type {{langue|en|broadcast}} est remplacé par [[Neighbor Discovery Protocol|NDP]] qui est en fait une utilisation d'[[Internet Control Message Protocol V6|ICMPv6]] en multicast, avec quasiment un groupe multicast distinct par {{langue|en|host}} ({{RFC|4861}}) ; cela peut entrainer des dysfonctionnements liés à des filtrages ({{RFC|4890}}) d'une part, à des problèmes de performances sur certains équipements<ref>{{Article|langue=en-US |titre=The network nightmare that ate my week |périodique={{langue|en|Occasionally Coherent}} |date=2014-09-06 |lire en ligne=https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ |consulté le=2018-03-12}}.</ref> d'autre part.

==== Fragmentation et option jumbo ====
En IPv4, les routeurs qui doivent transmettre un paquet dont la taille dépasse le [[Maximum transmission unit|MTU]] du lien de destination ont la tâche de le fragmenter, c'est-à-dire de le segmenter en plusieurs paquets IP plus petits. Cette opération complexe est coûteuse en termes de CPU pour le routeur ainsi que pour le système de destination et nuit à la performance des transferts, d'autre part les paquets fragmentés sont plus sensibles aux pertes : si un seul des fragments est perdu, l'ensemble du paquet initial doit être retransmis.

En IPv6, les routeurs intermédiaires ne fragmentent plus les paquets et renvoient un paquet [[Internet Control Message Protocol V6|ICMPv6]] ''{{langue|en|Packet Too Big}}'' en lieu et place, c'est alors la machine émettrice qui est responsable de fragmenter le paquet. L'utilisation du [[Path MTU discovery]] est cependant recommandée pour éviter toute fragmentation.

Ce changement permet de simplifier la tâche des routeurs, leur demandant moins de puissance de traitement.

La MTU minimale autorisée pour les liens a également été portée à {{unité|1280|octets}} (contre 68 pour l'[[IPv4]], {{RFC|791}}, la RFC précise qu'un hôte doit être capable de recevoir un paquet ré-assemblé de {{unité|576|octets}}.). Si des liens ne peuvent pas soutenir ce MTU minimal, il doit exister une couche de convergence chargée de fragmenter et de réassembler les paquets.

Comme pour IPv4, la taille maximale d'un paquet IPv6 hors en-tête est de {{unité|65535|octets}}. IPv6 dispose cependant d'une option ''[[jumbogram]]'' ({{RFC|2675|titre=IPv6 Jumbograms|date=août 1999}}) permettant de porter la taille maximale d'un paquet à {{unité|4|Go}} et profiter ainsi des réseaux avec un MTU plus élevé.

==== En-têtes d'extension ====
L'en-tête IPv6 peut être suivi d'un certain nombre d'en-tête d'extensions. Ceux-ci se succèdent, chaque en-tête indiquant la nature du suivant. Quand ils sont présents, leur ordre est le suivant :

{| class="wikitable"
|+ En-têtes d'extension IPv6
|-
! Nom français
! Nom anglais
! Type
! Taille
! Description
! RFC
|-
|sauts après sauts {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}
|''{{langue|en|Options Hop-By-Hop}}''
| 0 || variable || Contient les options qui doivent être honorées par tous les routeurs de transit, par exemple l'option jumbogram. || {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}, {{RFC|2675}}
|-
|colspan = "2" | ''Routage''
| 43 || variable || Permet de modifier le routage à partir de la source, qui est utilisé notamment par [[Mobile IPv6]] || {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}} {{RFC|3775}}, {{RFC|5095}}
|-
|colspan = "2" |''Fragment''
| 44 || {{nombre|64|bits}} || Contient les informations relatives à la fragmentation. || {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}
|-
|
|''{{langue|en|Authentication Header (AH)}}''
| 51 || variable || Contient les informations nécessaires à l'authentification de l'en-tête, voir [[IPsec]]. || {{RFC|4302}}
|-
|
|''{{langue|en|Encapsulating Security Payload (ESP)}}''
| 50 || variable || Contient les informations relatives au chiffrement du contenu, voir [[IPsec]]. || {{RFC|4303}}
|-
|''Options de destination''
|
| 60 || variable || Options qui doivent être traitées par la destination finale. || {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}
|-
|Pas d’en-tête suivant {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}.
|''{{langue|en|No Next Header}}''
| 59 || vide || Indique qu'il n'y a aucune charge utile qui suit. || {{RFC|2460|auteur=Robert Hinden, Steve Deering|titre=Internet Protocol, {{nobr|Version 6}} (IPv6) Specification|date=décembre 1998}}
|}

Les autres valeurs possibles suivent la même convention que le champ ''{{langue|en|Protocol}}'' dans l'en-tête IPv4<ref>{{en}} [http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml {{langue|en|Assigned Internet Protocol Numbers}}].</ref>.

=== Neighbor Discovery Protocol ===
{{Article détaillé|Neighbor Discovery Protocol}}
Le protocole de «Découverte de voisin pour IP version 6» ([[Neighbor Discovery Protocol]] ou ND, {{RFC|4861}}) associe les adresses IPv6 à des adresses MAC sur un segment, comme [[Address Resolution Protocol|ARP]] pour IPv4. Il permet également de découvrir les routeurs et les préfixes routés, le MTU, de détecter les adresses dupliquées, les hôtes devenus inaccessibles et l'autoconfiguration des adresses et éventuellement les adresses des serveurs DNS récursifs (RDNSS, {{RFC|5006}}). Il s'appuie sur [[ICMPv6]].

=== Attribution des adresses IPv6 ===
[[Fichier:Ipv6 eui64.svg|thumb|upright=1.3|Construction d'une adresse d'interface [[EUI-64]] modifiée à partir d'une adresse MAC.]]
Dans un [[sous-réseau]], il existe plusieurs méthodes d'attribution des adresses :

; Configuration manuelle : l'administrateur fixe l'adresse. Les adresses constituées entièrement de 0 ou de 1 ne jouent pas de rôle particulier en IPv6.

; Configuration automatique

Sans état (''{{Langue|en|Stateless Address Autoconfiguration}}'', SLAAC) :
* autoconfiguration avec tirage pseudo aléatoire, l'adresse change dans le temps ({{RFC|4941}}),
* autoconfiguration basée sur une clé secrète et sur le préfixe réseau, ne dévoile pas l'adresse MAC et est stable pour chaque préfixe réseau, c'est l'usage recommandé pour une adresse fixe ({{RFC|8064}}, {{RFC|7217}}),
* autoconfiguration basée sur l'[[adresse MAC]] ([[EUI-64]]), adresse stable mais machine facilement identifiable, usage déconseillé par l'[[IETF]] depuis 2017 ({{RFC|8064}}, {{RFC|4862}}),
* utilisation d'adresses générées cryptographiquement (CGA, {{RFC|3972}}), qui lient l'adresse à la clé publique du client et qui peuvent être utilisées par [[Secure Neighbor Discovery Protocol|SEND]].
Avec état :
* attribution par un serveur [[DHCPv6]] ({{RFC|3315}}).

==== Protection des données personnelles - privacy extensions ====
Quand ce protocole a été développé, dans les années 1990, internet n'était pas aussi développé et les problématiques de protection des [[données personnelles]] et de vie privée n'étaient pas abordées. Mais dans les années 2010, l'utilisation de l'[[adresse MAC]] d'une [[carte réseau]] pour construire une adresse IPv6 a suscité des inquiétudes quant à la protection des données personnelles<ref>articles 16 et 17 de la directive générale 95/46, ''[https://www.droit-technologie.org/dossiers/les-risques-majeurs-de-ipv6-pour-la-protection-des-donnees-a-caractere-personnel/ Les risques majeurs de IPv6 pour la protection des données à caractère personnel]''</ref> dans la mesure où l'adresse MAC permet d'identifier de façon unique le matériel. Pour pallier cet oubli, le protocole a évolué et d'autres méthodes de génération d'adresses ont été apportées, nommées ''privacy extensions'' :

Il est possible d'utiliser des adresses temporaires générées de façon pseudo-aléatoire et modifiées régulièrement ({{RFC|4941}}). Pour le besoin d'une adresse stable dans le temps il est possible et même recommandé depuis 2017 d'utiliser l'adresse dérivée d'une clé secrète et du préfixe réseau (nommée ''stable private'', {{RFC|7217}}). Il reste toujours la possibilité d'utiliser un service d'attribution automatique des adresses IPv6 par un serveur, de façon similaire à ce qui existe pour IPv4, avec DHCPv6.

=== Multicast ===
Le [[multicast]], qui permet de diffuser un paquet à un groupe, fait partie des spécifications initiales d'IPv6. Cette fonctionnalité existe également en IPv4 où il a été ajouté par la {{RFC|988}} en 1986.

Il n'y a plus d'adresse [[broadcast (informatique)|broadcast]] en IPv6, celle-ci étant remplacée par une adresse multicast spécifique à l'application désirée. Par exemple, l'adresse ff02::101 permet de contacter les serveurs [[Network Time Protocol|NTP]] sur un lien. Les hôtes peuvent ainsi filtrer les paquets destinés à des protocoles ou des applications qu'ils n'utilisent pas, et ce sans devoir examiner le contenu du paquet.

Au niveau [[ethernet]], une série de préfixes [[Organizationally Unique Identifier|OUI]] est réservée aux adresses IPv6 multicast (33:33:xx). L'adresse MAC du groupe multicast consistera en ces {{unité|16|bits}} que l'on fait suivre par les 32 derniers bits de l'adresse IPv6 multicast. Par exemple, l'adresse ff02::3:2 correspondra à l'adresse MAC 33:33:00:03:00:02. Bien que de nombreux groupes multicast partagent la même adresse MAC, ceci permet déjà un filtrage efficace au niveau de la carte réseau.

Bien que la prise en charge du multicast au niveau des liens soit obligatoire pour IPv6, le routage des paquets multicast au-delà du segment requiert l'utilisation de protocoles de routage comme [[Protocol Independent Multicast|PIM]], à la discrétion du fournisseur d'accès à Internet.

Le protocole [[Multicast Listener Discovery]] permet d'identifier les groupes actifs sur un segment, à l'instar d'[[Internet Group Management Protocol|IGMP]] pour IPv4.

Les [[commutateurs réseau|commutateurs ethernet]] les plus simples traitent les trames multicast en les diffusant comme des trames [[broadcast (informatique)|broadcast]]. Ce comportement est amélioré avec ''MLD snooping'' qui limite la diffusion aux seuls hôtes manifestant un intérêt pour le groupe, à l'instar d'''[[IGMP Snooping]]'' pour IPv4.

Alors qu'en IPv4 il est difficile de réserver des adresses multicast globales, la {{RFC|3306}} associe un bloc d'adresses multicast /96 pour chaque préfixe routable sur Internet, c'est-à-dire que chaque organisation dispose automatiquement de {{nombre|4|milliards}} d'adresses multicast publiques. La {{RFC|3956}} simplifie également la réalisation de points de rendez-vous pour les interconnexions multicast.

La structure des adresses de diffusion groupée, fondées sur le préfixe d’envoi individuel peut ainsi prendre la forme d'un des exemples suivants :
* Préfixes mondiaux – un réseau avec un préfixe d’envoi individuel de 3FFE:FFFF:3::/48 aurait aussi un préfixe de diffusion groupée fondé sur le préfixe d’envoi individuel de FF3x:0030:3FFE:FFFF:0003::/96 (où 'x' est toute portée valide).
* {{Lien|langue=en|trad=Source-specific_multicast|fr=Multicast issu d'une source spécifique|texte=SSM}} – toutes les adresses de diffusion groupée SSM IPv6 vont avoir le format FF3x::/96 ({{RFC|3306}}).

=== DNS ===
Dans le [[Domain Name System]], les noms d'hôtes sont associés à des adresses IPv6 grâce à l'enregistrement AAAA.

 www.ipv6.ripe.net. IN AAAA 2001:610:240:22::c100:68b

L'enregistrement inverse est réalisé sous ip6.arpa en inversant l'adresse écrite sous forme canonique ({{RFC|3596}}) : le quartet de moindre poids est codé le premier :

 b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. IN PTR www.ipv6.ripe.net.

La première mouture de la norme prévoyait d'utiliser le suffixe ''ip6[[.int]]''.

Le mécanisme utilisé pour construire le nom de domaine inverse est similaire à celui employé en IPv4, à la différence que les points sont utilisés entre chaque quartet ({{RFC|3596}}) de bits (ou ''[[nibble (informatique)|nibble]]'' de 4 bits), ce qui allonge le domaine.

Les plus complexes bitlabels ({{RFC|2673}}), DNAME et A6 ({{RFC|2874}}), qui permettent de s'affranchir de la contrainte de la délégation sur une frontière de nibble, sont considérés comme expérimentaux et leur support est rare ({{RFC|3363}}, l'enregistrement A6, inusité, est relégué à l'état « historique » par la {{RFC|6563}} en 2012).

La résolution inverse peut être utilisée par des systèmes de contrôle d'accès ainsi que par des outils de diagnostic comme [[traceroute]].

=== Traduction d'adresse ===
Le recours à la [[Network address translation|traduction d'adresse]] est découragé en IPv6 pour préserver la transparence du réseau ({{RFC|5902|titre=IAB Thoughts on IPv6 Network Address Translation}}), son utilisation n'est plus nécessaire pour économiser des adresses.

=== IPv6 et mobilité ===
{{Article détaillé|contenu=Article détaillé : [[Mobile IPv6 (internet)|Mobile IPv6]]}}

IPv6 prévoit des mécanismes pour conserver une même adresse IPv6 pour une machine pouvant être connectée à des réseaux différents, tout en évitant autant que possible le routage triangulaire.

=== Technologies de transition pour l'accès à l'Internet IPv6 ===
{{Article détaillé|Transition d'IPv4 vers IPv6}}
[[Fichier:Tunnel-ipv6.svg|thumb|upright=1.3|Schéma de fonctionnement d'un tunnel statique.]]
[[Fichier:6to4.svg|thumb|upright=1.3|Schéma de fonctionnement de 6to4.]]
[[Fichier:6to4 convert address.svg|upright=1.3|thumb|Encodage d'une adresse IPv4 dans le préfixe 6to4.]]
Les adresses IPv4 et IPv6 ne sont pas compatibles, la communication entre un hôte ne disposant que d'adresses IPv6 et un hôte ne disposant que d'adresses IPv4 constitue donc un problème. La transition consiste à doter les hôtes IPv4 d'une ''double pile'', c'est-à-dire à la fois d'adresses IPv6 et IPv4.

La manière la plus simple d'accéder à IPv6 est lors de l'abonnement de choisir un [[Fournisseur d'accès à Internet|FAI]] qui offre de l'IPv6 ''nativement'', c'est-à-dire sans recours à des tunnels.

À défaut, et pendant une phase de transition, il est possible d'obtenir une connectivité IPv6 via un tunnel. Les paquets IPv6 sont alors encapsulés dans des paquets IPv4, qui peuvent traverser le réseau du FAI jusqu'à un serveur qui prend en charge IPv6 et IPv4, et où ils sont décapsulés. Le recours à des tunnels, et donc à un [[réseau overlay]], est de nature à nuire aux performances.

; Tunnels statiques :
Plusieurs services du type « ''[[tunnel broker]]'' » sont disponibles, nécessitant en général une inscription. On peut citer SixXS<ref>{{en}} [https://www.sixxs.net SixXS]</ref>, ou Hurricane Electric<ref>{{en}} [http://tunnelbroker.net/ Hurricane Electric Free IPv6 Tunnel Broker]</ref>.

Les protocoles utilisés peuvent être :
* [[6in4]] ({{RFC|4213}}) fait usage du numéro de protocole 41 d'IP et est donc parfois bloqué par des [[pare-feu (informatique)|pare-feux]] et les NAT.
* [[Anything In Anything|AYIYA]]<ref>{{en}} [http://tools.ietf.org/html/draft-massar-v6ops-ayiya-02 AYIYA: Anything In Anything], Internet Draft, 2004</ref> permet le transport sur UDP ou TCP et gère le changement d'adresse IP.
* [[Generic Routing Encapsulation|GRE]] utilise le numéro de protocole 47.

Le [[Tunnel Setup Protocol]] ({{RFC|5572}}) facilite la création des tunnels et permet la mobilité et l'authentification. Le ''Tunnel Information and Control protocol'', utilisé par {{Lien|langue=en|fr=AICCU}}, automatise la création des tunnels.

; Tunnels automatiques :
* [[6to4]] ({{RFC|3056}}) si une adresse IPv4 publique (de préférence fixe) est disponible, 6to4 est simple à mettre en place. Pour l'accès aux adresses IPv6 hors du préfixe 2002::/16 (réservé pour 6to4), une adresse relais [[anycast]] est réservée, 192.88.99.1.
* [[6rd]] ({{RFC|5569}}) est similaire au précédent. Il ne fait pas usage du préfixe 2002::/16 mais d'un préfixe spécifique au fournisseur d'accès.
* [[6over4]] ({{RFC|2529}}) permet la connexion à travers un réseau IPv4 qui prend en charge [[multicast]]
* [[ISATAP]] ({{RFC|5214}}), une amélioration du précédent qui ne requiert pas le support multicast.
* [[Teredo (protocole)|Teredo]] ({{RFC|4380}}) utilisable dans un réseau d'adresses IPv4 privées, relié à Internet via un routeur assurant une traduction d'adresses. Une implémentation de Teredo fait partie de la pile IPv6 des systèmes [[Microsoft Windows|Windows]], et une implémentation pour [[Linux]] et les systèmes [[Berkeley Software Distribution|BSD]] est miredo<ref>[http://www.remlab.net/miredo/ miredo]</ref>.

; Passerelles applicatives :
Il est possible de faire usage de serveurs qui disposent d'une double pile et qui font office de passerelle applicative ({{Langue|en|Application-Level gateway}}, ALG), un serveur [[proxy|mandataire]] web par exemple.

NAT-PT combine la [[network address translation|traduction d'adresse réseau]] et un serveur DNS pour permettre la communication entre des systèmes IPv4 et des systèmes IPv6.
Il est défini dans la {{RFC|2766}} mais a été rendu obsolète par la {{RFC|4966}} en raison de problèmes causés.

=== Multihoming ===
Le [[multihoming]] consiste, pour un réseau, à disposer de plusieurs fournisseurs de transit dans le but d'augmenter la fiabilité de l'accès Internet. En IPv4, ceci est généralement accompli en disposant d'un numéro d'[[Autonomous System|AS]] propre, d'une plage d'adresse IP de type ''Provider Independent'' (PI) et en utilisant [[Border Gateway Protocol|BGP]] pour échanger des routes de façon dynamique avec chacun des fournisseurs d'accès.

Cette façon de réaliser le multihoming consomme des numéros d'AS et augmente la taille de la table de routage Internet en raison de préfixes PI qu'il n'est pas possible d'agréger.

La standardisation du multihoming en IPv6 a tardé, une des ambitions initiales de l'architecture IPv6 étant de n'utiliser que des adresses de type ''Provider Aggregatable'' (PA) pour réduire la taille de la table de routage Internet. Dans cette optique, le multihoming était réalisé en attribuant autant d'adresses PA qu'il y a de fournisseurs, les mécanismes d'IPv6 comme l'attribution automatique et la durée de vie limitée des adresses facilitant les changements d'adresses liées aux changements de fournisseurs. Par conséquent, les registres Internet régionaux ne distribuaient pas de bloc PI pour IPv6 jusqu'à récemment.

En 2009, les RIR, comme le [[RIPE NCC]], ont modifié leur politique en acceptant d'attribuer des blocs PI aux entreprises qui veulent se connecter à plusieurs fournisseurs<ref>''[http://www.ripe.net/ripe/policies/proposals/2006-01.html Provider Independent (PI) IPv6 Assignments for End User Organisations]'', 2009</ref>, la taille minimale du bloc PI est de /48, alors que la taille des blocs PA est /32. Ceci permet de réaliser le multihoming de la même façon qu'en IPv4.

D'autres approches possibles sont basées sur la séparation de l'identificateur et du localisateur (''Identifier / Locator Separation'') :
* [[SHIM6]] ({{RFC|5533}})
* [[Host Identity Protocol]] ({{RFC|4423}}, {{RFC|5102}})
* [[Stream Control Transmission Protocol]]
* GSE/8+8<ref>{{en}} [http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00 GSE - An Alternate Addressing Architecture for IPv6], Internet Draft 1997</ref>{{,}}<ref>{{en}} [http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-multihoming-bof.pdf Multihoming] présentation RIPE 52 {{pdf}}</ref>.
* [[Locator/Identifier Separation Protocol]] (LISP)<ref>[http://tools.ietf.org/html/draft-farinacci-lisp-12 ocator/ID Separation Protocol (LISP)], Internet Draft, 2009</ref>
* NPTv6, soit la traduction de préfixe ({{RFC|6296}})

Ceci est un sujet de recherche confié au groupe de travail ''Routing Research'' de l'{{Lien|langue=en|fr=Internet Research Task Force}}<ref>[http://www.irtf.org/charter?gtype=rg&group=rrg RRG] {{Lien archive|url=http://www.irtf.org/charter?gtype=rg&group=rrg |horodatage archive=20060812095706 |titre=Copie archivée}}</ref>.

== Déploiement d'IPv6 ==
{{section à actualiser|date=septembre 2023}}
=== L'Internet IPv6 ===
[[Fichier:IPv6-as.svg|thumb|upright=1.3|Nombre de préfixes et d'AS IPv6 sur Internet, de 2003 à {{quand|aujourd'hui}}. À titre de comparaison, il y a environ {{formatnum:50000}} AS visibles dans la [[default-free zone]] en 2015.]]
Dans une première phase, les fournisseurs d'accès à Internet utilisent des tunnels qui encapsulent les paquets IPv6 dans des paquets IPv4 (via 6in4 ou GRE) pour traverser les groupes de [[routeur]]s qui ne prennent pas en charge IPv6. Lorsque c'est possible, les échanges se font ''nativement'', avec IPv4 et IPv6 qui coexistent sur les mêmes liaisons. Pour autant que les routeurs soient mis à jour pour la prise en charge d'IPv6, il n'est pas nécessaire de disposer d'une infrastructure séparée pour IPv6, les routeurs traitant à la fois le trafic IPv4 et IPv6.

=== Prise en charge d'IPv6 par le DNS ===
Depuis {{date-|juillet 2004}}, l'[[Internet Corporation for Assigned Names and Numbers|ICANN]] accepte d'intégrer des serveurs de noms avec des adresses IPv6 (''{{Langue|en|[[Domain Name System#Glue records|glue records]]}}'') dans la [[zone racine]]<ref name="ocde"/>. Les premiers [[domaine de premier niveau|domaines de premier niveau]] qui disposent d'un serveur DNS IPv6 sont [[.kr]] et [[.jp]], [[.fr]] suit peu après<ref>{{en}} [http://www.icann.org/en/announcements/announcement-20jul04.htm Next-generation IPv6 Address Added to the Internet's Root DNS Zone] - [[Internet Corporation for Assigned Names and Numbers|ICANN]], 20 juillet 2004</ref>.

En {{date||février|2008|en informatique}}, l'ICANN a ajouté des adresses IPv6 à six des treize [[Serveur racine du DNS|serveurs racine du DNS]]<ref>[http://www.zdnet.fr/actualites/l-icann-commence-a-convertir-les-serveurs-dns-a-l-ipv6-39378221.htm L'ICANN commence à convertir les serveurs DNS à l'IPv6]</ref> et « i » a été ajouté en 2010. D'autre part, en 2010, 228 des 283 [[Domaine de premier niveau|domaines de premier niveau]] disposent d'au moins un serveur avec une adresse IPv6<ref>{{en}} ''[http://ipv6.he.net/statistics/ Hurricane Electric Statistics]''</ref>. Les agents d'enregistrement doivent cependant mettre à jour leurs logiciels pour la prise en charge des délégations vers des serveurs IPv6 et les éventuels ''[[Domain Name System#Glue records|glue AAAA]]'' records<ref>{{en}} [http://www.sixxs.net/faq/dns/?faq=ipv6glue Which DNS Registrars allow me to add AAAA glue for my Domain Name Servers?] - Sixxs.net</ref>.

Les principaux serveurs de noms comme [[BIND]]v9 prennent en charge les records AAAA ainsi que le transport des requêtes sur IPv6.

La taille des paquets DNS en UDP est limitée à {{unité|512|octets}} ({{RFC|1035}}), ce qui peut poser des problèmes au cas où la réponse est particulièrement volumineuse. La norme prévoit alors qu'une connexion TCP est utilisée, mais certains pare-feux bloquent le port TCP 53 et cette connexion consomme plus de ressources qu'en UDP. Ce cas se pose notamment pour la liste de serveurs de noms de la zone racine. L'extension [[EDNS]]0 ({{RFC|2671}}) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.

=== Prise en charge d'IPv6 par les protocoles de routage ===
Les protocoles de routage comme [[Border Gateway Protocol|BGP]] ({{RFC|2545}}), [[Open shortest path first|OSPFv]]3 ({{RFC|5340}}), [[IS-IS]] ({{RFC|5308}}) et [[Multiprotocol Label Switching|MPLS]] ({{RFC|4798}}) ont été mis à jour pour IPv6.

=== Prise en charge d'IPv6 sur les couches liaison et transport ===
Les protocoles [[Transmission Control Protocol|TCP]] et [[User Datagram Protocol|UDP]] fonctionnent comme en IPv4. Le pseudo en-tête utilisé pour le calcul du code de contrôle est cependant modifié et inclut les adresses IPv6 source et destination. L'utilisation du code de contrôle est obligatoire également pour UDP. Des modifications mineures ont été apportées pour la prise en charge des paquets jumbo ({{RFC|2675}}).

Les protocoles de la couche de liaison de type [[IEEE 802]] sont adaptés pour le transport d'IPv6. Au niveau [[ethernet]] par exemple, la valeur du champ ''type'' attribué à IPv6 est 0x86DD ({{RFC|2464}}).

Sur les réseaux {{Lien|langue=en|trad=Nonbroadcast multiple-access network|fr=Nonbroadcast multiple-access|texte=NBMA}} comme [[X.25]] ou [[Relais de trames|Frame Relay]], des adaptations sont prévues pour permettre le fonctionnement du ''Neighbor Discovery''.

Le consortium {{Lien|langue=en|fr=CableLabs}} a publié les spécifications IPv6 qui concernent les modems câble dans [[DOCSIS]]v3.0 en {{date-|août 2006}}. Il n'y a pas de prise en charge IPv6 dans la version DOCSIS 2.0. Une version dite « DOCSIS 2.0 + IPv6 » existe cependant et ne nécessite qu'une mise à jour micrologicielle<ref>{{en}} [http://www.cablemodem.com/specifications/specifications20.html DOCSIS 2.0 Interface]</ref>.

Pour les technologies xDSL, la {{RFC|2472}} définit l'encapsulation de IPv6 sur PPP. Le [[Broadband Access Server|BRAS]] doit également prendre en charge IPv6.

En général, les équipements qui travaillent sur la [[couche de liaison]], comme les [[commutateur réseau|commutateurs ethernet]], n'ont pas besoin de mise à jour pour la prise en charge d'IPv6, sauf éventuellement pour le contrôle et la gestion à distance et l'optimisation de la diffusion multicast avec [[Multicast Listener Discovery|MLD snooping]].

Les systèmes d'accès doivent généralement être revus pour IPv6, les outils d'attribution des adresses et les bases de données d'enregistrement des adresses notamment.

=== Prise en charge d'IPv6 dans les systèmes d'exploitation et les logiciels ===
{{Article connexe | Support de l'IPv6 par système d'exploitation}}

Depuis le début du {{s-|XXI}}, tous les principaux systèmes d'exploitation ([[GNU/Linux]], [[Mac OS X]], [[Microsoft Windows]], [[Berkeley Software Distribution|BSD]], [[Solaris (système d'exploitation)|Solaris]], [[HP-UX]], etc.) ont été mis à jour pour la prise en charge d'IPv6, et c'est également le cas d'autres systèmes embarqués, tels que [[Symbian OS|Symbian]], [[QNX]], [[Android]], [[Microsoft Windows Mobile|Windows Mobile]] ou [[Wind River (entreprise)|Wind River]].

[[Microsoft Windows Vista|Windows Vista]] prend en charge IPv6 dans sa configuration par défaut, expose les réglages IPv6 dans l'interface graphique sur le même plan que les réglages IPv4, et utilise une nouvelle pile [[TCP/IP]] {{langue|en|''dual stack''}} au lieu d'une pile indépendante pour IPv6. Cette prise en charge sert de base à HomeGroup et DirectAccess dans [[Windows 7]].

Au niveau des [[routeur]]s, [[Cisco]] offre la prise en charge IPv6 depuis 2001 avec IOS 12.2, c'est également le cas des versions récentes de logiciels par principaux vendeurs comme [[Juniper Networks]], [[Alcatel-Lucent]] ou [[Redback Networks]].
<!-- pare-feu, load balancers -->

Certains [[Customer Premises Equipment|CPE]] restent cependant encore incompatibles avec IPv6, ce qui rend nécessaire la configuration de tunnels.

Les applications reliées au réseau doivent être modifiées pour être compatibles avec IPv6. L'ampleur de la mise à jour du [[code source]] varie en fonction de l'usage qui est fait des adresses par les applications. Il peut s'agir d'un remplacement simple mais aussi de modifications plus complexes si l'adresse est stockée dans une base de données ou est utilisée dans un contrôle d'accès.

Quand il n'est pas possible de mettre l'application à jour rapidement, des techniques de transition permettent à des applications IPv4 de communiquer avec des clients IPv6 :
* ''{{Langue|en|Bump in the Stack}}'' ({{RFC|2767}})
* ''{{Langue|en|Bump in the API}}'' ({{RFC|3338}}) - L'outil IPv6 CARE en fournit une implémentation pour les systèmes UNIX.

De nombreuses applications ont déjà été portées<ref>{{Lien web|langue=en|auteur=Peter Bieringer & all|url=https://www.deepspace6.net/docs/ipv6_status_page_apps.html|titre=Current Status of IPv6 Support for Networking Applications|date=11 février 2017}}</ref>
<!-- préciser les versions si possible -->
C'est en particulier le cas des [[navigateur web|navigateurs web]] comme [[Internet Explorer]] (depuis la version 7, partiellement pour la version 6), [[Mozilla Firefox]] (1.0), [[Opera]] (7.20b), [[Safari (navigateur web)|Safari]] et [[Google Chrome]], du client de messagerie [[Mozilla Thunderbird]] (1.0), serveur web [[Apache HTTP Server|Apache]] (1.3.27/2.0.43), du serveur de mail [[Exim]] (4.20), etc.
<!-- IIS, outlook, messagerie instantanée ? -->

=== Déploiement d'IPv6 chez les fournisseurs d'accès à Internet en France ===
[[Réseau national de télécommunications pour la technologie, l'enseignement et la recherche|Renater]] a commencé à expérimenter IPv6 en [[1996 en informatique|1996]] avec le réseau G6bone, le pendant français du réseau [[6bone]] mondial qui a démarré la même année. Ce réseau de test utilisait essentiellement des tunnels. Le service pilote IPv6 du réseau Renater 2 offre des connexions natives IPv6 sur [[Asynchronous Transfer Mode|ATM]] en 2002.

{| class="wikitable"
! scope="col" | [[Fournisseur d'accès à internet]]
! scope="col" | Date de déploiement
! scope="col" | Longueur du préfixe attribué
! scope="col" | [[Maximum transmission unit|MTU]]
! scope="col" | Notes
|-
| [[Nerim]] || {{date-|mars 2003}} || /48 || {{formatnum:1500}} en PPPoA, 1492 en [[PPPoE]] ||
|-
| [[Free (société)|Free]] || {{date-|décembre 2007}}<ref>[http://www.iliad.fr/presse/2007/CP_IPv6_121207.pdf communiqué de presse free (Iliad)] {{pdf}}</ref> || /61<ref>{{en}} [http://ripe58.ripe.net/content/presentations/ipv6-free.pdf IPv6 @ free, native IPv6 to the user] {{pdf}}</ref> || {{formatnum:1480}} en [[ADSL 2+|ADSL]] dégroupé, non disponible en non dégroupé || [[6rd]] en [[ADSL]]
|-
| [[French Data Network|FDN]] || {{date-|novembre 2008}} || /48 || {{formatnum:1492}} en [[PPPoE]] ||
|-
| [[SFR]] || fin 2011 (beta en {{date-|juin 2011}})
fin 2013 (FTTH)
|| /64<ref>[https://la-communaute.sfr.fr/c144-2-questions-techniques/f32-materiel/f126-neufbox-de-sfr-et-modem-routeur/t462529-vous-avez-des-questions-sur-l-ipv6-topic-de-centralisation.html la-communaute.sfr.fr]</ref> || ? || tunnel [[Layer 2 Tunneling Protocol|L2TP]]<ref>[http://newsroom.cisco.com/press-release-content?type=webcontent&articleId=358080 newsroom.cisco.com]</ref>
|-
| [[Numericable]] || début 2012 || ? || ? || [[DOCSIS]] 3.0<ref>{{Lien archive|url=http://www.pcinpact.com/news/65084-numericable-reseau-fttla-montee-debit.htm|title=Présentation du protocole et des zones qui devrait être couverte d'ici fin 2012|site=[[Next (site web)|pcinpact.com]]|horodatage archive=20111111152855}}</ref>
|-
| [[OVH]] || mi-2012 || /56 || {{formatnum:1500}} en IPoE (dégroupé), {{formatnum:1492}} en PPPoE || délégation de préfixe ({{RFC|3633}}) par [[DHCPv6]]<ref>http://www.ovh.fr/adsl/fiche_technique_no_tv.xml</ref>
|-
| [[Orange (entreprise)|Orange]] || tests de Wanadoo en 2005 ; proposé en offre sur mesure depuis 2010 sur le marché entreprise sous la marque [[Orange Business Services]], tests internes depuis {{date-|juillet 2014}}, le déploiement IPv6 pour le grand public a commencé depuis début 2016 pour les clients fibre et VDSL<ref>{{Lien web|titre=Le déploiement de l’IPv6 démarre chez Orange !|url=https://communaute.orange.fr/t5/Orange-et-Vous/Le-d%25C3%25A9ploiement-de-l-IPv6-d%25C3%25A9marre-chez-Orange/ba-p/857401|date=2016-02-04|consulté le=2016-07-01}}</ref>. || /56 || {{formatnum:1500}} || La Livebox Play est annoncé comme compatible IPv4 et IPv6.
Délégation de préfixe possible.
|-
| [[Bouygues Telecom]] || prévu pour l'ADSL dégroupé en 2017<ref>{{lien web |titre=IPv6 chez Bouygues... |url=https://lafibre.info/bbox-les-news/ipv6-chez-bouygues/msg382659/#msg382659 |site=lafibre.info |consulté le=10-04-2023}}.</ref>, le FTTH en 2018 || /60<ref>[https://lafibre.info/bbox-les-news/ipv6-chez-bouygues/msg382679/#msg382679]</ref>|| {{formatnum:1500}} || délégation de préfixe IPv6 sur la Bbox en 2018<ref>[https://lafibre.info/bbox-les-news/ipv6-chez-bouygues/msg386216/#msg386216]</ref>
|-
| [[Zeop]] || {{date-|22 juillet 2014}} || /56 || {{formatnum:1500}} || {{refnec|Premier opérateur IPv6 à la Réunion}}
|-
| [[Quantic Telecom]]|| 2013 || /48<ref>{{lien web |titre=Quantic Telecom on Twitter |url=https://twitter.com/QuanticTelecom/status/310469912143474688 |site=[[Twitter|twitter.com]] |consulté le=09-09-2020}}.</ref> ||? ||?
|-
|[[K-Net]]
|2012
|/56
|{{formatnum:1500}}
|-
| [[Orne THD]]|| 2019 || /56 || {{formatnum:1500}} || Premier opérateur à avoir activé IPv6 à 100% chez tous les clients<ref>{{Lien web |langue=fr |titre=Les opérateurs ayant entre 5 000 et 3 millions de clients sur le réseau fixe |url=https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html#c22704 |date= |site=arcep.fr }}. </ref>
|-
|VIALIS
|2020
|/32
|1500
|Vialis a débuté sa transition en 2020 et avait déjà activé l'IPv6 auprès de 88% en 2021 puis 91 % en 2022.
|}

D'après le bilan annuel de l'ARCEP, de 2019, les quatre principaux opérateurs français (Bouygues Telecom, Free, Orange, SFR) ont déjà affecté entre environ 94% et 99% des adresses IPv4 qu’ils possèdent, à fin {{date-|juin 2019}}<ref name=barometre>{{Lien web |langue=fr |titre= Baromètre annuel de la transition vers IPv6 en France|url=https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/transition-ipv6/barometre-annuel-de-la-transition-vers-ipv6-en-france.html|date= |site=arcep.fr }}.</ref>.

{|
|-
| {{Graph:Chart |width=300 |height=100
|xAxisTitle=Stock
|yAxisTitle=Année
|legend=Stock d'adresse IPv4 en France
|type=rect
|x=2015, 2016, 2017, 2018, 2019, 2020, 2021
|y1=16,15,10,
|y2=,,7,4,1,0
|y1Title=Réel
|y2Title=Estimé
|colors=#80212100,#80ff8000
|showValues=
|xGrid=1
}}
|-
|Sources : Arcep<ref name=barometre/>
|}

{|
|-
| {{Graph:Chart |width=300 |height=100
|xAxisTitle=Opérateur
|yAxisTitle=%
|legend=Clients activés en IPv6, par opérateur
|type=rect
|x=juin 2018
|y1=2.5
|y2=50
|y3=45
|y4=0.9
|y1Title=Bouygues
|y2Title=Free
|y3Title=Orange
|y4Title=SFR
|colors=#c06060aa,#c0a2606a,#c0b19100,#80a12100,#80a200aa,#80ff8000,
|showValues=
|yGrid=1
}}
|-
|Sources : Arcep<ref name=barometre/>
|}

=== Déploiement d'IPv6 chez les fournisseurs d'accès à Internet en Suisse ===

En [[Suisse]], outre l'exploitant des réseaux des universités, [[Switch (fondation)|Switch]], plusieurs opérateurs alternatifs ont déployé IPv6 pour leurs clients résidentiels dès la normalisation du protocole, l'un des plus importants étant Init7.

L'opérateur historique, [[Swisscom]], a mené des expériences de déploiement en 2003 et 2004 dans le cadre de la Swiss IPv6 Task Force dont il assurait la direction, mais seul le réseau international de la société (IP-Plus) a conservé IPv6 en production. En 2011, Swisscom a initié<ref>[http://labs.swisscom.ch/fr/node/692/ Swisscom Labs IPv6 Trial]</ref> un pilote ouvert à tous ses clients pour le déploiement d'IPv6 résidentiel via la technologie [[6rd]], chaque client disposant d'un /60 pour son usage personnel.

Les autres grands opérateurs suisses, à savoir Sunrise, Cablecom, et Orange n'ont pas encore annoncé officiellement de plans en {{date-|juillet 2011}}, mais France Telecom avait annoncé<ref>[http://ripe59.ripe.net/presentations/jacquenet-france-telecom-v6.pdf RIPE 59, Stratégie IPv6 de France Télécom] {{pdf}}</ref> en octobre 2009 utiliser la Suisse comme pays pilote pour ses déploiements.

=== Déploiement d'IPv6 en Europe ===
En 2000, le programme 6INIT permet l'interconnexion des [[réseau national de la recherche et de l'enseignement|réseaux nationaux de la recherche et de l'enseignement]] (NREN) européens grâce à des [[Circuit virtuel|PVC]] IPv6 sur ATM à travers le réseau de recherche européen [[DANTE|TEN 155]]<ref>{{en}} [http://www.ec.ipv6tf.org/index.php?page=news/newsroom&id=23&id_others=64 6INIT]</ref>.

En 2003, le réseau [[GÉANT2|GÉANT]], qui succède à TEN 155, utilise une double [[Pile (informatique)|pile]] (IPv4 + IPv6). Dix-huit des NREN sont connectés nativement en IPv6.

La Commission européenne s'est fixé comme objectif de recevoir des engagements des 100 principaux opérateurs de sites web de l'Union européenne avant la fin de l'année 2008 et a publié un plan d'action<ref>[http://ec.europa.eu/information_society/newsroom/cf/document.cfm?action=display&doc_id=479 Plan d’action pour le déploiement d'IPv6 en Europe]</ref> en {{date-|mai 2009}}.

En [[2010]], le [[RIPE NCC]] (Europe) est la région qui annonce le plus grand nombre de préfixes IPv6<ref>[http://www.sixxs.net/tools/grh/dfp/ Ghost Route Hunter : IPv6 DFP visibility]</ref>.

Le projet ''IPv6 Ripeness''<ref>{{en}} [http://labs.ripe.net/content/ipv6-ripeness IPv6 Ripeness] - [[RIPE]]</ref> du [[RIPE]] vise à observer le déploiement d'IPv6 en Europe en attribuant des étoiles aux [[Local Internet Registry|registres Internet locaux]] quand certains indicateurs de déploiement sont atteints. Les étoiles sont attribuées pour chacun des critères suivants :
* une allocation IPv6,
* le bloc d'adresse IPv6 est visible dans la table de routage Internet,
* le bloc fait l'objet d'un enregistrement ''route6'' dans la base de données du RIPE,
* la zone [[Domain Name System|DNS]] inverse correspondant au bloc est déléguée.

En {{date-|janvier 2013}}, 57 % des [[Local Internet Registry|LIR]] ont obtenu un bloc d'adresse IPv6, et 19 % ont atteint le niveau le plus élevé de quatre étoiles<ref>[http://ipv6ripeness.ripe.net/pies.html IPv6 ripeness country pie charts]</ref>.
{|
|{{Diagramme circulaire
| thumb     = right
| caption   = Résultat de l'enquête ''{{Langue|en|IPv6 Ripeness}}'' du [[RIPE]] en avril 2010, sur {{formatnum:6748}} registres locaux.
| autre     = 
| label1    = Pas d'IPv6
| valeur1   = 72.3
| couleur1  = #FF0000
| label2    = 1 étoile
| valeur2   = 9.5
| couleur2  = #0000FF
| label3    = 2 étoiles
| valeur3   = 4
| couleur3  = #00B200
| label4    = 3 étoiles
| valeur4   = 5.9
| couleur4  = #EAEA00
| label5    = 4 étoiles
| valeur5   = 8.3
| couleur5  = #AA4CAA
}}
||
{{Diagramme circulaire
| thumb     = right
| caption   = Résultats en juin 2015 sur {{formatnum:11813}} registres locaux.
| autre     = 
| label1    = Pas d'IPv6
| valeur1   = 24
| couleur1  = #FF0000
| label2    = 1 étoile
| valeur2   = 30
| couleur2  = #0000FF
| label3    = 2 étoiles
| valeur3   = 9
| couleur3  = #00B200
| label4    = 3 étoiles
| valeur4   = 15
| couleur4  = #EAEA00
| label5    = 4 étoiles
| valeur5   = 21
| couleur5  = #AA4CAA
}}
|}

En France en 2021, 50% des utilisateurs sont sous IPv6<ref>{{lien web |auteur=Amélie CHARNAY |titre=L'IPv6 progresse mais encore trop lentement en France |url=https://www.01net.com/actualites/l-ipv6-progresse-mais-encore-trop-lentement-en-france-2051979.html |site=01net.com |date=01-12-2021 |consulté le=10-04-2023}}.</ref>.
En France en 2021, 29% des 30 serveurs français les plus utilisés sont sous IPv6<ref>{{lien web |titre=Une transition vers IPv6 encore bien insuffisante |url=https://www.generation-nt.com/ipv6-transition-arcep-fixe-mobile-hebergeur-actualite-1995302.html |site=Génération NT |consulté le=10-04-2023}}.</ref>.

En 2021, la France est le quatrième utilisateur d'IPv6 à l'échelle européenne. La France est le sixième utilisateur d'IPv6 à l'échelle mondiale<ref name=barometre/>.

L’Europe de l’Ouest, avec 47% d’utilisation d’IPv6 fait partie des trois régions les plus avancées dans la transition vers IPv6.
L’Europe de l’est (11%), l’Europe du sud (9%) font partie des trois ou quatre régions les plus en retard dans le déploiement d’IPv6<ref name=barometre/>.

=== Déploiement d'IPv6 dans le monde ===
[[Fichier:Rir-ipv6-allocation-rate.svg|thumb|upright=1.3|Nombre mensuel d'allocations de blocs IPv6 par chacun des RIR depuis 1999.]]
{{Diagramme circulaire
| thumb     = right
| caption   = Répartition de la taille des allocations de blocs IPv6 aux registres Internet régionaux en 2012 (source OCDE). Il y avait plus de 17000 allocations à ce moment<ref>{{Lien web|url=https://books.google.fr/books?id=MRQMAAAAQBAJ&pg=PA146&lpg=PA146#v=onepage&q&f=false|titre=OECD Communications Outlook 2013}}</ref>.
| autre     = 
| label1    = APNIC
| valeur1   = 23
| couleur1  = #EAEA00
| label2    = AfriNIC
| valeur2   = 2.5
| couleur2  = #FFA023
| label3    = RIPE NCC
| valeur3   = 24
| couleur3  = #0000FF
| label4    = LACNIC
| valeur4   = 40
| couleur4  = #00B200
| label5    = ARIN
| valeur5   = 11
| couleur5  = #FF0000
}}

En 1996, le réseau de test [[6bone]] a permis les expérimentations de la technologie IPv6 ({{RFC|2471}}). Ce réseau était construit sur des tunnels, et les routes échangées par le protocole [[Border Gateway Protocol|BGP4+]]. Les participants se voyaient octroyer un préfixe /24, /28 ou /32 dans le bloc 3ffe::/16<ref>{{Lien web|url=http://www.go6.net/ipv6-6bone/6bone_pTLA_list.html|titre=Liste des pTLA 6bone}}</ref>. Le réseau a été démantelé en 2006 ({{RFC|3701}}) au profit de connexions natives.

{{quand|Aujourd'hui}}, de nombreux [[Serveur HTTP|serveurs web]] acceptent les connexions via IPv6<ref>{{Lien web|langue=en |url=http://sixy.ch/|titre=Sixy.ch}}</ref>. [[Google]] est par exemple accessible en IPv6 depuis {{date-|mars 2008}}<ref>{{Lien web|langue=en|url= http://www.google.com/intl/en/ipv6/ |titre=Google over IPv6.}}</ref>, c'est également le cas de [[YouTube]] et [[Facebook]] depuis 2010.

Existent également des serveurs en IPv6 proposant des services courants, tels que [[File Transfer Protocol|FTP]], [[Secure Shell|SSH]], [[SMTP]], [[Internet Message Access Protocol|IMAP]] ou [[Internet Relay Chat|IRC]].

En 2009, plusieurs opérateurs mondiaux ont commencé à déployer IPv6<ref>{{Lien web|langue=en|url=http://www.networkworld.com/news/2009/061809-comcast-ipv6.html?hpg1=bn |titre=Comcast open for IPv6 business, juin 2009|éditeur=Networkworld.com}}</ref>{{,}}<ref>{{Lien web|langue=en|url=http://www.networkworld.com/news/2009/061009-verizon-lte-ipv6.html?fsrc=netflash-rss |titre=LTE devices must support IPv6, says Verizon, juin 2009|éditeur=Networkworld.com}}</ref>{{,}}<ref>{{Lien web|langue=en|url=http://www.networkworld.com/news/2008/040208-ipv6-carrier-services.html |titre=U.S. carriers quietly developing IPv6 services, avril 2008|éditeur=Networkworld.com}}</ref>.

Au [[Japon]], [[Nippon Telegraph and Telephone|NTT]] commercialise différentes offres de services IPv6<ref>{{en}} [http://www.v6.ntt.net/index_e.html {{langue|en|''NTT Com — IPv6 Global Community — IPv6 Top''}}]</ref> et commercialise également le {{langue|en|''[[Flet's phone]]''}}.

Les règlements des marchés publics rendent la prise en charge d'IPv6 obligatoire, notamment dans les États de l'[[Union européenne]] et aux [[États-Unis]]<ref>[http://www.french.xinhuanet.com/french/2008-05/28/content_641389.htm L'UE encourage l'utilisation du nouveau protocole Internet IPv6], mai 2008</ref>.

Aux États-Unis, [[Comcast]] a commencé<ref>[http://www.comcast6.net/ Les tests IPv6 de Comcast]</ref> en 2010 des tests de diverses technologies autour d'IPv6, sur son réseau de production, en prévision du déploiement définitif et de l'épuisement des adresses [[IPv4]]. IPv6 est également utilisé par le [[Département de la Défense des États-Unis|département de la défense]] des États-Unis d'Amérique.

La Chine populaire considère avec intérêt l'IPv6. Elle vise à un début d'utilisation commerciale de l'IPv6 à partir de 2013, et à une utilisation et une interconnexion plus large d'ici 2015<ref>{{lien web |titre=人民网--404页面 |url=http://french.peopledaily.com.cn/Economie/7686884.html |site=french.peopledaily.com.cn |consulté le=10-04-2023}}.</ref>. Les adresses IPv6 chinoises ne représentent que 0,29 % des adresses IPv6 mondiales<ref>{{lien web |titre=人民网--404页面 |url=http://french.peopledaily.com.cn/Sci-Edu/7688106.html |site=french.peopledaily.com.cn |consulté le=10-04-2023}}.</ref>, en 2011. Alors que la Chine est à la troisième place à un niveau mondial<ref>
http://www1.cnnic.cn/html/Dir/2012/08/31/6060.htm</ref>.

IPv6 s'impose parfois comme unique moyen d'interconnexion avec les terminaux mobiles itinérants en [[Asie]] ; il le sera aussi rapidement en [[Europe]] quand les anciennes solutions d'interconnexion basées sur les protocoles [[Global System for Mobile Communications|GSM]] devront être remplacées par des solutions IP. De plus, l'évolution des usages mobiles allant vers une connectivité IP permanente, il deviendra alors très difficile d'adresser un nombre très important de terminaux mobiles ([[smartphone]]s), avec un adressage IPv4 (même avec NAT).

Un rapport de l'[[Organisation de coopération et de développement économiques|OCDE]] publié en {{date-|avril 2010}}<ref name="ocde">[http://www.oecd.org/dataoecd/48/51/44953210.pdf Internet Addressing: Measuring deployment of IPv6], OCDE, avril 2010 {{pdf}}</ref> indique que le niveau d'adoption d'IPv6 est encore faible, avec de 0,25 à 1 % des utilisateurs qui font usage d'IPv6. Le trafic IPv6 natif représente 0,3 % du trafic de l'[[AMS-IX]]. À la fin de l'année 2009, {{formatnum:1851}} numéros d'[[Autonomous System|AS]] IPv6 étaient visibles, ce nombre ayant doublé en deux ans.

En {{date-|décembre 2010}}, Google estime que le nombre d'utilisateurs IPv6 de son service de recherche Internet serait de 0,25 % environ<ref name="Googleipv6stats" />.

==== Le cas de Wikipédia ====
Les équipes de Wikipédia préparent cet aspect technique depuis 2008<ref>{{en}} [http://www.personal.psu.edu/dvm105/blogs/ipv6/2008/04/wikipedias-foray-into-ipv6.html www.personal.psu.edu]</ref>{{,}}<ref>{{en}} [http://features.techworld.com/networking/3212045/where-do-web-giants-stand-on-ipv6/ features.techworld.com]</ref>{{,}}<ref>{{en}} [http://www.personal.psu.edu/dvm105/blogs/ipv6/2008/08/ipv6-going-mainstream-little-b.html www.personal.psu.edu]</ref>, après une tentative en 2006<ref>{{en}} http://toolserver.org/~river/pages/projects/ipv6</ref>. Une page de suivi a été créée pour en suivre l'évolution<ref>{{en}} http://wikitech.wikimedia.org/view/IPv6_deployment</ref>.

Après une participation de la fondation à la journée de test de 2011<ref>{{en}} [http://meta.wikimedia.org/wiki/Translation_of_the_week/2012_translations/Archive#en:World_IPv6_Day meta.wikimedia.org]</ref>. Wikipedia permet à ses utilisateurs de profiter pleinement de ses services à l'aide de l'IPv6<ref>{{lien web |langue=en |titre=Initiative IPv6/ Jour de l'annoncement de l'IPv6 2012 |url=http://meta.wikimedia.org/wiki/IPv6_initiative/2012_IPv6_Day_announcement/fr |site=wikimedia.org |consulté le=10-04-2023}}.</ref>{{,}}<ref>{{en}} http://bugzilla.wikimedia.org/show_bug.cgi?id=35540</ref> lors de la journée de lancement<ref>{{en}} http://blog.wikimedia.org/2012/08/02/engineering-july-2012-report/</ref>{{,}}<ref>{{en}} http://www.worldipv6launch.org/participants/?q=1</ref>.

==== Journée mondiale IPv6 ====
[[Fichier:World IPv6 launch logo.svg|thumb|Logo de la journée mondiale du lancement IPv6 du 6 juin 2012.]]
Le {{date-|8 juin 2011}} l'[[Internet Society]] (ISOC) a organisé une journée mondiale IPv6 pendant laquelle les fournisseurs et les sites ont été encouragés à tester la technologie à grande échelle<ref>[http://isoc.org/wp/worldipv6day World IPv6 Day]</ref>.
Google, Facebook, [[Yahoo!]], [[Akamai]] et [[Limelight Networks]] ont participé à cet événement.
Google a estimé que 99,95 % des utilisateurs ne seraient pas affectés par ce test<ref>{{en}} [http://googleblog.blogspot.com/2011/01/world-ipv6-day-firing-up-engines-on-new.html World IPv6 day : firing uo engines on the new Internet protocol], Google 21 janvier 2011</ref>. Des statistiques présentées par Yahoo montrent que 0,022 % des utilisateurs de leur site ont été affectés, {{Pas clair|tandis que 0,229 % ont utilisé IPv6|Peu compréhensible alors que 0,022 % ont été affecté|date=août 2023}}<ref>[http://www.nanog.org/meetings/nanog52/presentations/Monday/Gashinsky-Y-w6d_v5.pdf World IPv6 Day Debrief], Yahoo, [[North American Network Operators' Group|NANOG]] 52, 13 juin 2011 {{pdf}}</ref>.

==== Évolution législative ====
En France, la [[loi pour une république numérique]] prévoyait de rendre obligatoire la compatibilité avec l'IPv6 des produits vendus à partir du {{date-|1 janvier 2018}}<ref>https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=7E2504406D54E4B63CDEE065E4ABD3A5.tpdila17v_1?cidTexte=JORFTEXT000033202746&categorieLien=id</ref>. Cependant, l'article n°42 qui imposait cette obligation a été abrogé par une nouvelle loi en 2020<ref>https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000042624546 </ref>.

=== Freins au déploiement d'IPv6 ===
==== Critiques opérationnelles ====
Certains, comme Randy Bush, ont critiqué la façon dont la phase de transition vers IPv6 a été élaborée, en indiquant que les difficultés et les coûts de la transition ont été minimisés, que les adresses IPv6 sont distribuées de façon trop généreuse, que le niveau actuel de trafic ne permet pas d'affirmer que les routeurs sont capables des mêmes performances qu'avec IPv4, que l'adaptation des protocoles est incomplète (notamment [[Simple Network Management Protocol|SNMP]] et les pare-feu) et que les bénéfices escomptés (en termes d'élimination de NAT et d'agrégation de la table de routage Internet) ont été surestimés<ref>{{en}} [http://www.iepg.org/2007-07-ietf69/070722.v6-op-reality.pdf IPv6 Transition & Operational Reality] - Randy Bush, IEPG / Chicago, juillet 2007 {{pdf}}</ref>.

D'autre part, certains systèmes d'exploitation qui disposent d'une double pile sans toutefois disposer de connectivité IPv6 fonctionnelle peuvent créer des délais anormaux lors de l'accès à des serveurs qui disposent à la fois d'une adresse IPv6 et d'une adresse IPv4<ref>{{en}} [http://fud.no/ipv6/ IPv6 dual-stack client loss in Norway]</ref>, l'adresse IPv6 étant utilisée en priorité avant de recourir à l'adresse IPv4 après un délai déterminé.

En 2011, la politique de ''peering'' de certains fournisseurs d'accès aboutit au partitionnement de l'Internet IPv6. Les utilisateurs de Hurricane Electric (AS 6939) ne peuvent pas communiquer avec ceux de Cogent (AS 174) ni ceux de Level 3 (AS 3356) par exemple. Ce problème affecte occasionnellement aussi l'Internet IPv4<ref>{{en}} [http://labs.ripe.net/Members/emileaben/measuring-world-ipv6-day-glitches-and-lessons-learned Measuring World IPv6 Day - Some Glitches And Lessons Learned], RIPE NCC, 28 juin 2011</ref>{{,}}<ref>{{en}} [http://www.datacenterknowledge.com/archives/2009/10/22/peering-disputes-migrate-to-ipv6/ Peering Disputes Migrate to IPv6], 22 septembre 2009</ref>.

==== Freins au déploiement ====
Les freins au déploiement d'IPv6 sont, entre autres, les suivants :
* Pour les équipements anciens :
** Le fabricant a cessé ses activités ;
** Le fabricant ne fournit pas de mise à jour pour IPv6 ou réclame des prix élevés pour le faire;
** La mise à jour logicielle est impossible (le code étant en [[mémoire morte]]) ;
** L'équipement n'a pas les ressources requises pour le traitement d'IPv6 ;
** IPv6 est disponible mais avec des performances dégradées.
* Pour les équipements récents :
** Le prix de vente est plus élevé pour le consommateur ;
** {{refnec|Le développement de logiciel compatible IPv6 est coûteux}}:  {{citation bloc|les coûts liés au déploiement sont exclusivement à la charge des réseaux qui déploient l’IPv6. En effet, ils doivent faire des investissements en infrastructure et de formation, et subir des coûts de compatibilité. Les autres réseaux qui choisissent de rester sur l’IPv4 doivent payer seulement pour des numéros supplémentaires, et seulement s’ils en ont besoin pour leur développement.|developpez<ref>{{lien web |titre=La proportion mondiale d'utilisation de l'IPv6 toujours en dessous de la barre des 35% selon Google, la France note 40,19% d'adoption sur son… |url=https://reseau.developpez.com/actu/307792/La-proportion-mondiale-d-utilisation-de-l-IPv6-toujours-en-dessous-de-la-barre-des-35-pourcent-selon-Google-la-France-note-40-19-pourcent-d-adoption-sur-son-territoire/ |site=Developpez.com |consulté le=10-04-2023}}.</ref>}}
* L'indifférence des utilisateurs finaux :
** Les utilisateurs ne manifestent pas d'intérêt à défaut de nécessité ;
** Les applications fonctionnent correctement en IPv4 actuellement ;
** La formation à la nouvelle technologie coûte cher.

Concernant le développement de la prise en charge IPv6 chez les fournisseurs de contenu et d'accès, on compare parfois le problème à celui de l'œuf et de la poule<ref>{{en}} [http://www.ripe.net/ripe/meetings/ripe-57/presentations/Colitti-A_strategy_for_IPv6_adoption.Z8ri.pdf A strategy for IPv6 adoption], présentation Google au RIPE 57 {{pdf}}</ref> :
* Les fournisseurs d'accès disent qu'il n'y a pas de contenu disponible spécifiquement en IPv6 ;
* Les fournisseurs de contenu disent qu'il n'y a pas de demande.

Selon une étude publiée en {{date-|octobre 2009}}<ref>{{en}} [http://www.ripe.net/ripe/meetings/ripe-59/presentations/botterman-v6-survey.pdf IPv6 deployment survey] RIPE 59, juin 2009 {{pdf}}</ref>, les fournisseurs identifient les points suivants comme les principaux obstacles :
* Les coûts ;
* La prise en charge par les fabricants ;
* L'absence de rentabilité ;
* Le manque de familiarité.

Les principaux facteurs de développement sont :
* Tenir le rôle de précurseur ;
* S'assurer que les produits sont compatibles IPv6 ;
* Désir de profiter des avantages d'IPv6 dès que possible ;
* Prévoir l'épuisement des adresses IPv4.

Concernant les problèmes rencontrés par les FAI qui ont déployé IPv6 :
* Le manque de demande de la part des utilisateurs ;
* Le manque de familiarité avec la technologie.

==== IPv6 dans les produits destinés au public ====
{{section à sourcer|date=décembre 2011}}
{{refnec|En général, les produits du marché destinés au grand public n'ont pas de possibilité de mise à jour.}}

En 2014, la prise en charge d'IPv6 n'est pas encore un critère de choix pour le consommateur final. Quand une application majeure ne sera plus accessible en IPv4, l'importance de ce critère sera sans doute revue. Les entreprises sont cependant plus attentives à ce problème et évitent d'investir dans des équipements qui pourraient s'avérer incompatibles avec IPv6.

Les clients ne disposant que d'une adresse IPv6 pourraient apparaître vers 2014, le problème de la connectivité vers les serveurs Internet qui ne disposent que d'une adresse IPv4 se posera concrètement dès lors pour les clients internet qui ne sont pas dotés d'une double pile (adresses IPv4 et IPV6). L'accès aux serveurs IPv6 depuis des clients IPv4 présente également un défi technique.

Ainsi, des problèmes sont {{quand|déjà}} visibles concernant notamment les accès [[Internet mobile]], qui souvent n'attribuent que des adresses IPv4 privées non routables, mais connectées à des serveurs proxy HTTP fournis par l'opérateur de réseau d'accès, avec des performances parfois décevantes et des problèmes de restriction des protocoles de communication supportés par ce type de tunnels mais aussi de stabilité des sessions temporaires. D'autres solutions utilisant un [[Network address translation|NAT]] dynamique connaissent un autre problème lié à la famine des [[Port TCP|ports]] disponibles dans les routeurs NAT partagés par plusieurs clients IPv4 pour une utilisation optimale avec les applications de plus en plus interactives du web actuel et qui nécessitent de nombreux ports pour chaque utilisateur; les autres solutions basées sur la traduction de protocole dans un tunnel (6to4 ou Teredo) posent également des problèmes similaires de performance et de coût de mise en œuvre, que seul un déploiement en IPv6 natif pourrait résoudre avec un meilleur compromis entre performances, coût de mise en œuvre et coûts d'exploitation : puisque déjà des problèmes très fréquents{{référence souhaitée}} existent sur les accès mobiles [[3G]], et sont constatés par les clients de ces réseaux même pour une utilisation très modérée{{référence souhaitée}} (alors que le coût d'accès est déjà élevé), le passage au palier suivant des réseaux [[4G]]+ ([[LTE (réseaux mobiles)|LTE]] par exemple) ne pourra pas être économiquement viable sans un passage au routage IPv6 natif{{refnec}}, sans tunnel ni proxy d'adaptation chaque fois que possible (de nombreuses applications et sites web devront être adaptés pour être accessibles directement en IPv6, sans nécessiter ces adaptations, si elles désirent conserver des performances acceptables pour leurs clients sans accès IPv4 natif).

Bien que certains équipements n'auraient besoin que d'une mise à jour de [[micrologiciel]] pour IPv6, il n'est pas certain que leurs fabricants investiront dans cette voie alors que la vente de produits ''IPv6 Ready'' s'avérerait plus rentable.

== Notes et références ==
{{Références}}

=== Exemple ===
{{Références|groupe=Ex}}

== Voir aussi ==
=== Articles connexes ===
* [[Adresse IP]] - format des adresses, masques réseaux, CIDR.
* [[Adresse IPv6]] - format d'une adresse IPv6
* [[Histoire d'IPv6]] - l'évolution du protocole
* [[Transition d'IPv4 vers IPv6]] - les technologies permettant à des paquets IPv6 d'être transmis à travers un réseau [[IPv4]]

=== Liens externes ===
* [http://www.g6.asso.fr/ Association pour la promotion et le développement d’IPv6 (G6)]
* [http://www.certa.ssi.gouv.fr/site/CERTA-2006-INF-004/CERTA-2006-INF-004.html Migration IPv6 : enjeux de sécurité] - Note d'information du [[Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques|CERTA]]

;Tests et statistiques
* [http://www.adresse-ip.fr/test-ipv6-site.php Test de la compatibilité IPv6 d’un site Web]
* {{en}} [http://test-ipv6.com/ Test de connectivité IPv6]
* {{de}} [http://www.allesedv.at/IPv6/tld/.fr Principaux hôtes disponibles en IPv6 dans le TLD.fr]

{{Palette|Modèle OSI}}
{{Portail|informatique|internet|Télécommunications}}

[[Catégorie:IPv6|*]]
[[Catégorie:TCP/IP]]
[[Catégorie:Protocole réseau sur la couche réseau]]