Difference between revisions of "AdressageBis-Fondamentaux"

From Livre IPv6

(→‎Durée de vie des adresses)
(→‎Structuration de 'identifiant d'interface (IID))
Line 240: Line 240:
 
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sours-réseaux différents pour cette communauté.
 
* <tt>2001:DB8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sours-réseaux différents pour cette communauté.
  
−
==== Structuration de 'identifiant d'interface (IID) ====
 
  
−
Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:
 
−
 
−
* manuelle,
 
−
* basée sur l'adresse de niveau 2 de l'interface,
 
−
* aléatoire,
 
−
* cryptographique.
 
−
 
−
===== Manuel =====
 
−
{{HorsTexte|Le resolveur DNS|Le résolveur DNS est le cas le plus flagrant ; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas  utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.}}
 
−
Pour les serveurs les plus utilisé, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.
 
−
Il existe plusieurs techniques plus ou moins mnémotechniques :
 
−
* incrémenter l'identifiant d'interface à chaque nouveau serveur créé
 
−
 
−
<tt>2001:DB8:1234:1::1</tt>
 
−
<tt>2001:DB8:1234:1::2</tt>
 
−
...
 
−
 
−
* reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interace. Par exemple si un serveur a comme adresse IPv4 <tt>192.0.2.123</tt>, son adresse IPv6 sera :
 
−
 
−
<tt>2001:DB8:1234:1::7B</tt>
 
−
ou plus simplement
 
−
<tt>2001:DB8:1234:1::123</tt>
 
−
 
−
* reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvient de conduire à des adresses plus longues à taper :
 
−
 
−
<tt>2001:DB8:1234:1::192.0.2.123</tt>
 
−
 
−
===== Dérivé de l'adresse de l'interface=====
 
−
 
−
L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.
 
−
 
−
Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiant d'interface manuel pour les serveur.
 
−
 
−
Ces identifiants d'interface étant stable dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. il pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.
 
−
 
−
Si ces inconvénients sont jugés important par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement. 
 
−
 
−
====== EUI-64 ======
 
−
 
−
<tikz title="Transformation d'une adresse MAC en identifiant d'interface">
 
−
 
−
\clip (0, 1) rectangle (11,5);
 
−
% \draw[help lines] (0,0) grid (11,4);
 
−
 
−
 
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{u}g}}};
 
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
 
−
\draw (2, 1.25)  rectangle+(3, 0.5);
 
−
 
−
\draw (5, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};
 
−
 
−
</tikz>
 
−
 
−
L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.
 
−
 
−
 
−
Il existe plusieurs méthodes pour construire l'identifiant :
 
−
{{HorsTexte|Ordre de transmission|L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs, le premier bit transmis est le bit de poids faible, c'est-à-dire le bit de droite. Ainsi sur le support physique le bit <tt>g</tt>, puis le bit <tt>u</tt> puis les bits suivants sont transmis. }}
 
−
 
−
* Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64.
 
−
: Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits <tt>u</tt> (septième bit du premier octet) et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale :
 
−
:* <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
 
−
:* <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g = 0</tt>), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g = 1</tt>), par exemple une adresse de multicast.
 
−
 
−
<tikz title="Identificateur d'interface dérivé d'une EUI-64">
 
−
 
−
\clip (0, 1) rectangle (11,5);
 
−
% \draw[help lines] (0,0) grid (11,4);
 
−
 
−
 
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
 
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
 
−
\draw (2, 1.25)  rectangle+(3, 0.5);
 
−
 
−
\draw (5, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=5cm, minimum height=0.5cm] {\tiny{Serial Number}};
 
−
 
−
</tikz>
 
−
* L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit <tt>u</tt> (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser <tt>1</tt> pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur <tt>0</tt> pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de <tt>1</tt>.
 
−
 
−
======MAC-48======
 
−
 
−
<tikz title="Transformation d'une adresse MAC en identifiant d'interface">
 
−
 
−
\clip (0, 1) rectangle (11,5);
 
−
% \draw[help lines] (0,0) grid (11,4);
 
−
 
−
\only<2-> {
 
−
\draw (3, 4.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
 
−
\draw (4, 4.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
 
−
\draw (3, 4.25)  rectangle+(3, 0.5);
 
−
 
−
\draw (0,4.5) node [right] {MAC-48};
 
−
 
−
\draw (6, 4.5)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
 
−
 
−
 
−
\draw (2, 3)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_00}}};
 
−
\draw (3, 3)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
 
−
\draw (2, 2.75)  rectangle+(3, 0.5);
 
−
 
−
\draw (7, 3)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
 
−
 
−
\draw (6,4.5) -- (6, 4) -- (5, 3.5) -- (5, 3);
 
−
\draw (6,4) -- (7, 3.5) -- (7, 3);
 
−
\draw (3, 4.5) -- (3, 4) -- (2, 3.5) -- (2, 3);
 
−
\draw (9, 4.5) -- (9, 4) -- (10, 3.5) -- (10, 3);
 
−
 
−
\draw (5, 3)  node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};
 
−
 
−
\draw (0,3) node [right] {EUI-64};
 
−
}
 
−
 
−
\only<3-> {
 
−
 
−
\draw (2, 1.5)  node [right, shade, top color = yellow, minimum width=1cm, minimum height=0.5cm] {\tiny{\tt{\_\_\_\_\_\_\alert{1}0}}};
 
−
\draw (3, 1.5)  node [right, shade, top color = yellow, minimum width=2cm, minimum height=0.5cm] {\tiny{Vendor}};
 
−
\draw (2, 1.25)  rectangle+(3, 0.5);
 
−
 
−
\draw (7, 1.5)  node [right, draw, shade, top color = blue!80, minimum width=3cm, minimum height=0.5cm] {\tiny{Serial Number}};
 
−
 
−
\draw (5, 1.5)  node [right, draw, shade, top color = red!50, minimum width=2cm, minimum height=0.5cm] {\tiny{\tt{0xFFFE}}};
 
−
 
−
\draw (2,3) -- (2, 1.5);
 
−
\draw (10,3) -- (10, 1.5);
 
−
\draw (0,1.5) node [right] {IID};
 
−
}
 
−
 
−
</tikz>
 
−
 
−
* Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, puis le bit <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.
 
−
 
−
======Cas Particuliers======
 
−
* Si une interface possède une adresse locale unique sur le lien, mais non universelle (par exemple le format d'adresse IEEE 802 sur 2 octets ou une adresse sur un réseau Appletalk), l'identifiant d'interface est construit à partir de cette adresse en rajoutant des 0 en tête pour atteindre 64 bits.
 
−
 
−
 
−
{{HorsTexte|Erreur de l'IETF|A noter que l'IETF s'est trompée quand elle a défini l'algorithme de conversion. En effet, l'ajout de la valeur <tt>0xFFFE</tt> concerne les EUI-48, c'est-à-dire des identifiants, alors qu'Ethernet utilise des MAC-48, c'est-à-dire des adresses (ils servent à transporter des trames vers le bon destinataire). La bonne valeur aurait été <tt>0xFFFF</tt>. Mais cette erreur n'a aucune conséquence pour l'identification des équipements, elle n'a donc pas été corrigée par la suite.}}
 
−
 
−
* Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. <br>S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.
 
−
 
−
===== Valeur aléatoire =====
 
−
 
−
L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.
 
−
 
−
Pour couper court à toute menace de boycott d'un protocole qui «menacerait la vie privée», il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état «déprécié» et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.
 
−
 
−
Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows Vista, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface.
 
−
 
−
Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.
 
−
 
−
En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.
 
−
 
−
===== Cryptographique =====
 
−
 
−
{{HorsTexte|Encore un sujet de recherche|L'usage de ces adresses n'est pas encore généralisé. Shim6 pour la gestion de la multi-domiciliation ou SEND pour sécuriser la découverte de voisins y on recours.}}
 
−
Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : ''Cryptographic Generated Addresses'') à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.
 
  
 
=== Adressage local : adresses lien-local ===
 
=== Adressage local : adresses lien-local ===

Revision as of 09:48, 3 July 2009

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. En effet la taille de l'adresse reste fixe mais passe de 32 à 128 bits. Même si les principes sont fortement similaires à ceux employés dans IPv4, cet adressage apparaît à première vue beaucoup plus complexe. Il est intéressant d'en comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.


Ce chapitre 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).

Aspects fondamentaux de l'adressage IPv6

Représentation des adresses

La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère «:», chacun d'eux étant représenté en hexadécimal. Par exemple : 

2001:0DB8:0000:0000:0400:A987:6543:210F

Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête : 

2001:DB8:0:0:400:A987:6543:210F

En outre plusieurs champs nuls consécutifs peuvent être abrégés par «::». Ainsi l'adresse précédente peut s'écrire comme suit : 

2001:DB8::400:A987:6543:210F

Naturellement, pour éviter toute ambiguïté, l'abréviation «::» ne peut apparaître qu'une fois au plus dans une adresse. Les cas extrêmes sont l'adresse indéfinie (utilisée pour désigner les routes par défaut) à tous les bits à zéro et qui se note de manière compacte : 

::

et l'adresse de bouclage (loopback), équivalent du préfixe 127/8 dont tous les bits sont à zéro sauf le dernier et qui s'écrit : 

::1

La représentation des préfixes IPv6 est similaire à la notation CIDR RFC 1519 utilisée pour les préfixes IPv4. Un préfixe IPv6 est donc représenté par la notation :

adresse-ipv6/longueur-du-préfixe-en-bits

Les formes abrégées avec «::» sont autorisées. 

2001:0DB8:7654:3210:0000:0000:0000:0000/64
2001:DB8:7654:3210:0:0:0:0/64
2001:DB8:7654:3210::/64

Le seul piège de cette notation vient des longueurs de préfixes qui ne sont pas en frontière de «:». Ainsi le préfixe 3EDC:BA98:7654:3::/56 équivaut en réalité à 3EDC:BA98:7654:0000::/56 car il s'écrit 3EDC:BA98:7654:0003::/56.

On peut combiner l'adresse d'une interface et la longueur du préfixe réseau associé en une seule notation. 

2001:DB8:7654:3210:945:1321:ABA8:F4E2/64

Ces représentations peuvent apparaître beaucoup plus complexes qu'avec IPv4, mais leur attribution répond à des règles strictes, ce qui favorise leur mémorisation.

Dans certains cas, une adresse (voire plusieurs adresses) IPv4 peut être contenue dans une adresse IPv6. Pour les faire resortir, la notation classique d'IPv4 peut être utilisée au sein d'une adresse IPv6. Ainsi : 

::128.12.13.14

représente une adresse IPv6 composée de 96 bits à 0 suivit des 32 bits de l'adresse IPv4 128.12.13.14


Il est pourtant parfois nécessaire de manipuler littéralement des adresses IPv6. Le caractère ":" utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi utilisé pour indiquer le numéro de port. Ainsi l'URL 

http://2001:DB8:12::1:8000/

peut aussi bien indiquer le port 8000 sur la machine ayant l'adresse IPv6 2001:DB8:12::1, que la machine 2001:DB8:12::1:8000 en utilisant le port par défaut. Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre "[ ]". L'adresse précédente s'écrirait : 

http://[2001:DB8:12::1]:8000/

ou 

http://[2001:DB8:12::1:8000]/

suivant les cas. Cette représentation peut être étendue à d'autres domaines comme X-window ou au protocole de signalisation téléphonique SIP.


Type des adresses

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast. Le premier de ces types désigne une interface unique. Un paquet envoyé à une telle adresse, sera donc remis à l'interface ainsi identifiée. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire désignant sans ambiguïté une machine sur le réseau Internet et celles qui auront une portée locale (lien ou site). Ces dernières ne pourront pas être routées sur l'Internet.

Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des noeuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.

Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées par des adresses de type multicast qui saturent moins un réseau local constitué de commutateurs. L'absence de broadcast augmente la résistance au facteur d'échelle d'IPv6 dans les réseaux commutés.

Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est principalement expérimental, voir Adresses anycast.

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : http://www.iana.org/assignments/ipv6-address-space) donne la liste de ces préfixes. La plage «réservée» du préfixe 0::/8 est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.


Préfixe IPv6 Allouer Référence
0000::/8 Réservé pour la transition et loopback RFC 3513
0100::/8 Réservé RFC 3513
0200::/7 Réservé (ex NSAP) RFC 4048
0400::/6 Réservé (ex IPX) RFC 3513
0800::/5 Réservé RFC 3513
1000::/4 Réservé RFC 3513
2000::/3 Unicast Global RFC 3513
4000::/3 Réservé RFC 3513
6000::/3 Réservé RFC 3513
8000::/3 Réservé RFC 3513
A000::/3 Réservé RFC 3513
C000::/3 Réservé RFC 3513
E000::/4 Réservé RFC 3513
F000::/5 Réservé RFC 3513
F800::/6 Réservé RFC 3513
FC00::/7 Unique Local Unicast RFC 4193
FE00::/9 Réservé RFC 3513
FE80::/10 Lien-local RFC 3513
FEC0::/10 Réservé RFC 3879
FF00::/8 Multicast RFC 3513

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

Durée de vie des adresses

TODO A déplacer dans Découverte de voisins

IPv6 généralisant le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs. Il ne peuvent plus être attribués "à vie" aux équipements. Pour faciliter la renumérotation d'une machine l'attribution d'une adresse à une interface est faite temporairement, les adresses IPv6 ne sont pas données mais prêtées. Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide, elle est supprimée de l'interface et devient potentiellement assignable à une autre interface. Une adresse invalide ne doit jamais être utilisée comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30 jours, mais cette durée peut être prolongée, ou portée à l'infini. L'adresse lien-local a une durée de vie illimitée.

États successifs d'une adresse sur une interface
Figure : États successifs d'une adresse sur une interface

La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse, sinon toutes les communications TCP, qui l'utilisent comme identificateur de connexion, seraient immédiatement coupées. Ceci entraînerait des perturbations importantes au niveau des applications.

Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses valides à une même interface. Ensuite pour effectuer le choix de l'adresse à utiliser, un état est associé. Il indique dans quelle phase de sa durée de vie une adresse se situent vis à vis de l'interface. Le premier de ces états est qualifié de préféré : l'utilisation n'est aucunement restreinte. Peu avant son invalidation l'adresse passe dans un état de déprécié. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée ne doit plus être utilisée comme adresse de source pour les nouvelles communications (comme l'établissement de connexion TCP). Par contre l'adresse dépréciée peut encore servir d'adresse de source dans le cas des communications existantes. Les paquets reçus à une adresse dépréciée continuent à être remis normalement. À la durée de vie de validité d'un adresse, il est également associé une durée de vie pour son état préféré. La figure États successifs d'une adresse sur une interface représente les différents états que prend une adresse lorsqu'elle est allouée à une interface.

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. Il est géré de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

Adresses Globales
Figure : Adresses Globales

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

Structuration du prefixe global (GP)

Appréhender les tailles

France Télécom a obtenu du RIPE-NCC un /19. Si l'on enlève les troix premiers bits 001 désignant le plan d'adressage, il est donc possible d'avoir 216 opérateurs. Sachant qu'il y a 192 pays à l'ONU, ils pourraient abritrer 320 opérateurs de taille de FT. Chacun pouvant attribuer jusqu'à 229 /48, soit 536 870 912 sites

A part le préfixe 2002:: qui est est réservé au mécanisme de transition 6to4, cet espace est géré hierarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12 (cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site http://www.sixxs.net/tools/grh/ donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un /56. 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.

TODO Ajouter comment obtenir un préfixe auprès de RIPE-NCC

Structuration de l'identifiant de sous-réseau (SID)

Il n'existe pas de règles pour allouer les identificateurs de sous-réseau au sein d'un site. Plusieurs techniques (non exclusives) peuvent être utilisées :

  • numéroter de manière incrémentale les sous-réseaux: 0001, 0002, ... Cette technique est simple a mettre en œuvre dans des réseaux expérimentaux, mais elle peut conduire à un plan d'adressage à plat difficile à mémoriser. Elle peut être utilisée par exemple pour un sous-réseau dédié aux serveur pour simplifier l'écriture et la mémorisation des adresses.
  • utiliser le numéro de VLAN. Elle permet d'éviter de mémoriser plusieurs niveau de numérotation.
  • séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées pour à la gestion de ces sous-réseau pour la partie de droite. A titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :
Communauté 4bits 8bits 4bits
Infrastructure 0 valeurs spécifiques
Tests 1 valeurs spécifiques
Tunnels 6 allocation de /60 aux utilisateurs
Invités Wi-Fi 8 valeurs spécifiques
Personnels A Entité Sous-Réseaux
Etudiants E Entité Sous-Réseaux
Autres (Start up, etc.) F valeurs spécifiques
Affectation des SID dans une université

Ainsi, le préfixe:

  • 2001:DB8:1234::/52 servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront pris dans cet espace,
  • 2001:DB8:1234:8000::/52 servira pour le réseau wi-fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés,
  • 2001:DB8:1234:E000::/52 servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sours-réseaux différents pour cette communauté.


Adressage local : adresses lien-local

Les adresses de type lien-local (link local use address) sont des adresses dont la validité est restreinte à un lien, c'est-à-dire l'ensemble de interfaces directement connectées sans routeur intermédiaire : par exemple machines branchées sur un même Ethernet, machines reliées par une connexion PPP, ou extrémités d'un tunnel. Les adresses lien-local sont configurées automatiquement à l'initialisation de l'interface et permettent la communication entre noeuds voisins. L'adresse est obtenue en concaténant le préfixe FE80::/64 aux 64 bits de l'identifiant d'interface. L'identifiant d"interface est généralement basé sur l'adresse MAC. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

Adresses Lien-local
Figure : Adresses Lien-local

Ces adresses sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins (neighbor discovery) et de découverte de routeurs (router discovery). Ce sont de nouveaux dispositifs, le premier supplantant en particulier le protocole ARP (Address Resolution Protocol), qui permettent pas à un réseau local de se configurer automatiquement (voir Découverte de voisins). Elles sont également largement utilisées par les protocoles de routage soit pour l'échange de données (cf. RIPng, OSPFv3), soit dans les tables de routage puisque le champ prochain routeur est toujours un équipement directement accessible sur le lien.

Unicité sur le lien

Les adresses lien-local sont uniques à l'intérieur d'un lien. Le protocole de détection de duplication d'adresse (voir Détection d'adresse dupliquée) permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents, ou entre deux interfaces d'un même noeud est autorisée.

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

Le fait que ces adresses aient une portée très faible les limite dans la pratique au cas où un démarrage automatique (bootstrap) est nécessaire. Leur usage ne doit pas être généralisé dans les applications classiques en régime stabilisé.

Portée de l'adresse (scoped address)

Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement -I permet de la désigner.

Unique Local Address

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : Unique Local Address). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les caractéristiques suivantes :

  • Prefixe globalement unique.
  • Préfixe clairement définit facilitant le filtrage sur les routeurs de bordure.
  • Permet l'interconnexion de sites sans générer de conflit d'adresse et sans nécessiter de renumérotation.
  • Indépendantes des fournisseurs d'accès à l'Internet et ne nécessitent donc pas de connectivité.
  • Pas de conflit en cas de routage par erreur en dehors d'un site.
  • Aucune différences pour les applications, qui peuvent les considérer comme des adresses globales unicast standard.

Unique Local Addresses
Figure : Unique Local Addresses

Les adresses uniques locales sont créées en utilisant un identifiant global (Global ID) généré pseudo-aléatoirement. Ces adresses suivent le format suivant :

  • Prefix (7 bits) : FC00::/7 préfixe identifiant les adresses IPv6 locales (ULA)
  • L (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future.
  • Global ID (40 bits) : Identifiant global utilisé pour la création d'un préfixe unique (Globally Unique Prefix).
  • Subnet ID (16 bits) : Identifiant d'un sous réseau à l'intérieur du site.
  • Interface ID (64 bits) : L'indentifiant d'interface tel que définit dans Identifiant d'interface.

Le site http://www.sixxs.net/tools/grh/ula/ permet de créer et d'enregistrer son adresse ULA à partir d'une adresse MAC.

Adresses Multicast

porté et porté

Il ne faut pas confondre la porté d'une adresse link-local ou multicast qui désigne l'interface par laquelle sera émis le paquet et la porté d'un groupe multicast qui désigné l'étendue de la couverture

Cette section décrit brièvement le système d'adressage multicast IPv6 et ne s'intéresse qu'aux adresses utilisées localement par les protocoles directements lié à IPv6 (Découverte de voisins, DHCPv6,...). Pour plus de détails sur le multicast en général, se reporter au chapitre Multicast. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.

Structure de l'adresse IPv6 Multicast
Figure : Structure de l'adresse IPv6 Multicast

Les adresses multicast IPv6 sont dérivées du préfixe FF00::/8. Le champ drapeaux de 4 bits est défini de la manière suivante :

  • Seul le bit T (comme Transient) du champ drapeaux est initialement décrit dans le RFC 3513. La valeur 0 indique une adresse multicast bien connue gérée par une autorité. La valeur 1 indique une valeur temporaire.
  • Les bits P et R sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
  • Le bit de poids fort du champ drapeaux n'est pas encore attribué.

Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.

Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (scope en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (Time To Live), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies :

  • 1 - node-local : Les paquets ne sortent pas de la machine, cette adresse sert pour la communication entre les applications.
  • 2 - link-local : La portée se limite au réseau local, les paquets ne peuvent pas traverser les routeurs multicast. Cette valeur est utilisée en particulier par le protocole de découverte des voisins.
  • 3 - subnet-local : Ce type n'est pas officiellement défini, mais se retrouve dans certains documents. Il permet de faire la différence entre un lien physique et un lien logique (regroupement de plusieurs liens physiques) partageant le même préfixe IPv6.
  • 4 - admin-local
  • 5 - site-local
  • 8 - organisation-local
  • E - global
  • Les portées 0 et F sont réservées.

http://www.iana.org/assignments/ipv6-multicast-addresses donne les adresses multicast définies. Le tableau ci-dessous liste les plus utilisées :

Adresse multicast usage
FF01::1 All Nodes Address
FF01::2 All Routers Address
FF02::1 All Nodes Address
FF02::2 All Routers Address
FF02::5 OSPFIGP
FF02::6 OSPFIGP Designated Routers
FF02::9 RIP Routers
FF02::1:2 All-dhcp-agents
FF05::2 All Routers Address
FF05::1:3 All-dhcp-servers
FF0X::101 Network Time Protocol (NTP)
Retrieved from "http://livre.g6.asso.fr/index.php?title=AdressageBis-Fondamentaux&oldid=4229"
Personal tools