La standardisation d'IPv6
Un article de IPv6.
 | Historique de la standardisation d’IPv6 | Table des matières | Bases whois | 
|
Dans cette première phase, commencée en août 1990 lors de la réunion IETF de Vancouver, le taux de croissance continu de l'Internet met en évidence le gaspillage des adresses dû à la structure en classes de l'adressage IPv4. L'activité a surtout consisté à quantifier le problème et à proposer quelques solutions à plus ou moins court terme.
Un certain nombre de sites ne peuvent plus se contenter d'un simple réseau de classe C pour les équipements qu'ils ont à mettre en réseau. Leurs besoins d'adressage sont intermédiaires entre un réseau de classe C (254 adresses disponibles) et un réseau de classe B (65534 adresses disponibles). Une simulation montre alors que si chacun de ces sites fait une demande de réseau de classe B, compte tenu de la vitesse de croissance de l'Internet, il n'y aurait plus eu de réseaux de classe B disponibles pour de nouvelles allocations vers mars 1994.
La solution adoptée, qui consiste à attribuer plusieurs réseaux de classe C à un même site va générer un autre problème qui est la saturation de la mémoire disponible pour maintenir les tables de routage sur les routeurs principaux de l'Internet.
La question de fond commence alors à émerger : faut-il conserver le protocole IP en l'adaptant tant bien que mal aux exigences de l'évolution de l'Internet et en acceptant les contraintes (en particulier la limitation de la croissance à cause de la pénurie prévisible d'adresses), ou bien opter pour la modification de la structure des adresses et refondre le standard IP en acceptant le bouleversement que cela va provoquer ?
En novembre 1991, lors de la réunion IETF de Santa Fe, les groupes de travail ROAD (Routing and Addressing) et ALE (Address Lifetime Expectations) sont créés. Ils sont chargés d'étudier les trois problèmes suivants pour guider l'IETF dans ses choix :
- la pénurie des réseaux de classe B,
- la croissance des tables de routage des routeurs principaux,
- la pénurie des adresses de machines.
L'émergence des premières idées
En mars 1992, lors de la réunion IETF de San Diego, le groupe ROAD rend compte de ses travaux et propose pour le court terme d'adopter CIDR (Classless Inter-Domain Routing) qui règle provisoirement le problème de la croissance des tables de routage par l'agrégation des préfixes contigus.
Pour le long terme, il propose de faire un appel à propositions et de former des groupes de travail chargés d'étudier différentes approches possibles pour un nouveau protocole IP doté d'un espace d'adressage plus grand qu'IPv4. Quatre groupes sont alors au travail avec des propositions sérieuses, il s'agit de :
- PIP : The ‘P’ Internet Protocol, qui introduit la notion d'identificateur et de localisateur,
- TUBA : TCP and UDP with Bigger Addresses ([RFC 1347]) basée sur CLNS,
- IPAE : IP Address Encapsulation, basée sur une extension des adresses IPv4,
- SIP : Simple Internet Protocol, version simplifiée de IPv4 avec des adresses à 64 bits.
Parallèlement à ce travail, l'IAB produit une version 7 du protocole IP basée sur CNLP (Connectionless Protocol) de l'ISO.
D'autre part, plusieurs propositions indépendantes ont vu le jour. On peut citer notamment CATNIP [RFC 1707], proposant une standardisation de l'interface entre les couches réseau et transport. Après discussions, l'IETF décide de rejeter la proposition de l'IAB et adopte les propositions du groupe ROAD.
En juillet 1992, lors de la réunion IETF de Cambridge, un appel à propositions est donc lancé à la communauté mondiale pour définir les caractéristiques de l'IP de nouvelle génération (IPng).
Définition du cahier des charges du nouvel IP
En novembre 1992, lors de la réunion IETF de Washington, CIDR est adopté par l'IESG pour répondre au problème de la croissance trop rapide des tables de routage. Il sera rapidement inclus dans les protocoles de routage externe comme BGP4.
L'IESG publie le RFC 1380 "Délibérations de l'IESG pour le routage et l'adressage". Ce document fixe un premier cahier des charges que devront respecter les propositions pour le nouveau standard IP, et une grille d'évaluation qui sera utilisée pour les comparer. Ainsi, le nouveau standard devra être capable :
- d'adresser au moins un milliard de réseaux,
- de proposer un plan de transition "sans jour J",
- de prendre en compte à terme la mobilité, la réservation de ressources, les hauts débits, etc.
Les propositions devront préciser les changements induits sur :
- les machines,
- les routeurs intérieurs et extérieurs,
- la sécurité et l'authentification,
- la gestion du réseau et les outils (ping, traceroute, etc.),
- les modes opératoires et les procédures d'administration,
- les autres protocoles (ARP, RARP, IP, ICMP...).
Et étudier :
- l'impact sur les performances et la sécurité,
- un schéma complet de routage et d'adressage,
- un plan de déploiement.
Tous les groupes sont invités à présenter leurs propositions pour la réunion IETF de mars 1993 à Columbus. Lors de cette réunion, les groupes IPAE, PIP, SIP, TUBA présentent leurs premiers travaux et parfois des premières implémentations de leurs protocoles. Les groupes SIP/IPAE fusionnent en gardant le nom de SIP. Mais la compétition entre les groupes qui défendent chacun leur solution est très forte et tend à disperser les efforts tout en ralentissant le processus d'émergence du nouveau standard. Aussi en juillet 1993, lors de la réunion IETF d'Amsterdam, et sous la pression des acteurs industriels, l'objectif est redéfini : il faut arriver rapidement à produire un standard minimum fondé sur tous les éléments techniques pour lesquels il y a consensus. L'IESG est également chargé de clarifier le processus de sélection. Pour limiter la dispersion des efforts due à la concurrence de groupes de travail rivaux, un domaine IPng (IP next generation) est formellement créé pour coordonner leur action [RFC 1454]. En novembre 93, lors de la réunion IETF de Houston, le groupe ALE présente des projections de croissance de l'Internet et propose les mesures suivantes pour prolonger la vie d'IPv4 :
- récupération des numéros de réseaux assignés non utilisés ou sous-utilisés,
- durcissement de la politique d'allocation de réseaux,
- incitation des sites largement pourvus à renuméroter pour restituer une partie de leurs numéros de réseaux ou pour revenir dans l'espace d'adressage de leur fournisseur d'accès.
Lors de cette même réunion, les groupes de travail PIP et SIP fusionnent dans le groupe SIPP (Simple Internet Protocol Plus [RFC 1710]). L'IESG publie un livre blanc ([RFC 1550]) qui est un appel à propositions pour définir les critères qui serviront à apprécier les propositions des différents groupes de travail sur le nouveau protocole IP. En mars 1994, lors de la réunion IETF de Seattle, le groupe ALE dans son étude sur la croissance du nombre de machines connectées à l'Internet prédit qu'il n'y aura plus d'adresses disponibles en 2008 (à 3 ans près) sur la base du taux de croissance actuel. Il propose de standardiser quelques numéros de réseaux non routables pour les utiliser dans les réseaux IP privés (Intranets). Parallèlement, une forte incitation sera lancée pour utiliser l'agrégation de routes au moyen du Classless Interdomain Routing (CIDR).
L'appel du RFC 1550 sera entendu, et un document définissant les critères de sélection du nouveau protocole IP parmi les candidats restants a pu être élaboré à partir des réponses obtenues. Un appel à commentaires est lancé avec comme objectif de pouvoir disposer d'une version définitive lors de la prochaine réunion de l'IETF en juillet 1994 à Toronto.
Le choix d'IPv6
Lors de la réunion IETF de Toronto, les projets de protocoles TUBA, CATNIP, SIPP qui ont été finalisés courant 1994 sont analysés. Il en ressort les principaux éléments suivants :
- CATNIP est bien considéré, mais trop jeune. Le risque lié à un protocole très nouveau et le manque de plan de transition le font rejeter.
- TUBA est assez globalement rejeté à cause de la dualité IETF/ISO.
- SIPP, qui est devenu SIPP+ quand la taille de ses adresses a été portée à 16 octets, est adopté : la philosophie principale d'IPv4 est conservée et le nombre de champs de l'en-tête est moindre.
Recommandation "impérative" est faite d'adopter le protocole SIPP+ comme successeur d'IPv4.
Le choix de SIPP+ comme nouveau protocole a aussi le mérite d'arrêter la compétition entre groupes de travail rivaux, et de concentrer les efforts autour d'un même projet. Car si le format du paquet IP nouveau est défini, beaucoup de choses restent à faire, et notamment définir la structure de l'adressage qui reste un problème majeur non résolu à cette époque.
Fin 1994, le nom définitif du protocole est adopté, ce sera IPv6 (la version 5 ayant déjà été attribuée à un protocole expérimental : ST-II, [RFC 1819] et la version 7 réservée au transport sur CLNP). L'IESG approuve alors la création de deux nouveaux groupes de travail :
- IPng (IP next generation) va devoir définir complètement les spécifications du nouveau protocole sur les bases de SIPP, en respectant le cahier des charges élaboré.
- NGTRANS (IPng Transition) qui s'attèle au problème de la migration de l'Internet d'IPv4 vers IPv6.
En même temps, les premières implémentations du protocole vont permettre des tests à plus grande échelle, en interconnectant les plates-formes de test IPv6 intra- et inter- continent.
Des premières implémentations au démarrage du 6bone
Après la publication d'une nouvelle version des recommandations pour le nouveau protocole IP [RFC 1752], en janvier 1995 et la création de l'enregistrement de type AAAA pour supporter les adresses IPv6 dans le DNS d'IPv4 en février, les trois premières souches IPv6 sont produites par DIGITAL, l'INRIA, et le NRL (US Naval Research Laboratory). Le 30 mars 1995, les premiers paquets IPv6 sont échangés entre des machines utilisant ces codes.
Les choses vont s'accélérer à partir de la réunion IETF de fin avril 1995 à Denver qui donne lieu à première diffusion des souches IPv6 existantes. Les implémentations d'IPv6 se multiplient, et début juin 1995, la liste des systèmes supportant IPv6 est la suivante : NetBSD (INRIA), BSDI (NRL), DIGITAL Unix, HP-UX (SICS).
La fin de l'année 1995 va voir un grand nombre de tests et démonstrations d'interopérabilité d'IPv6 se dérouler. En particulier :
- juillet 1995 : interopérabilité démontrée à la réunion IETF de Stockholm.
- 8-10 août 1995 : TCP/IP expo show (SICS, Mitre, INRIA, HP, DIGITAL).
- 27-29 septembre 1995 : démonstration publique de machines échangeant du trafic IPv6 à l’Atlanta User Interop.
- 7 décembre 1995 : rencontre des implémenteurs IPv6 à la réunion IETF de Dallas.
La plupart de ces tests d'interopérabilité ont eu lieu sur un même réseau local. La suite logique est de vouloir étendre ces tests dans un contexte de réseau étendu pour tester les équipements et protocoles de routage.
C'est ainsi que naît l'idée du G6 en France. Ce groupe se donne un double objectif :
- regrouper les expérimentateurs d'IPv6 en France en les aidant à partager leur expérience et en coordonnant des actions communes.
- faire connaître et promouvoir le proctocole IPv6.
Il tient sa première réunion le 20 décembre 1995.
Au plan international, c'est à la réunion IETF de Los Angeles en mars 1996 que germe l'idée de créer un réseau mondial de machines implémentant IPv6. Il est appelé le 6bone. Lors de la réunion IETF suivante à Montréal en Juillet 1996, il est imaginé de construire le 6bone à partir d’un ensemble de tunnels reliant entre eux des îlots de machines.
Le 15 juillet 1996 comme prévu à Montréal, a lieu le démarrage officiel du 6bone reliant l'IMAG en France pour le G6, Uni-C au Danemark et le projet WIDE au Japon. En Décembre 1996, lors de la réunion IETF de San José, le 6bone devient un groupe de travail de l'IETF. Il est décidé de structurer géographiquement le réseau, tous les tunnels d'un même pays arrivant sur un ou quelques noeuds qui échangent eux-même leurs trafics.
Pendant toute l'année 1997, le 6bone raccorde de plus en plus de sites, jouant son rôle de terrain d'expérimentation pour IPv6. Dans le domaine du routage, il utilise d'abord RIPng [RFC 2080] qui est une adaptation à IPv6 de RIP et IDRPv6, puis BGP4+ qui est une adaptation à IPv6 de BGP4.
Il permet surtout de déployer et de tester à grande échelle les deux plans d'adressage qui se succèdent en cette année 1997.
Format des adresses de test
Les expérimentations d'IPv6 sur un réseau devaient commencer avant que les règles d'attribution des préfixes soient complètement finalisées. La valeur 0x1FFE a été attribué par l'IANA au 6bone dans le plan d'adressage agrégé pour les expérimentations (RFC 3701). Il correspond au préfixe 3FFE::/16 pour l'ensemble du 6bone.
Les 48 bits restant avant le champ Subnet ID recréent les niveaux hiérarchiques d'un réseau IPv6 défini dans le RFC 3587, d'où le terme pseudo accolé au nom du champ. La taille réduite n'étant pas un facteur limitant dans la phase expérimentale. Des pseudo-TLA d'une taille initialement de 8, mais portées à 12 bits par la suite, sont attribués à des opérateurs voulant expérimenter le protocole. Les 24 ou 20 bits suivants sont utilisés pour numéroter les sites.
Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. La liste complète est disponible sur le serveur Web http://www.6bone.net/6bone_pTLA_list.html. Le tableau Pseudo TLA attribués par le groupe ngtrans reprend quelques unes de ces valeurs.
| Organismes/Pays | Préfixe | Organismes/Pays | Préfixe | |
|---|---|---|---|---|
| ROOT66/US-CA | 3FFE:0000::/24 | TRUMPET/AU | 3FFE:8000::/28 | |
| TELEBIT/DK | 3FFE:0100::/24 | ICM-PL/PL | 3FFE:8010::/28 | |
| SICS/SE | 3FFE:0200::/24 | IIJ/JP | 3FFE:8020::/28 | |
| G6/FR | 3FFE:0300::/24 | QTPVSIX/EU | 3FFE:8030::/28 | |
| JOIN/DE | 3FFE:0400::/24 | APAN-KR | 3FFE:8040::/28 | |
| WIDE/JP | 3FFE:0500::/24 | MIBH | 3FFE:8050::/28 | |
| SURFNET/NL | 3FFE:0600::/24 | ATNET-AT | 3FFE:8060::/28 |
L'expérimentation lié au 6bone s'est terminée symboliquement le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau au début de l'introduction d'IPv6 palier à l'absence d'opérateurs officiels, il a vite montré ses limites. L'utilisation de tunnels pour créer la connectivité, a conduit à un trop fort maillage, à des routes relativement longues et par conséquence à une faible qualité de service.
Mise au point du plan d'adressage d'IPv6
Comme on l'a vu précédemment, la structure de l'adressage n'a pas été définie lors de l'adoption du nouveau format de paquet IP en juillet 1994. La seule chose de sûre est que les adresses IPv6 ont 128 bits de long. Une des premières tâches a donc été de définir comment ces 128 bits allaient être utilisés.
Cela va donner lieu à beaucoup d'activité et à des échanges passionnés tant les enjeux sont importants. En effet, les principaux acteurs que sont les fournisseurs d'accès au réseau, leurs clients, et les constructeurs d'équipements routage ou de postes de travail ont des intérêts et donc des points de vue qui peuvent être sensiblement opposés. Par exemple les fourniseurs d'accès sont plutôt enclins à garder captifs leurs clients en maîtrisant l'espace d'adressage, alors que les clients souhaitent garder la possibilité de changer de fournisseurs facilement. Les constructeurs quant à eux souhaitent que les protocoles soient simples à implémenter.
Plusieurs plans d'adressages ont été étudiés pour arriver finalement au plan d'adressage dit agrégé basé sur 3 niveaux d'agrégation.
En juillet 1995, lors de la réunion IETF de Stockholm, un premier débat oppose les partisans d'un plan d'adressage géographique aux fournisseurs d'accès. Ces derniers souhaitent pouvoir faire de l'agrégation d'adresses (type CIDR) indépendamment des critères géographiques. Les premières spécifications d'IPv6 sont publiées sous forme d'une suite de RFC ([RFC 1883], [RFC 1884], [RFC 1885], [RFC 1886], [RFC 1887]) lors de la réunion IETF de Dallas en décembre 1995. Ils spécifient complètement la structure des en-têtes du paquet IPv6, le plan d'adressage est structuré par fournisseur d'accès à l'Internet.
En décembre 1996, lors de la réunion IETF de San José la proposition "8+8" qui découpe les 16 octets de l'adresse en 8 octets fournisseur d'accès et 8 octets utilisateur est discutée. Elle a pour objectif de limiter la croissance des tables de routage et de rendre l'utilisateur indépendant de son fournisseur en effectuant une traduction partielle d'adresse sur les 8 octets réservés au fournisseur d'accès en sortie de site. En mars 1997, lors de la réunion IETF de Palo Alto, la proposition 8+8 qui est devenue GSE (Global, Site and End-system) est à nouveau discutée, mais est rejetée.
Plan d'adressage géographique (geographic-based unicast address)
C'est l'un des premiers plans d'adressage proposés. Il découpe hiérarchiquement les adresses en entités géographiques (continents, pays, région, ville, etc.). Ce plan est aujourd'hui abandonné, car difficile à mettre en œuvre pour des raisons d'ordre technique notamment. Il n'est valable que dans des situations monopolistiques où les opérateurs contrôlent une partie de territoire.
Les adresses étaient caractérisées par le préfixe 8000::/3.
Plan d'adressage fournisseur (provider-based unicast address)
Ce type d'adresse (cf. figure 17-4) est décrit dans le RFC 2073, classé historique. Une adresse de ce type avait pour préfixe 4000::/3 et possèdait 5 niveaux hiérarchiques :
| registry ID | Nature |
|---|---|
| 10000 | IANA (Internet Assigned Numbers Authority) |
| 01000 | RIPE NCC (Réseaux IP Européens, Network Coordination Center) |
| 11000 | InterNIC (Internet Network Information Center) |
| 10100 | APNIC (Asia-Pacific Network Information Center) |
- Le premier niveau avait une longueur fixée à 5 bits (i=5) et ses valeurs possibles étaient donné par le tableau précédent.
- Un fournisseur d'accès à l’Internet était identifié par un numéro qu'il obtient d’un des organismes mentionnés ci-dessus.
De même, un souscripteur obtienait son identificateur de son fournisseur. C’est un mot de 24 bits suivi de 8 bits laissés à zéro (donc k=32).
Les deux derniers niveaux, gérés par le souscripteur, étaient respectivement le numéro de sous-réseau (l=16) et l'identificateur de l'interface (48 bits), typiquement son adresse MAC. Dans ce plan d'adressage, les adresses appartiennent aux fournisseurs de connectivité IP et non pas aux utilisateurs. Tout changement de fournisseur implique donc pour un client de renuméroter toutes ses machines. De plus, si un client est abonné à un "petit" fournisseur lui-même revendant de la connectivité IP d'un plus gros fournisseur, et si le fournisseur intermédiaire décide de changer de fournisseur principal, le client final doit renuméroter tout son réseau. Ceci a été jugé inacceptable.
Adresses de test dans le plan d'adressage fournisseur
Ces adresses (cf. figure 17-5) sont décrites dans le RFC 1897. L'intérêt principal de ces adresses de test est de fournir un algorithme simple basé sur les adresses IPv4 existantes afin de construire des adresses IPv6 pour des équipements expérimentaux sans avoir à demander de délégation d'autorité. Ces adresses ont été largement utilisées lors de la création du 6bone:
Plan d'adressage GSE
Le plan d'adressage fournisseur a été largement critiqué, surtout par les opérateurs, qui tiennent essentiellement aux problèmes de renumérotation.
L'approche GSE (Global, Site and End-system) propose une construction dynamique des adresses avec une partie basse fixe d'identificateur globalement unique (au niveau de l'Internet) sur 64 bits et une partie haute variable identifiant le fournisseur d'accès, insérée à la volée par le routeur de sortie du site.
Tant qu'un paquet reste à l'intérieur du site, la partie haute des adresses sources des paquets émis depuis le site est forcée à zéro. Il en va de même pour les adresses destinations des paquets reçus depuis l'extérieur à destination d'une machine du site. La partie haute des paquets sortants est positionnée à la "bonne" valeur par le routeur de sortie. Si le site est connecté à plusieurs fournisseurs d'accès, ce routeur sélectionne cette valeur en fonction du fournisseur choisi. Ceci facilite le changement de fournisseur en éliminant la nécessité de renumérotation manuelle. En outre, la gestion d'un site dépendant de plusieurs fournisseurs est facilitée.
Le plan d'adressage proposé par GSE présente des avantages :
- GSE facilite la renumérotation du réseau puisqu'il suffit de changer l'adresse dans le routeur en frontière ;
- GSE supporte facilement les réseaux à attachements multiples (multihomed). Les réseaux ayant plusieurs attachements à des fournisseurs d'accès différents posent un problème d'adressage dans les plans d'adressages classiques~: si une station choisit l'une des adresses possibles, des exceptions doivent être introduites dans les tables de routage de l'Internet. Si la station prend toutes les adresses possibles, elle ne sait quelle adresse source optimale utiliser. Avec GSE l'adresse de la source est construite dynamiquement au moment de la traversée du routeur en frontière, elle est donc la meilleure pour une destination donnée.
Par contre GSE présente plusieurs inconvénients graves :
- TCP associe un contexte en fonction des adresses IP. Si celles-ci changent, la connexion doit quand même être maintenue, d'où l'existence d'un identifiant unique au niveau mondial ; cela implique une refonte de TCP qui n'est pas à l'ordre du jour à l'IETF ;
- le calcul des checksums doit être modifié puisque la station ne connaît qu'une partie de l'adresse ;
- la question de l'enregistrement des adresses dans le DNS inverse, faisant la correspondance entre une adresse et un nom de machine, n'est pas résolue ;
- la partie identificateur est supposée "globalement" unique ; on ne sait pas s'il faut une garantie absolue, et si oui, comment la vérifier ;
les mécanismes de mascarade (utiliser l'adresse source d'une autre machine) sont mal compris, et il semble que l'utilisation de sécurité active (IPsec) soit quasiment obligatoire.
Mise au point finale du cœur des spécifications d’IPv6
En août 1997, lors de la réunion IETF de Munich, le protocole BGP4+ est choisi de préférence à BGP5 (la possibilité d'avoir des numéros de systèmes autonomes codés sur 4 octets au lieu de 2 dans la version IPv4 n’est pas retenue).
En décembre 1997, lors de la réunion IETF de Washington, le rapport d’un test d’interopérabilité fait par un laboratoire de l’UNH (Université du New Hampshire) est présenté au groupe IPng. Ce test qui met en oeuvre 10 machines et 6 routeurs, montre que 90% des machines et 70% des routeurs interopèrent bien (en RIPng ou BGP4+ pour ces derniers). Lors de cette même réunion, les règles d’attribution des TLA et NLA et les critères définissant les niveaux d'agrégation donnent lieu à beaucoup de controverses, ces éléments ne pourront être finalisées que mi 1998.
Pendant cette année 1998, une intense activité de test et de déploiements de réseaux expérimentaux, permet d’affiner les propositions de standards, les implémentations (machines et routeurs) et de valider les plans d’adressage expérimentaux et de production.
En octobre 1998, ESnet (Energy Sciences Network) établit une connexion IPv6 sur ATM avec les réseaux CAIRN, Internet2/vBNS et CA*net2, puis, en décembre avec WIDE (Japon). ESnet crée aussi l'initiative 6REN (IPv6 Research and Education Networks Initiative) qui a pour but de donner au monde de l'enseignement et la recherche américain un service IPv6 de production en complément du 6bone qui est un réseau d’expérimentation et ne peut assurer la continuité de service necessaire à un réseau de production. Le 6REN est à considérer comme un équivalent du NANOG dédié à IPv6. C’est aussi ESnet qui assure la connecticité 6BONE/6REN. On peut aussi noter à cette époque des ébauches de projets similaires en australie (AARNET: Australian Academic and Research Network) et en chine (CERNET: China Education and Research Network). En France, le G6bone effectue sa migration dans le nouveau plan d’adressage de test.
Pendant la réunion IETF de décembre 1998 à Orlando, le groupe IPng décide de fusionner les codes IPv6 INRIA, NRL, et KAME dans la souche KAME regroupant ainsi sur une seule souche les efforts d’implémentation sous système d’exploitation BSD.
Cette fin d’année 1998 marque une nouvelle étape dans l’histoire d’IPv6, en effet, 15 RFC ont été publiés (dont 4 sont passés en Draft Standard), fixant ainsi le cœur des spécifications d’IPv6 et définissant un premier plan d’adressage aggrégé. Quatre ans après l’étape décisive de fin 1994 qui avait vu fixer les éléments consensuels d’alors (les 128 bits d’adresse, et le format d’en-tête simplifié), cette étape fixe de la même manière ce qui peut l’être, laissant à la suite du processus le soin de résoudre les nombreux problèmes encore en suspens (migration, mobilité, DNS, autoconfiguration, etc...).
Les schémas de migration et d’intégration IPv4/IPv6
Bien que la standardisation d’IPv6 ne soit pas achevée, loin s’en faut, les membres de l’IETF, considèrent qu’il faut maintenant s’attaquer à un nouveau problème de taille : celui de la transition d’IPv4 vers IPv6. Lors de la réunion intérimaire de l’IETF de février 1999 (qui a lieu à l’IMAG à Grenoble) les propositions de schémas de migration et d’intégration IPv4/IPv6 sont si nombreux qu’il est décidé d’en faire une taxonomie pour y voir plus clair et faire naître des convergences.
Au premier trimestre 2000, la plupart des propositions sont formalisées par des RFC. On peut les répartir dans les trois grandes familles suivantes :
Des outils au niveau réseau comme :
- les adresses IPv4 compatibles : utilisées au début quand il n’y avait que très peu de machines IPv6,
- les adresses IPv4 mappées : qui permettent à des machines IPv4 de communiquer avec des machines IPv6,
- les adresses ’6to4’ : qui permettent de joindre un site IPv6 à travers un réseau IPv4 sans configuration de tunnels,
- les tunnels configurés : utilisés pour le déploiement des réseaux de test, mais comme tous les tunnels, ils réduisent le MTU et empilent deux routages,
- les générateurs automatiques de tunnels (tunnels brokers) : solution permettant à une machine d’obtenir une connectivité IPv6 sans avoir intervention manuelle du gestionnaire du site offrant cette connectivité.
Des protocoles de traduction d’adresses comme :
- SIIT [RFC 2765] : qui permet à des machines IPv6 de communiquer avec des machines IPv4 au moyen de traducteurs d’adresses, situés en bordure des domaines IPv4/IPv6. Ces traducteurs traitent les paquets IP et ICMP, sans introduire d’état dans le réseau,
- NAT-PT [RFC 2766] : semblable à SIIT, il utilise des adresses globales IPv6 (et non pas des adresses dérivées d’IPv4). Les traducteurs de bordure modifient les adresses et les en-tête, ils doivent disposer d’un préfixe IPv4,
- DSTM [BTM-id] : qui permet de résoudre tous les cas de communication entre les mondes IPv6 et IPv4 sans nécessiter de portage des applications IPv4. Les traducteurs de bordure doivent disposer d’un préfixe IPv4.
Des protocoles intervenant au niveau TCP ou des applicatifs comme :
- BIS [RFC 2767] : qui permet à des aplications IPv4 de fonctionner sur les machines IPv6 en effectuant les traductions d’adresses nécessaires dans le noyau du système d’exploitation,
- SOCKS [RFC 3089] : fonctionnellement similaire à BIS, c’est une extension du protocole SOCKS (défini dans le RFC 1928) à la communication entre des piles TCP/IPv4 et TCP/IPv6.
Durant le reste de l’année 2000 et toute l’année 2001, ces protocoles sont retravaillés, notamment pour prendre mieux en compte les aspects sécurité et dénis de service ainsi que les mécanismes de mise à jour du DNS qui peuvent ou doivent leur être associés.
La longue marche vers un Internet IPv6
Le 14 juillet 1999, presque 3 ans jour pour jour après le démarrage du 6bone, l’IANA annonce que la première délégation officielle de préfixes IPv6 vient d’être effectuée auprès du RIPE-NCC, de l’ARIN, et de l’APNIC. On peut considérer que cette date marque la naissance du nouvel Internet IPv6. Ces organismes vont alors commencer à distribuer des sTLA à un rythme tel qu’indiqué dans le tableau suivant.
| APNIC | ARIN | RIPE-NCC | |
|---|---|---|---|
| mai 2000 | 13 sTLA | 3 sTLA | 14 sTLA |
| décembre 2000 | 21 sTLA | 10 sTLA | 23 sTLA |
| décembre 2001 | 48 sTLA | 20 sTLA | 51 sTLA |
Comme les chiffres le montrent, ce déploiement, s’il est bien réel, reste limité en volume et assez hétérogène géographiquement. L’hétérogénéité géographique s’explique par le fait que les utilisateurs nord américains ne sont pas en situation de pénurie d’adresses IPv4, et donc ne sollicitent que faiblement leurs opérateurs en connectivité et adresses IPv6. Le déploiement limité sur les autres continents s’explique par la non complétude de la standardisation des protocoles IPv6. C’est le deuxième axe de travail de l’IETF (en plus de celui sur les mécanismes de transition/intégration) durant les années 2000 et 2001, car cette complétude constitue un pré-requis à un développement à grande échelle d’IPv6.
En décembre 1999, le RFC 2740 standardise la version IPv6 d’OSPF, et en juillet 2000, lors de la réunion IETF de Pittsburgh, une communication dans le groupe de travail OSPF informe les participants que le logiciel de routage Zebra dispose d’une première version IPv6 d’OSPF implémentée et testée avec succès.
En juillet et août 2000, les RFC 2874 et RFC 2894 sont publiés, ils concernent des extensions au DNS pour l’aggrégation et la renumérotation ainsi que la renumérotation de routeurs. En fin d’année 2000, les RFC 3007 et RFC 3008 concernant la sécurisation des DNS sont publiés. Ce sont les compléments indispensables pour gérer la dynamicité introduite par les mécanismes de renumérotation.
Début 2001, le RFC 3041 améliore la protection de la vie privée ou professionnelle qui pouvait être mis en cause par le mécanisme d’autoconfiguration. En effet, ce dernier, en construisant un identifiant d’interface unique et permanent à partir de l’adresse Ethernet aurait pu permettre la tracabilité dans le temps ou dans l’espace du possesseur d’une machine IPv6. L’introduction d’une durée de vie limitée pour les identifiants d’interface et leur remplacement régulier par d’autres règle cette question.
Mi 2001, le groupe de travail IPng constate qu'il a presque terminé sa tâche. Il décide de changer de nom ; un nouveau groupe est créé, IPv6, qui a pour but de terminer les documents en attente et de traiter de points encore en débat (renumérotation automatique, adressage de site, ...). Un autre groupe, multi6, est créé pour s'occuper du problème de la multi-domiciliation.
En août 2001, le RFC 3152 met en place la délégation de la racine (ip6.arpa) de l’arbre de nommage inverse pour IPv6, complétant ainsi le dispositif pour le DNS.
Fin 2001, les travaux de standardisation sont principalement centrés sur les mécanismes de transition comme DSTM et BIA (Bump In the API) ainsi que sur la gestion du multicast IPv6. Des liens sont aussi établis avec la téléphonie mobile dont la version UMTS a choisi IPv6 comme technologie de transport pour pallier les insuffisances d’IPv4 en matière d’espace d’adressage.
Début 2002, l’ensemble des systèmes d’exploitation sont équipés d’une double pile IPv4 et IPv6, la plupart des routeurs implémentent au moins un protocole de routage interne (RIPng) et un protocole de routage externe (BGP4+). Même si la suite des protocoles IPv6 n’est pas encore aussi complète qu’il serait souhaitable, l’Internet IPv6 est bien en cours de déploiement, et des noeuds importants comme le Startap, aux Etats-Unis, le Nspixp au Japon ou le Sfinx en France échangent désormais du trafic natif IPv6.
| | Historique de la standardisation d’IPv6 | Table des matières | Bases whois |
|
