Livre IPv6 - User contributions [en]

Unicast Global

2008-11-20T10:38:39Z

Laurent Toutain: /* Adressage global : plan d'adressage agrégé */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== Adressage global : plan d'adressage agrégé ===

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Une adresse intègre trois niveaux de hiérarchie :

<tikz>
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

\draw (0, 6.6) node [right] {Global Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{public topology}} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>



* une topologie publique codé sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codé sur 16 bits. Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] (64 bits) distinguant les différentes machines sur le lien.

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

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

[[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 récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, 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.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délégation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de longueur supérieure ou égale à 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

Unicast Global

2008-11-20T10:38:26Z

Laurent Toutain: /* Adressage global : plan d'adressage agrégé */

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

=== Adressage global : plan d'adressage agrégé ===

Ce plan, proposée dans le RFC 3587, précise la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Une adresse intègre trois niveaux de hiérarchie :

<tikz>
\clip (0.0, 0) rectangle (11.5,7);
% \draw[help lines] (0,0) grid (10,6);

\draw (0, 6.6) node [right] {Globale Unicast Address:};

\draw (0,5) node [right, draw, shade, top color = yellow, minimum width=1cm, minimum height=1cm] {\tt{001}};
\draw (1,5) node [right, draw, shade, top color = green, minimum width=3cm, minimum height=1cm] {Global Prefix};
\draw (4,5) node [right, draw, shade, top color = blue, minimum width=1.5cm, minimum height=1cm] {SID};
\draw (5.5,5) node [right, draw, shade, top color = black!50, minimum width=4.8cm, minimum height=1cm] {Interface ID};

\draw (0.5, 5.7) node {\tiny{3}};
\draw (2.5, 5.7) node {\tiny{45}};
\draw (4.7, 5.7) node {\tiny{16}};
\draw (8, 5.7) node {\tiny{64}};

\draw [snake=brace, mirror snake] (0, 4.20) -- (4, 4.20) node [below, midway] {\tiny{public topology}} node [below = 8pt, midway] {\tiny{given by the provider}} ;
\draw [snake=brace, mirror snake] (4, 4.20) -- (5.5, 4.20) node [below, midway] {\tiny{local topology}} node [below = 8pt, midway] {\tiny{assigned by network engineer}} ;
\draw [snake=brace, mirror snake] (5.5, 4.20) -- (10.3, 4.20) node [below, midway] {\tiny{link address}} node [below = 8pt, midway] {\tiny{auto or manual configuration}} ;
</tikz>



* une topologie publique codé sur 48 bits, allouée par le fournisseur d'accès;
* une topologie de site codé sur 16 bits. Ce champ permet de coder les numéros de sous réseau du site;
* un [[identifiant d'interface]] (64 bits) distinguant les différentes machines sur le lien.

Il existe plusieurs instanciations de ce plan d'adressage. Historiquement la première (préfixe <tt>3FFE::/16</tt>) a servi aux réseaux expérimentaux, puis une seconde (préfixe <tt>2001::/16</tt>) est définie par les autorités régionales pour les réseaux dits de production, enfin une troisième est dédiée (préfixe <tt>2002::/16</tt>) au mécanisme de transition [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]]. Ces instanciations sont différenciées par la valeur du préfixe initial de 16 bits (cf. Tableau). Très récemment, d'autres préfixes ont été libérés. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser. Il semble que cela pourrait remettre en cause l'attribution de préfixes de longueur 48 pour tous les utilisateurs au profit de préfixes plus long. Une version, à jour des allocations est disponible sur le site http://www.iana.org/assignments/ipv6-unicast-address-assignments.

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

[[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 récemment; la date d'arrêt a été symboliquement choisie le mardi 6 juin 2006 RFC 3701. En effet, si ce réseau a servi palier à l'absence d'opérateurs officiels au début de l'introduction d'IPv6, 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.

== Adresses gérées par les RIR ==

La valeur <tt>0x0001</tt> a été attribué par l'IANA pour un plan d'adressage où les autorités régionales attribuent les préfixes. Le préfixe initial est par conséquent <tt>2001::/16</tt>. Ce plan reproduit, en étendant la largeur des champs les principes de délégation et de gestion introduits en IPv4 par CIDR. Un site voulant se connecter reçoit de son fournisseur d'accès un préfixe global de longueur supérieure ou égale à 48 bits.

{{suivi |Plans d'adressage|Plans d'adressage|Lien-local|Adresses Lien-local}}

TdMbis

2008-11-20T10:28:24Z

Laurent Toutain: /* Table des matières */

=Table des matières=

''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage =
= Protocoles réseau et transport =
= Configuration automatique et contrôle =
= Nommage =
= Supports de transmission =
= Routage =
= Multicast =
= Sécurité =
= Mobilité dans IPv6 =
= Intégration d'IPv6 et des applications =
= Programmation d'applications=
= Supervision =
= Historique de la standardisation d’IPv6 =
= Bases whois=
= Bibliographie =

TdMbis

2008-11-20T10:19:57Z

Laurent Toutain: /* Table des matières */

TdMbis

2008-11-20T10:19:27Z

Laurent Toutain: New page: =Table des matières= ''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'édition originale, mais quand les articles se...

=Table des matières=

''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante:
* Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.
* Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)
* Questions ouvertes : Faire le point sur les aspects controversés
* Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.
* Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.
* Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

MediaWiki:Sidebar

2008-11-20T09:46:36Z

Laurent Toutain:

Adressage

2008-10-09T19:40:05Z

Laurent Toutain:

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle d'une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes [[bibliographie#BM95|[BM95]]], on obtient l'encadrement suivant où l'unité est le nombre d'adresses par mètre carré de surface terrestre (océans compris) :
<math>\int\limits_a^x f(\frac{\alpha}{2}\,)\,dx</math>

<math>1564 < adresses disponibles < 3911873538269506102</math>

<tikz>
\clip (-0.1, -0.1) rectangle (11.1,4.1);

\draw (1,1) node [thick,rounded corners=8pt, color=red] {toto};
</tikz>

D'autres calculs indiquent que l'on pourrait potentiellement attribuer 60 000 milliards de milliards d'adresses par habitant.

Ces calculs sont bien entendu complètement arbitraires. Il est difficile de prévoir l'utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d'adressage actuellement mis en oeuvre utilise un identifiant d'équipement sur 64 bits, c'est-à-dire la moitié de la taille de l'adresse. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d'équipements adressables est colossal.

Il ne faut toutefois pas faire un contre-sens sur l'interprétation de ces calculs. Le but d'IPv6 n'est pas d'attribuer une fois pour toute une adresse IPv6 à un équipement (ou à un être humain). Une adresse IPv6 n'a de sens et d'utilité que lors que l'équipement est connecté sur le réseau. De plus si l'emplacement sur le réseau de cet équipement change, l'adresse devra également être modifiée pour refléter ce déplacement.

Ce chapitre, après avoir défini ce que l'on attend d'une adresse dans l'Internet, passe en revue les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire les réseaux de tests et opérationnels. Il décrit également la manière de calculer les identifiants d'interface utilisé par plusieurs types d'adresses (voir également [[Supports de transmission]]).

== Qu'est-ce qu'une adresse ? ==

La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation.

* L'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP.
* La localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.

En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification... Cela implique une perte ou au mieux une renégociation des communications en cours.

Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation... Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue ; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchiques (CIDR) utilisées dans IPv4.

Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface ; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le coeur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possédera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.

== Structuration des adresses et agrégation ==

Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.

Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le sera pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.

D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.

[[Image:Cidr.png|thumb|frame|Evolution de la taille des tables de routage Source: http://www.cidr-report.org]]

En 2000, la progression linéaire de cette table a semblé compromise du fait :

* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important),
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.

Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :

* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30 pourcent,
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25 pourcent,
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20 pourcent,
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR, et à l'allocation séquencielle des blocks d'adresses contribue à plus de 75 pourcent de la taille de la table.

Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le coeur du réseau s'en trouvera quand même améliorée car :

* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes,
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation.
* des mécanismes de renumérotation automatiques permettent aux sites de changer facilement de préfixe quand cela est nécessaire.

Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.

Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Adressage

2008-10-09T18:51:16Z

Laurent Toutain:

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle d'une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes [[bibliographie#BM95|[BM95]]], on obtient l'encadrement suivant où l'unité est le nombre d'adresses par mètre carré de surface terrestre (océans compris) :
<math>\int\limits_a^x f(\frac{\alpha}{2}\,)\,dx</math>

<math>1564 < adresses disponibles < 3911873538269506102</math>

<tikz>
\clip (-0.1, -0.1) rectangle (11.1,4.1);

\draw (1,1) node [thick,rounded corners=8pt] {toto};
</tikz>

D'autres calculs indiquent que l'on pourrait potentiellement attribuer 60 000 milliards de milliards d'adresses par habitant.

Ces calculs sont bien entendu complètement arbitraires. Il est difficile de prévoir l'utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d'adressage actuellement mis en oeuvre utilise un identifiant d'équipement sur 64 bits, c'est-à-dire la moitié de la taille de l'adresse. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d'équipements adressables est colossal.

Il ne faut toutefois pas faire un contre-sens sur l'interprétation de ces calculs. Le but d'IPv6 n'est pas d'attribuer une fois pour toute une adresse IPv6 à un équipement (ou à un être humain). Une adresse IPv6 n'a de sens et d'utilité que lors que l'équipement est connecté sur le réseau. De plus si l'emplacement sur le réseau de cet équipement change, l'adresse devra également être modifiée pour refléter ce déplacement.

Ce chapitre, après avoir défini ce que l'on attend d'une adresse dans l'Internet, passe en revue les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire les réseaux de tests et opérationnels. Il décrit également la manière de calculer les identifiants d'interface utilisé par plusieurs types d'adresses (voir également [[Supports de transmission]]).

== Qu'est-ce qu'une adresse ? ==

La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation.

* L'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP.
* La localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.

En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification... Cela implique une perte ou au mieux une renégociation des communications en cours.

Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation... Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue ; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchiques (CIDR) utilisées dans IPv4.

Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface ; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le coeur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possédera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.

== Structuration des adresses et agrégation ==

Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.

Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le sera pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.

D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.

[[Image:Cidr.png|thumb|frame|Evolution de la taille des tables de routage Source: http://www.cidr-report.org]]

En 2000, la progression linéaire de cette table a semblé compromise du fait :

* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important),
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.

Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :

* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30 pourcent,
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25 pourcent,
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20 pourcent,
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR, et à l'allocation séquencielle des blocks d'adresses contribue à plus de 75 pourcent de la taille de la table.

Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le coeur du réseau s'en trouvera quand même améliorée car :

* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes,
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation.
* des mécanismes de renumérotation automatiques permettent aux sites de changer facilement de préfixe quand cela est nécessaire.

Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.

Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Adressage

2008-10-09T18:37:55Z

Laurent Toutain:

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur expérimenté et l'ingénieur réseau dans cette nouvelle version du protocole. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.

Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle d'une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes [[bibliographie#BM95|[BM95]]], on obtient l'encadrement suivant où l'unité est le nombre d'adresses par mètre carré de surface terrestre (océans compris) :
<math>\int\limits_a^x f(\frac{\alpha}{2}\,)\,dx</math>

<math>1564 < adresses disponibles < 3911873538269506102</math>

D'autres calculs indiquent que l'on pourrait potentiellement attribuer 60 000 milliards de milliards d'adresses par habitant.

Ces calculs sont bien entendu complètement arbitraires. Il est difficile de prévoir l'utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d'adressage actuellement mis en oeuvre utilise un identifiant d'équipement sur 64 bits, c'est-à-dire la moitié de la taille de l'adresse. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d'équipements adressables est colossal.

Il ne faut toutefois pas faire un contre-sens sur l'interprétation de ces calculs. Le but d'IPv6 n'est pas d'attribuer une fois pour toute une adresse IPv6 à un équipement (ou à un être humain). Une adresse IPv6 n'a de sens et d'utilité que lors que l'équipement est connecté sur le réseau. De plus si l'emplacement sur le réseau de cet équipement change, l'adresse devra également être modifiée pour refléter ce déplacement.

Ce chapitre, après avoir défini ce que l'on attend d'une adresse dans l'Internet, passe en revue les différents types d'adresses. Il explique en détail le plan d'adressage agrégé qui a été retenu pour construire les réseaux de tests et opérationnels. Il décrit également la manière de calculer les identifiants d'interface utilisé par plusieurs types d'adresses (voir également [[Supports de transmission]]).

== Qu'est-ce qu'une adresse ? ==

La distinction entre les notions d'annuaires, de noms, d'adresses et de routes est comprise depuis longtemps. Cependant, depuis quelques années, au sein de l'Internet, la compréhension du rôle d'une adresse réseau a évolué. Dans l'Internet, une adresse sert en fait à deux fonctions distinctes : identification et localisation.

* L'identification est utilisée pendant une connexion par chacun des intervenants pour reconnaître son interlocuteur. Cela permet entre autres de s'assurer de l'origine des paquets reçus. Cette vérification se fait dans les pseudo-en-têtes TCP ou dans les associations de sécurité d'IPsec. La durée de vie minimale d'un identificateur est celle d'une connexion TCP.
* La localisation est utilisée pour trouver un intermédiaire qui saura délivrer les paquets. La durée de vie de la fonction de localisation est assez grande. En fait, elle ne varie qu'en cas de changement de prestataire IP ou de réorganisation du site. En général la localisation est découpée en deux parties : localisation globale (identifiant le réseau) et locale, distinguant les machines sur un même réseau. La localisation est intrinsèquement liée aux fonctions de routage d'IP.

En IPv4, on confond identification et localisation en une seule entité, l'adresse IP, globalement unique dans l'Internet. Cette construction a un prix : lors de la renumérotation d'un site, ou lorsqu'un mobile se déplace, la localisation change. Avec l'approche IPv4, l'adresse IP change, et donc l'identification... Cela implique une perte ou au mieux une renégociation des communications en cours.

Lors des études initiales pour IPv6, il a été proposé de séparer ces deux fonctions pour pouvoir résoudre simplement les problèmes de renumérotation, mobilité, multi-domiciliation... Ceci est encore un sujet de recherche. Cette proposition n'a donc pas été retenue ; en IPv6 comme en IPv4, l'adresse sert à la fois pour l'identification et la localisation. En effet, le plan d'adressage choisi dans un premier temps est une extension des règles d'adressage hiérarchiques (CIDR) utilisées dans IPv4.

Un autre débat est de savoir si une adresse identifie une machine ou une interface. Cette distinction n'est pas très importante dans le cas d'une machine simple ne possédant qu'une seule interface ; elle le devient dans le cas où elle en possède plusieurs ou est multi-domiciliée. En effet pour essayer de simplifier les tables de routage dans le coeur de réseau, si un site est connecté à plusieurs fournisseur d'accès, il possédera autant de préfixes IPv6 que de fournisseurs. Contrairement à IPv4, où l'on associe généralement qu'une seule adresse à une interface, une interface possède plusieurs adresses IPv6.

== Structuration des adresses et agrégation ==

Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de router des ensembles de réseaux identifiés par un seul descripteur. CIDR apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec les adresses déjà allouées.

Attribuer une adresse à un équipement est un processus complexe, basé sur un compromis entre la facilité d'attribution et la facilité de gestion. Idéalement, pour minimiser la taille de routage, le réseau devrait avoir une topologie en arbre, cela rendrait l'adressage hiérarchique très efficace. Dans la réalité pour des raisons économiques, techniques, géographiques ou de performances, le réseau est beaucoup plus complexe et peut être vu comme un graphe. Il faut introduire des exceptions dans les tables de routages pour refléter cette topologie. On voit que pour avoir l'adressage le plus efficace possible, il faut dans ce graphe trouver la représentation arborescente qui génère le moins d'exceptions possibles. Or s'il était possible aujourd'hui de trouver une représentation valide, elle ne le sera pas nécessairement demain. En conséquence, la définition du plan d'adressage doit être la plus souple possible pour permettre une évolution de nature imprévisible.

D'autant plus que l'agrégation pour IPv4 ne semble plus aussi efficace. La figure suivante donne l'évolution de table de routage dans le coeur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.

[[Image:Cidr.png|thumb|frame|Evolution de la taille des tables de routage Source: http://www.cidr-report.org]]

En 2000, la progression linéaire de cette table a semblé compromise du fait :

* de la baisse du coût des liaisons longues distances, permettant une multi-domiciliation (''multi-homing'') des sites pour des raisons de fiabilité (en cas de panne d'un opérateur, le trafic pourra passer par un autre), de performances (aller directement sur le réseau avec lequel le site à un trafic important),
* le manque d'adresses IPv4 qui force les opérateurs à allouer des préfixes de plus en plus long.

Depuis, les opérateurs ont fortement aggrégé pour revenir à une progression linéaire de la table. Des études [[bibliographie#BTC02|[BTC02]]] montrent que :

* la multi-domiciliation, c'est-à-dire la connexion d'un site à plusieurs opérateurs pour fiabiliser l'accès, ajoute un surcoût de 20 à 30 pourcent,
* le partage de charge, c'est-à-dire réduire l'agregation pour annoncer un sous-ensemble de préfixe à chaque opérateur, induit un surcoût de 20 à 25 pourcent,
* de mauvaises règles d'agrégation induisent une surcharge de 15 à 20 pourcent,
* la fragmentation de l'espace d'adressage liée à la gestion des préfixes avant CIDR, et à l'allocation séquencielle des blocks d'adresses contribue à plus de 75 pourcent de la taille de la table.

Actuellement, pour pouvoir assurer une bonne agrégation, les règles utilisées par CIDR pour IPv4 sont conservées. Mais la gestion des tables de routage dans le coeur du réseau s'en trouvera quand même améliorée car :

* dès le début le plan d'adressage est hiérarchique, éliminant les longs préfixes,
* les sites multi-domiciliés posséderont autant d'adresses que de fournisseurs, permettant ainsi de garantir une agrégation.
* des mécanismes de renumérotation automatiques permettent aux sites de changer facilement de préfixe quand cela est nécessaire.

Si un plan d'adressage hiérarchique semble actuellement le plus adapté, d'autres règles de numérotation pourraient être utilisées dans le futur, comme par exemple, les coordonnées géographiques de l'équipement. Ces techniques ne sont actuellement utilisées que dans quelques laboratoires de recherche pour des réseaux ad hoc, mais il reste assez de place dans l'espace d'adressage pour prendre en compte ces nouveaux types de réseaux si un jour ils se généralisent.

Le choix d'un plan d'adressage a fait l'objet de nombreux débats à l'IETF. Il a été beaucoup plus difficile à définir que le format du paquet IPv6 présenté au chapitre suivant. Plusieurs plans ont été proposés puis abandonnés. Ces divers plans d'adressages sont commentés dans le chapitre sur l'[[La standardisation d'IPv6#plan|Historique]] de la standardisation d'IPv6. Le présent chapitre se contente de décrire les différents [[plans d'adressage]] actuellement utilisés.

{{suivi |Introduction|Introduction|Plans d'adressage|Plans d'adressage}}

Main Page

2008-10-02T19:34:28Z

Laurent Toutain: Accueil moved to Main Page

{{Annonce|Serveur de nouveau en ligne ! Si vous rencontrez un problème, contactez bruno.stevant AT telecom-bretagne.eu}}

=<center>'''IPv6 Théorie et Pratique'''</center>=
<center>''Gisèle Cizault''</center>

Bonjour,

Les évolutions autour du protocole IPv6 sont de plus en plus rapides. C'est
bon signe pour la vitalité du protocole, mais il est de plus en plus difficile
que la version papier du livre IPv6 théorie et pratique (ISBN 284177337X) soit toujours à jour.

Aussi nous avons décidé avec les éditions O'Reilly et le [http://www.g6.asso.fr G6]
et le support technique du [http://www.point6.net Point6]
d'en faire une version en ligne (accessible en IPv4 et IPv6). Ce serveur reprend
intégralement la quatrième édition du livre IPv6 théorie et Pratique paru en Novembre
2005 chez O'Reilly. Le but de ce site est de le faire évoluer le texte pour suivre
au plus près les évolutions d'IPv6, d'établir un dialogue avec les lecteurs répondre
plus clairement aux demandes des utilisateurs. D'un point de vue pratique, il permettra
également aux auteurs de mieux collaborer pour maintenir à jour les informations.

Vous pouvez commencer votre lecture par la [[Table des matières|table des matières]] ou le [[Préambule|préambule]]

L'intégralité du texte est maintenant en ligne, nous allons maintenant rendre les figures plus lisibles. Cela
demande un peu plus de temps car il faut remonter aux sources des contributions des différents auteurs.

Bonne Lecture

Gisèle Cizault.

PS: un [http://www.g6.asso.fr/blog blog] est également à votre disposition pour commenter
l'actualité, les avantages ou les problèmes techniques liés l'arrivée d'IPv6.

Talk:Main Page

2008-10-02T19:34:28Z

Laurent Toutain: Talk:Accueil moved to Talk:Main Page

je propose de faire un lien sur le site d'O'Reilly pour commander notre bouquin ... ?

+BT.

Fait, j'ai mis une ref sur le n° ISBN. Cette ref pointe sur la fnac, amazon, et alapage.

LT

*LT: DHCPv6 doit être revu
*LT: ULA

Thierry Ernst

Hello,

A propos du livre, je pense qu'il faudra scinder la partie mobilite
entre host mobility support (MIPv6, FMIPv6, etc) et network mobility
support.

Ceci dit, je vois deja certain penser que la partie mobilite ne doit pas
representer plus qu'une certaine part dans le livre, donc j'envisage
d'ecrire personnellement un livre sur NEMO (sans doute

Autre chapitre qui pourrait faire son apparition, ce serait le
"multihoming", qui pourrait traiter a la fois de Shim6 (mais Shim6 n'est
peut-etre pas encore suffisamment avance techniquement ?), et le
multihoming dans MIPv6 + NEMO (Monami6), qui est nettement plus avance.

Enfin, un chapiter independant sur les usages d'IPv6 (automobile,
domotique, sante, telephonie) me semblerait adequat.

PS: quelqu'un pourrait avoir la bonte de changer mon (mes) adresses
email pour une seule et unique: thierry.ernst@inria.fr (je ne crois pas
pouvoir proceder a la manip de moi-meme, mais si je me trompe n'hesitez
pas de me dire de bien chercher ;-)

Thierry.

Accueil

2008-10-02T19:34:28Z

Laurent Toutain: Accueil moved to Main Page

#REDIRECT [[Main Page]]

Talk:Accueil

2008-10-02T19:34:28Z

Laurent Toutain: Talk:Accueil moved to Talk:Main Page

#REDIRECT [[Talk:Main Page]]

Template:Chapitre

2008-07-31T17:30:36Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; background-color:#FFFFFF"
|-
| width="100px" |[[image:blue_ball.png|100px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Entete

2008-07-31T17:30:21Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
|[[image:singe.png|100px]] || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big> || [[image:singe.png|100px]]
|-
|}

Template:Entete

2008-07-31T17:28:44Z

Laurent Toutain:

{| border ="0"
|-
|[[image:singe.png|100px]] || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big> || [[image:singe.png|100px]]
|-
|}

Template:Entete

2008-07-31T17:26:39Z

Laurent Toutain:

{| border ="0"
|-
| rowspan=3 |[[image:singe.png|100px]] ||
|-
| || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
| ||
|-
|}

Template:Entete

2008-07-31T17:26:14Z

Laurent Toutain:

{| border ="0"
|-
| rowspan=3 |[[image:singe.png|100px]] || toto
|-
| || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
| || titi
|-
|}

Template:Entete

2008-07-31T17:25:47Z

Laurent Toutain:

{| border ="0"
|-
| rowspan=3 |[[image:singe.png|100px]] ||
|-
| || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
| ||
|-
|}

Template:Entete

2008-07-31T17:24:54Z

Laurent Toutain:

{| border ="0"
|-
| colspan=3 |[[image:singe.png|100px]] ||
|-
| || style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
| ||
|-
|}

Template:Entete

2008-07-31T17:24:09Z

Laurent Toutain:

{| border ="0"
|-
| colspan=3 |[[image:singe.png|100px]] ||style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|
|-
|
|-
|}

Template:Entete

2008-07-31T17:22:53Z

Laurent Toutain:

{| border ="0"
|-
| [[image:singe.png|100px]] ||style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

Template:Entete

2008-07-31T17:22:33Z

Laurent Toutain:

{|
|-
| [[image:singe.png|100px]] ||style="background:#00CCFF;" align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

Template:Entete

2008-07-31T17:22:10Z

Laurent Toutain:

{|
|-
| [[image:singe.png|100px]] ||style="background:#00CCFF;"| align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

File:Singe.png

2008-07-31T17:21:36Z

Laurent Toutain:

Template:Entete

2008-07-31T17:15:29Z

Laurent Toutain:

{| style="background:#00CCFF;"
|-
| [[image:singe.png|100px]] || align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

Template:Chapitre

2008-07-31T17:13:48Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| width="100px" |[[image:blue_ball.png|100px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Chapitre

2008-07-31T17:13:14Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| width="100px" |[[image:blue_ball.png|90px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Chapitre

2008-07-31T17:12:44Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| width="150px" |[[image:blue_ball.png|100px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Chapitre

2008-07-31T17:12:10Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| !width="150px" |[[image:blue_ball.png|100px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Chapitre

2008-07-31T17:11:52Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| !width="50" |[[image:blue_ball.png|100px]] || bgcolor="#00CCFF" | <big>{{{1}}}</big>
|-
|}

Template:Chapitre

2008-07-31T17:06:54Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| [[image:blue_ball.png|20px]] || bgcolor="#00CCFF" | {{{1}}}
|-
|}

Template:Chapitre

2008-07-31T17:06:36Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| [[image:blue_ball.png|20px]] | bgcolor="#00CCFF" | {{{1}}}
|-
|}

File:Blue ball.png

2008-07-31T17:06:07Z

Laurent Toutain:

Template:Chapitre

2008-07-31T17:02:35Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|- bgcolor="#00CCFF"
| [[image:blue_ball.png|20px]] || {{{1}}}
|-
|}

Template:Chapitre

2008-07-31T09:19:00Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|- bgcolor="#00CCFF"
| * || {{{1}}}
|-
|}

Template:Chapitre

2008-07-31T09:18:15Z

Laurent Toutain:

{| border="0" align="center" cellpadding="3px" style="width:100%; border: 1px solid #999; background-color:#FFFFFF"
|-
| * || {{{1}}}
|-
|}

Template:Chapitre

2008-07-30T18:25:31Z

Laurent Toutain:

{|
|-
| * || {{{1}}}
|-
|}

MOOC:Interviews

2008-07-30T18:23:10Z

Laurent Toutain:

{{Entete|Adresses}}

__NOTOC__

{{Chapitre|Specifications}}

= Mises en oeuvre =
== Linux ==
== BSD ==
== XP ==
== Vista ==
== Mac OS X ==
= Questions ouvertes=
= Sujets de recherche=
= Références=
= Tutoriaux/Etudes de cas=

Template:Entete

2008-07-30T18:19:39Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

Template:Entete

2008-07-30T18:19:17Z

Laurent Toutain:

{| style="background:#efefef;", border=1
|-
| align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

MOOC:Interviews

2008-07-30T18:17:49Z

Laurent Toutain:

{{Entete|Adresses}}

__NOTOC__

= Specifications =
= Mises en oeuvre =
== Linux ==
== BSD ==
== XP ==
== Vista ==
== Mac OS X ==
= Questions ouvertes=
= Sujets de recherche=
= Références=
= Tutoriaux/Etudes de cas=

Template:Entete

2008-07-30T18:16:20Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| align="center" width="1000px"|<big>'''{{{1}}}'''</big>
|-
|}

Template:Entete

2008-07-30T18:15:26Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| align="center" width="1000px"|<big>{{{1}}}</big>
|-
|}

Template:Entete

2008-07-30T16:31:32Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| align="center" width="1000px"|{{{1}}}
|-
|}

MOOC:Interviews

2008-07-30T16:08:41Z

Laurent Toutain:

{{Entete|Adresses}}

= Specifications =
= Mises en oeuvre =
== Linux ==
== BSD ==
== XP ==
== Vista ==
== Mac OS X ==
= Questions ouvertes=
= Sujets de recherche=
= Références=
= Tutoriaux/Etudes de cas=

Template:Entete

2008-07-30T16:07:42Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| width="1000px"|{{{1}}}
|-
|}

Template:Entete

2008-07-30T16:07:09Z

Laurent Toutain:

{| style="background:#efefef;"
|-
| width="100px"|{{{1}}}
|-
|}

Template:Entete

2008-07-30T15:44:13Z

Laurent Toutain:

{| style="background:#efefef;"
|-
|align="center", width="100%"|{{{1}}}
|-
|}

Template:Entete

2008-07-30T15:43:49Z

Laurent Toutain:

{| style="background:#efefef;"
|-
|align="center", width="100%"|{{{1}}}
|}