La standardisation d'IPv6 - Revision history

Laurent Toutain: /*
Des premières implémentations au démarrage du 6bone
*/

2006-06-13T12:25:57Z

‎<div if=6bone>Des premières implémentations au démarrage du 6bone</div>

Laurent Toutain: /* Des premières implémentations au démarrage du 6bone */

2006-06-13T12:24:51Z

‎Des premières implémentations au démarrage du 6bone

Laurent Toutain: /* = Format des sdresses de test */

2006-06-13T12:19:15Z

‎= Format des sdresses de test

Laurent Toutain: /* Des premières implémentations au démarrage du 6bone */

2006-06-13T12:18:53Z

‎Des premières implémentations au démarrage du 6bone

Bruno Deniaud at 14:23, 27 February 2006

2006-02-27T14:23:09Z

Laurent Toutain: /* Mise au point du plan d'adressage d'IPv6 */

2006-01-08T17:24:50Z

‎Mise au point du plan d'adressage d'IPv6

Laurent Toutain: /* La longue marche vers un Internet IPv6 */

2006-01-04T08:04:33Z

‎La longue marche vers un Internet IPv6

Laurent Toutain: /* Adresses de test dans le plan d'adressage fournisseur */

2006-01-04T08:03:55Z

‎Adresses de test dans le plan d'adressage fournisseur

Laurent Toutain: /* Plan d'adressage fournisseur (provider-based unicast address) */

2006-01-04T08:03:15Z

‎Plan d'adressage fournisseur (provider-based unicast address)

Laurent Toutain: /* Plan d'adressage fournisseur (provider-based unicast address) */

2006-01-04T08:01:38Z

‎Plan d'adressage fournisseur (provider-based unicast address)

@@ Line 80: / Line 80: @@
 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.
-== <div if=6bone>Des premières implémentations au démarrage du 6bone</div>==
+== <div id=6bone>Des premières implémentations au démarrage du 6bone</div>==
 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.

@@ Line 80: / Line 80: @@
 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==
+== <div if=6bone>Des premières implémentations au démarrage du 6bone</div>==
 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.

@@ Line 108: / Line 108: @@
 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 sdresses de test ==
+=== 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 <tt>3FFE::/16</tt> pour l'ensemble du 6bone.

← Older revision		Revision as of 12:18, 13 June 2006
Line 107:		Line 107:

	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.		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 sdresses 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 <tt>3FFE::/16</tt> pour l'ensemble du 6bone.
		+
		+	[[image:Fig3-4.jpg\|thumb\|right\|350px\|Figure 3-4 ''Adresse de test du plan agrégé'']]
		+
		+	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.
		+
		+	{\|
		+	\|+'''''Pseudo TLA attribués par le groupe ngtrans'''''
		+	!Organismes/Pays!!Préfixe!! !!Organismes/Pays!!Préfixe
		+	\|-style="background:silver"
		+	\|ROOT66/US-CA\|\|3FFE:0000::/24\|\| \|\|TRUMPET/AU\|\|3FFE:8000::/28
		+	\|-
		+	\|TELEBIT/DK\|\|3FFE:0100::/24\|\| \|\|ICM-PL/PL\|\|3FFE:8010::/28
		+	\|-style="background:silver"
		+	\|SICS/SE\|\|3FFE:0200::/24\|\| \|\|IIJ/JP\|\|3FFE:8020::/28
		+	\|-
		+	\|G6/FR\|\|3FFE:0300::/24\|\| \|\|QTPVSIX/EU\|\|3FFE:8030::/28
		+	\|-style="background:silver"
		+	\|JOIN/DE\|\|3FFE:0400::/24\|\| \|\|APAN-KR\|\|3FFE:8040::/28
		+	\|-
		+	\|WIDE/JP\|\|3FFE:0500::/24\|\| \|\|MIBH\|\|3FFE:8050::/28
		+	\|-style="background:silver"
		+	\|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.

	==<div id="plan">Mise au point du plan d'adressage d'IPv6</div>==		==<div id="plan">Mise au point du plan d'adressage d'IPv6</div>==

← Older revision		Revision as of 14:23, 27 February 2006
Line 1:		Line 1:
		+	{{suivi \|Historique de la standardisation d’IPv6\|Historique de la standardisation d’IPv6\|Bases whois\|Bases whois}}
	__TOC__		__TOC__

Line 245:		Line 246:

	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.		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.
		+	{{suivi \|Historique de la standardisation d’IPv6\|Historique de la standardisation d’IPv6\|Bases whois\|Bases whois}}

@@ Line 107: / Line 107: @@
 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.
-==Mise au point du plan d'adressage d'IPv6==
+==<div id="plan">Mise au point du plan d'adressage d'IPv6</div>==
 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.

@@ Line 222: / Line 222: @@
 |+Allocation des sTLA IPv6 par les RIR
 !	APNIC	|| ARIN	|| RIPE-NCC
-|-
+|-style="background:silver"
 |mai 2000	||13 sTLA ||	3 sTLA	|| 14 sTLA
 |-
 |décembre 2000	||21 sTLA ||	10 sTLA	|| 23 sTLA
-|-
+|-style="background:silver"
 |décembre 2001	||48 sTLA ||	20 sTLA	|| 51 sTLA
 |}

← Older revision		Revision as of 08:03, 4 January 2006
Line 156:		Line 156:

	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:		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:
		+
		+	[[image:CS215.gif]]

	===Plan d'adressage GSE===		===Plan d'adressage GSE===

@@ Line 127: / Line 127: @@
 ===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 :
+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 <tt>4000::/3</tt> et possèdait 5 niveaux hiérarchiques :
 [[image:CS214.gif]]
@@ Line 134: / Line 134: @@
 |+Allocation des valeurs des registry ID
 !registry ID	|| Nature
-|-
+|-style="background:silver"
 |10000 ||	IANA      (Internet Assigned Numbers Authority)
 |-
 |01000 ||	RIPE NCC  (Réseaux IP Européens, Network Coordination Center)
-|-
+|-style="background:silver"
 |11000 ||	InterNIC  (Internet Network Information Center)
 |-

@@ Line 127: / Line 127: @@
 ===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 :
+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 :
 {|
@@ Line 143: / Line 145: @@
-*Le premier niveau avait une longueur fixée à 5 bits (i=5) et ses valeurs possibles étaient donné par le tableau précédent.
+*Le premier niveau avait une longueur fixée à 5 bits (<tt>i=5</tt>) 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).
+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 <tt>k=32</tt>).
-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.
+Les deux derniers niveaux, gérés par le souscripteur, étaient respectivement le numéro de sous-réseau (<tt>l=16</tt>) 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.