| Modèle Internet Modèle OSI |
IPv6 (Internet Protocol version 6) est un protocole réseau sans connexion de la couche 3 du modèle OSI.
IPv6 est l'aboutissement des travaux menés au sein de l'IETF à la fin des années 1990 pour succéder à IPv4 dont la capacité d'adressage est insuffisante. En 2010, en dépit de l'imminent épuisement des adresses IPv4, le déploiement d'IPv6 est encore limité.
Distribution de l'espace d'adressage IPv4 en août 2010.
Épuisement des adresses IPv4 entre 1995 et 2010. En août 2010, il reste 14 blocs /8 libres.
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 multicast ou les 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 classes, des blocs de 16 millions d'adresses (Classe A), 65 536 (Classe B) ou 256 adresses (Classe C) sont attribués aux demandeurs, parfois bien au-delà des besoins réels. Les premières grandes organisations connectées à Internet se sont vues attribuer 16 millions d'adresses par exemple.
Au début des années 1990, devant l'épuisement de l'espace d'adressage, notamment des réseaux de classe B (RFC 1338), les registres Internet régionaux font leur apparition et le découpage des adresses en classe est aboli au profit du plus flexible 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 adresses privées, de la 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.
En août 2010, on estime que l'Internet Assigned Numbers Authority (IANA) assignera le dernier bloc /8 libre à un registre Internet régional (RIR) en juin 2011. Les RIR épuiseront les allocations d'adresses IPv4 pour les registres Internet locaux en février 2012. En juin 2010, l'IANA indique qu'il est possible que les blocs libres soient épuisés dès la fin de l'année en raison d'une demande importante observée dans la région Asie-Pacifique au début de l'année.
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 :
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). En 1993, l'IETF lance un appel à propositions (RFC 1550) et annonce la création d'un groupe de travail IP Next Generation (IPng).
D'abord nommé Simple Internet Protocol Plus (SIPP, RFC 1710), puis IP Next Generation (IPng), celui-ci a été choisi en 1994 parmi plusieurs candidats et a reçu en 1995 son nom définitif d'IPv6 (IP version 6). Les spécifications d'IPv6 sont initialement publiées en décembre 1995 dans la RFC 1883 et finalisées dans la RFC 2460 en décembre 1998.
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 ».
Une adresse IPv6 est longue de 128 bits, soit 16 octets, contre 32 bits pour IPv4. La 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 hexadécimale, où les 8 groupes de 2 octets (16 bits par groupe) sont séparés par un signe deux-points :
2001:0db8:0000:85a3:0000:0000:ac1f:8001
On peut omettre les zéros à gauche dans chaque groupe, et remplacer une seule séquence de zéros par un signe « :: ». L'adresse peut être abrégée en :
2001:db8:0:85a3::ac1f:8001
Les réseaux sont notés en utilisant la notation CIDR : la première adresse du réseau est suivie par une barre oblique et un nombre qui indique la taille en bits du réseau. La partie commune des adresses est appelée préfixe. Par exemple :
Certains préfixes d'adresses IPv6 jouent des rôles particuliers :
| Préfixe | Description |
|---|---|
| ::/8 | Adresses réservées |
| 2000::/3 | Adresses unicast routables sur Internet |
| fc00::/7 | Adresses locales uniques |
| fe80::/10 | Adresses locales lien |
| ff00::/8 | Adresses multicast |
Parmi les adresses réservées :
Parmi les adresses de 2000::/3 sont distinguées :
Structure de l'adresse IPv6 unicast globale
| champ | préfixe | sous-réseau | interface |
|---|---|---|---|
| bits | 48 | 16 | 64 |
Le préfixe 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 (RFC 3587).
Scope
Le scope d'une adresse IPv6 consiste en son domaine de validité et d'unicité.
On distingue :
Toutes les interfaces où IPv6 est actif ont au moins une adresse de scope link-local (fe80::/10).
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) qu'on ajoute à l'adresse après un signe pourcent : fe80::3%eth0 correspondra à l'adresse link-local fe80::3 sur l'interface eth0 par exemple.
Attribution des adresses IPv6
Dans l'espace d'adresse unicast global (2000::/3), l'IANA assigne des blocs /23 au registres Internet régionaux, comme le RIPE NCC en Europe. Ces derniers distribuent des préfixes /32 aux registres Internet locaux (FAI) qui les assignent ensuite sous forme de bloc /48 ou /64 à leurs clients.
Chaque client se voit attribuer soit un bloc /64 (un seul sous-réseau), soit un bloc /48 (65 536 sous-réseaux), chacun des sous-réseaux pouvant accueillir un nombre d'hôtes virtuellement illimité (2). Dans le bloc 2000::/3 qui représente 1/8 de l'espace d'adressage disponible en IPv6, on peut donc créer 2, soit 500 millions de blocs /32 pour des fournisseurs d'accès à Internet, et 2, soit 35 milliards de réseaux d'entreprise.
En-tête IPv6.
En-tête IPv4.
L'en-tête du packet IPv6 est de taille fixe à 40 octets, tandis qu'en IPv4 la taille minimale est de 20 octets, des options pouvant la porter jusqu'à 60 octets, ces options demeurant rares en pratique.
La signification des champs est la suivante :
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
En IPv4, les routeurs qui doivent transmettre un paquet dont la taille dépasse le 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 ICMPv6 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é 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 à 1 280 octets (contre 576 pour l'IPv4). 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 65535 octets. IPv6 dispose cependant d'une option jumbo (RFC 2675) permettant de porter la taille maximale d'un paquet à 4 Go et profiter ainsi des réseaux avec un MTU plus élevé.
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 :
| Nom | Type | Taille | Description | RFC |
|---|---|---|---|---|
| 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, RFC 2675 |
| Routage | 43 | variable | Permet de modifier le routage à partir de la source, qui est utilisé notamment par Mobile IPv6 | RFC 2460, RFC 3775, RFC 5095 |
| Fragment | 44 | 64 bits | Contient les informations relatives à la fragmentation. | RFC 2460 |
| Authentication Header (AH) | 51 | variable | Contient les informations nécessaires à l'authentification de l'en-tête, voir IPsec. | RFC 4302 |
| Encapsulating Security Payload (ESP) | 50 | variable | Contient les information 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 |
| No Next Header | 59 | vide | Indique qu'il n'y a aucune charge utile qui suit. | RFC 2460 |
Les autres valeurs possibles suivent la même convention que le champ Protocol dans l'en-tête IPv4.
Le Neighbor Discovery Protocol (ND, RFC 2461) associe les adresses IPv6 a des adresses MAC sur un segment comme 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 est basé sur ICMPv6.
Dans un sous-réseau, il existe plusieurs méthodes d'assigner 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
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 dans la mesure où l'adresse MAC permet d'identifier de façon unique le matériel. Pour pallier cet inconvénient, 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) ou bien d'utiliser un service d'attribution automatique des adresses IPv6 par un serveur, de façon similaire à ce qui existe pour IPv4, avec DHCPv6.
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 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 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 OUI est réservée aux adresses IPv6 multicast (33:33:xx). L'adresse MAC du groupe multicast consistera en ces 16 bits que l'on fait suivre par les 32 derniers bits de l'adresse IPv6 muticast. 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 de 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 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'IGMP pour IPv4.
Les commutateurs ethernet les plus simples traitent les trames multicast en les diffusant comme des trames 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 4 milliards d'adresses multicast publiques. La RFC 3956 simplifie également la réalisation de points de rendez-vous pour les interconnexions multicast.
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) :
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 nibble (groupe 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).
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.
Le recours à la traduction d'adresse est découragé en IPv6 pour préserver la transparence du réseau , son utilisation n'est plus nécessaire pour économiser des adresses.
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.
Schéma de fonctionnement d'un tunnel statique.
Schéma de fonctionnement de 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'adresse 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 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, Freenet6 , Hurricane Electric ou encore Renater.
Les protocoles utilisés peuvent être :
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 AICCU (en), automatise la création des tunnels.
Tunnels automatiques
Passerelles applicatives
Il est possible de faire usage de serveurs qui disposent d'une double pile et qui font office de passerelle applicative (Application-Level gateway, ALG), un serveur proxy web par exemple.
NAT-PT combine la 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.
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'AS propre, d'une plage d'adresse IP de type Provider Independent (PI) et en utilisant 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 assignant autant d'adresses PA qu'il y a de fournisseurs, les mécanismes d'IPv6 comme l'assignation 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, 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'autre approches possibles sont basées sur la séparation de l'identificateur et du localisateur (Identifier / Locator Separation) :
Ceci est un sujet de recherche confié au groupe de travail Routing Research de l'Internet Research Task Force (en).
Nombre de préfixes et d'AS IPv6 sur Internet, de 2003 à aujourd'hui.
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 routeurs 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.
Depuis juillet 2004, l'ICANN accepte d'intégrer des serveurs de noms avec des adresses IPv6 (glue records) dans la zone racine. Les premiers domaines de premier niveau qui disposent d'un serveur DNS IPv6 sont .kr et .jp, .fr suit peu après.
En février 2008, l'ICANN a ajouté des adresses IPv6 à 6 des 13 serveurs racine du DNS et i a été ajouté en 2010. D'autre part, en 2010, 228 des 283 domaines de premier niveau disposent d'au moins un serveur avec une adresse IPv6. 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 glue AAAA records.
Les principaux serveurs de noms comme BINDv9 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 à 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 EDNS0 (RFC 2671) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.
Les protocoles de routage comme BGP (RFC 2545), OSPFv3 (RFC 5340) et IS-IS (RFC 5308) et MPLS (RFC 4798) ont été mis à jour pour IPv6.
Les protocoles TCP et UDP fonctionnent comme en IPv4. Le pseudo en-tête utilisée 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 le support 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 assigné à IPv6 est 0x86DD (RFC 2464).
Sur les réseaux NBMA (en) comme X.25 ou Frame Relay, des adaptations sont prévues pour permettre le fonctionnement du Neighbor Discovery.
Le consortium CableLabs a publié les spécifications IPv6 qui concernent les modems câble dans DOCSISv3.0 en août 2006. Il n'y a pas de support 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.
Pour les technologies xDSL, la RFC 2472 définit l'encapsulation de IPv6 sur PPP. Le BRAS doit également supporter IPv6.
En général, les équipements qui travaillent sur la couche de liaison, comme les commutateurs ethernet, n'ont pas besoin de mise à jour pour le support d'IPv6, sauf éventuellement pour le contrôle et la gestion à distance.
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.
Depuis le début du XXI siècle, tous les principaux systèmes d'exploitations (GNU/Linux, Mac OS X, Microsoft Windows, BSD, 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, QNX, Windows Mobile ou Wind River.
Windows Vista supporte 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 dual stack au lieu d'une pile indépendante pour IPv6. Ce support sert de base à HomeGroup et DirectAccess dans Windows 7.
Au niveau des routeurs, Cisco offre du support 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.
Certains 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 connues sous le nom de Bump in the Stack (RFC 2767) et Bump in the API (RFC 3338) permettent à des applications IPv4 de communiquer avec des clients IPv6.
De nombreuses applications ont déjà été portées C'est en particulier le cas des navigateurs web comme Internet Explorer (depuis la version 7, partiellement pour la version 6), Mozilla Firefox (1.0), Opera (7.20b), Safari et Google Chrome, du client de messagerie Mozilla Thunderbird (1.0), serveur web Apache (1.3.27/2.0.43), du serveur de mail Exim (4.20), etc.
Afin de faciliter le support d'IPv6 dans les logiciels, des outils apparaissent, comme IPv6 CARE par exemple.
Renater, a commencé à expérimenter IPv6 en 1996 avec le réseau G6bone, le pendant français du réseau 6bone mondial qui démarre la même année. Ce réseau de test utilise essentiellement des tunnels. Le service pilote IPv6 du réseau Renater 2 offre des connexions natives IPv6 sur ATM en 2002.
Le premier fournisseur d'accès à Internet français à avoir mis à disposition de ses clients (professionnels et particuliers) un accès IPv6 natif est Nerim dès mars 2003.
Wanadoo (aujourd'hui Orange) a proposé en juin 2005 une expérimentation IPv6 pour les particuliers, cette expérimentation est aujourd'hui clôturée.
Depuis décembre 2007, l’opérateur Free.fr propose une connectivité IPv6 à ses utilisateurs dégroupés. Pour les client de leur offre ADSL, cette connectivité est assurée via 6rd et disponible sur simple activation par le client.
Le FAI associatif French Data Network fournit aussi une connectivité IPv6, en test pendant l'été 2008. Elle est entrée en production au premier novembre de la même année.
SFR, au travers du projet européen Anémone, a déployé en 2008 un acces mobile natif IPv6 a des fins d'expérimentations. En 2009, IPv6 est présent dans leur offre pour les entreprises.
En mai 2009, Orange Business Services a déployé l'IPv6 sur son réseau MPLS IP VPN, à destination des entreprises.
Résultat de l'enquête IPv6 Ripeness du RIPE en avril 2010, sur 6768 registres locaux.
En Europe, depuis 2003, le réseau de recherche universitaire pan-européen GÉANT, interconnectant les réseaux nationaux de la recherche et de l'enseignement (NREN), utilise une double 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 en mai 2009.
En 2010, le RIPE NCC (Europe) est la région qui annonce le plus grand nombre de préfixes IPv6.
Le projet IPv6 Ripeness du RIPE vise à observer le déploiement d'IPv6 en Europe en attribuant des étoiles aux registres Internet locaux quand certains indicateurs de déploiement sont atteints. Les étoiles sont attribuées pour chacun des critères suivants :
En avril 2010, 27 % des LIR ont obtenu un bloc d'adresse IPv6, et 8 % ont atteint le niveau le plus élevé de quatre étoiles.
Nombre mensuel d'allocations de blocs IPv6 par chacun des RIR depuis 1999.
Répartition des allocations de blocs IPv6 aux registres Internet régionaux en janvier 2010 (source OCDE). Il y avait environ 4000 allocations à ce moment.
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 BGP4+. Les participants se voyaient octroyer un préfixe /24, /28 ou /32 dans le bloc 3ffe::/16. Le réseau a été démantelé en 2006 (RFC 3701) au profit de connexions natives.
Aujourd'hui, de nombreux serveurs web acceptent les connexions via IPv6 . Google est par exemple accessible en IPv6 depuis mars 2008, c'est également le cas de YouTube et Facebook depuis 2010.
Existent également des serveurs en IPv6 proposant des services courants, tels que FTP, SSH, SMTP, IMAP ou IRC.
En 2009, plusieurs opérateurs mondiaux ont commencé à déployer IPv6.
Au Japon, NTT commercialise différentes offres de services IPv6 et commercialise également le 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.
Aux États-Unis, Comcast a commencé 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'Amérique.
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 l'adressage 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 impossible d'adresser un nombre important de terminaux mobiles avec un adressage IPv4 (même avec NAPT).
Un rapport de l'OCDE publié en avril 2010 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 représente 0,3 % du trafic de l'AMS-IX (en). À la fin de l'année 2009, 1851 numéros d'AS IPv6 étaient visibles, ce nombre ayant doublé en deux ans.
Critiques opérationnelles
Certains ont critiqué la façon de la phase de transition vers IPv6 a été élaborée, ont indiqué 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 SNMP et les pare-feux) 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.
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, l'adresse IPv6 étant utilisée en priorité avant de recourir à l'adresse IPv4 après un délai déterminé.
Freins au déploiement
Les freins au déploiement d'IPv6 sont, entre autres, les suivants :
Concernant le développement du support IPv6 chez les fournisseurs de contenu et d'accès, on compare parfois le problème à celui de l'œuf et de la poule :
Selon une étude publiée en octobre 2009, les fournisseurs identifient les points suivants comme les principaux obstacles :
Les principaux facteurs de développement sont :
Concernant les problèmes rencontrés par les FAI qui ont déployé IPv6 :
IPv6 dans les produits destinés au public
En général, les produits du marché destinés au grand public n'ont pas de possibilité de mise à jour.
En 2010, la prise en charge d'IPv6 n'est pas encore un critère de choix pour le consommateur final. Quand les adresses IPv4 publiques ne sont plus disponibles, l'importance de ce critère sera sans doute revu. Les entreprises sont cependant plus attentives à ce problème et évitent d'investir dans des équipement qui pourraient s'avérer incompatibles avec IPv6.
Les clients ne disposant que d'une adresse IPv6 pourraient apparaître dès 2012, 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. L'accès aux serveurs IPv6 depuis des clients IPv4 présente également un défi technique.
Bien que certains équipements n'auraient besoin que d'une mise à jour de micrologiciel pour IPv6, il n'est pas certains que ceux-ci investiront dans cette voie alors que la vente de produits IPv6 Ready s'avérerait plus rentable.