IPv6

Un article de Wikipédia, l'encyclopédie libre.
Aller à : Navigation, rechercher
Pile de protocoles
7 • Application
6 • Présentation
5 • Session
4 • Transport
3 • Réseau
2 • Liaison
1 • Physique
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 le successeur du protocole IPv4, ce dernier formant la base du réseau Internet. IPv6 est similaire à IPv4 dans son fonctionnement, mais s'en distingue par son espace d'adressage plus étendu ainsi qu'un certain nombre d'améliorations.

Sommaire

[modifier] Raisons du développement d'un nouveau protocole IP

Distribution de l'espace d'adressage IPv4. La partie Unallocated indique la fraction encore disponible.
Épuisement des adresses IPv4 entre 1995 et 2010.

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.

Article détaillé : Épuisement des adresses IPv4.

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. En juillet 2010, on estime que l'IANA assignera le dernier bloc /8 libre à un registre Internet régional (RIR) en juillet 2011. Les RIR épuiseront les allocations d'adresses IPv4 pour les Local Internet Registries en mars 2012[1]. En juin 2010, ces estimations sont revues à la baisse devant la demande importante observée dans la région Asie-Pacifique au début de l'année, il est possible que les blocs libres soient épuisés dès la fin de l'année[2].

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 :

[modifier] Historique

Steve Deering a présidé le groupe de travail IPng de l'IETF.
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). En 1993, l'IETF lance un appel à propositions (RFC 1550) et annonce la création d'un groupe de travail IP Next Generation (IPng)[3].

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 dans la RFC 1883, en décembre 1995.

[modifier] 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 »[4].

[modifier] Adresses IPv6

Article détaillé : Adresse IPv6.

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 :

Type d'adresses IPv6
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
Structure des adresses unicast globales
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).

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é (264). Dans le bloc 2000::/3 qui représente 1/8e de l'espace d'adressage disponible en IPv6, on peut donc créer 245, soit 35 milliards de réseaux d'entreprises.

[modifier] En-tête IPv6

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 

[modifier] Fragmentation et option jumbo

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

[modifier] 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 :

En-têtes d'extension IPv6
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[5].

[modifier] Neighbor Discovery Protocol

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.

[modifier] Assignation des adresses IPv6

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'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[6] 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.

[modifier] 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 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.

[modifier] 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) :

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.

[modifier] Traduction d'adresse

Le recours à la traduction d'adresse est découragé en IPv6 pour préserver la transparence du réseau [7], son utilisation n'est plus nécessaire pour économiser des adresses.

[modifier] IPv6 et mobilité

Article détaillé : 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.

[modifier] Technologies de transition pour l'accès à l'Internet IPv6

Article détaillé : Transition d'IPv4 vers IPv6.
Schéma de fonctionnement d'un tunnel statique.
Schéma de fonctionnement de 6to4.
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'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[8], Freenet6 [9], Hurricane Electric[10] ou encore Renater[11].

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.

[modifier] 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'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[14], 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)[18].

[modifier] Déploiement d'IPv6

[modifier] L'Internet IPv6

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.

[modifier] Support d'IPv6 par le DNS

Depuis 2004, l'ICANN accepte d'intégrer des serveurs de noms avec des adresses IPv6 dans la zone racine[19].

Au début de février 2008, l'ICANN a ajouté des adresses IPv6 à 6 des 13 serveurs racine du DNS[20] 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[21]. 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[22].

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.

[modifier] Support d'IPv6 par les protocoles de routage

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.

[modifier] Support d'IPv6 sur les couches liaison et transport

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[23].

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.

[modifier] Support d'IPv6 dans les systèmes d'exploitation et les logiciels

Depuis le début du XXIe 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.

De nombreuses applications ont déjà été portées[24] C'est en particulier le cas des navigateurs web comme Internet Explorer (depuis la version 7, partiellement pour la version 6), Mozilla Firefox, Opera, Safari et Google Chrome, du client de messagerie Mozilla Thunderbird, serveur web Apache, du serveur de mail Exim, etc.

Afin de faciliter le support d'IPv6 dans les logiciels, des outils apparaissent, comme IPv6 CARE par exemple.

[modifier] Déploiement d'IPv6 chez les fournisseurs d'accès à Internet en France

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[25].

Wanadoo (aujourd'hui Orange) a proposé en juin 2005 une expérimentation IPv6[26] pour les particuliers, cette expérimentation est aujourd'hui clôturée.

Depuis décembre 2007, l’opérateur Free.fr propose[27] 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[28], 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é[29] l'IPv6 sur son réseau MPLS IP VPN, à destination des entreprises.

[modifier] Déploiement d'IPv6 en Europe

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[30] en mai 2009.

En 2010, le RIPE NCC (Europe) est la région qui annonce le plus grand nombre de préfixes IPv6[31].

Le projet IPv6 Ripeness[32] 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.

[modifier] Déploiement d'IPv6 dans le monde

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[33]. 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 [34]. Google est par exemple accessible en IPv6 depuis mars 2008[35], 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[36],[37],[38].

Au Japon, NTT commercialise différentes offres de services IPv6[39] 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[40].

Aux États-Unis, Comcast a commencé[41] 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[19] 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.

[modifier] Freins au déploiement d'IPv6

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[42].

D'autre part, certaines 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[43], 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[44] :

Selon une étude publiée en octobre 2009[45], 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.

[modifier] Références

  1. (en) IPv4 address report
  2. IPv6 : il y a urgence à migrer, selon l'IANA et la Commission Européenne, mais les freins sont encore nombreux..."
  3. History of the IPng effort
  4. « 96 More Bits, No Magic. » Gaurab Upadhaya.
  5. Voir Assigned Internet Protocol Numbers
  6. articles 16 et 17 de la directive générale 95/46, Les risques majeurs de IPv6 pour la protection des données à caractère personnel
  7. RFC 5902 IAB Thoughts on IPv6 Network Address Translation
  8. SixXS
  9. Freenet6
  10. Hurricane Electric
  11. Le service tunnel broker de Renater
  12. AYIYA: Anything In Anything, Internet Draft, 2004
  13. miredo
  14. Provider Independent (PI) IPv6 Assignments for End User Organisations, 2009
  15. (en) GSE - An Alternate Addressing Architecture for IPv6, Internet Draft 1997
  16. Multihoming présentation RIPE 52
  17. ocator/ID Separation Protocol (LISP), Internet Draft, 2009
  18. RRG
  19. a et b Internet Addressing: Measuring deployment of IPv6, OCDE, avril 2010
  20. L'ICANN commence à convertir les serveurs DNS à l'IPv6
  21. (en) Hurricane Electric Statistics
  22. Which DNS Registrars allow me to add AAAA glue for my Domain Name Servers?
  23. DOCSIS 2.0 Interface
  24. Current Status of IPv6 Support for Networking Applications
  25. L'IPv6 chez Nerim
  26. L'expérimentation IPv6 de Wanadoo/Orange (lien vers Internet Archive)
  27. Communiqué de presse sur la disponibilité de l'IPv6 chez Free[pdf]
  28. Anemone
  29. (Communiqué de presse) Orange Business Services : premier fournisseur global de services de communication à proposer IPv6 sur le marché des IP VPN mondiaux
  30. (fr) Plan d’action pour le déploiement d'IPv6 en Europe
  31. Ghost Route Hunter : IPv6 DFP visibility
  32. IPv6 Ripeness
  33. Liste des pTLA 6bone
  34. (en)Sixy.ch
  35. (fr)Google over IPv6.
  36. (en)Comcast open for IPv6 business, juin 2009.
  37. (en)LTE devices must support IPv6, says Verizon, juin 2009.]
  38. (en)U.S. carriers quietly developing IPv6 services, avril 2008. sur /www.networkworld.com.
  39. (en)NTT Com
  40. L'UE encourage l'utilisation du nouveau protocole Internet IPv6, mai 2008
  41. Les tests IPv6 de Comcast
  42. IPv6 Transition & Operational Reality, Randy Bush, IEPG / Chicago, juillet 2007
  43. IPv6 dual-stack client loss in Norway
  44. A strategy for IPv6 adoption, présentation Google au RIPE 57
  45. IPv6 deployment survey RIPE 59, juin 2009

[modifier] Voir aussi

[modifier] Articles connexes

[modifier] Liens externes

Ce document provient de « http://fr.wikipedia.org/wiki/IPv6 ».
Outils personnels
Espaces de noms
Variantes
Actions
Navigation
Contribuer
Imprimer / exporter
Boîte à outils
Autres langues