Difference between revisions of "MOOC:Compagnon Act14"

From Livre IPv6

(Structuration basique du plan d'adressage)
(Adressage multiple des interfaces)
Line 19: Line 19:
  
 
<center>
 
<center>
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20151012-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]
+
[[image:activite-14-adresses-interface-reseau-img06-719x277-v20170517-01.jpg|400px|thumb|center|Figure 2 : Adressage multiple d'une interface de communication.]]
 
</center>
 
</center>
  

Revision as of 07:49, 17 May 2017

Activité 14  : L'utilisation des adresses unicast

Introduction

Lors de l'activité précédente, nous avons vu que les adresses IP unicast sont construites en combinant 2 éléments (voir la figure 1). Le premier élément vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet ou à travers l'interconnexion pour les infrastructures privatives. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise directe du paquet à l'interface de destination sur le dernier saut de l'acheminement. Dans cette activité, nous nous intéressons à la construction de ces adresses unicast. Pour la partie préfixe de réseau, il s'agit de définir un plan d'adressage. Ce plan d'adressage est organisé de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables. L'objectif, dans ce dernier cas, est de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. Dans cette activité, nous allons indiquer les différentes façons de numéroter les réseaux. Pour la partie identifiant d'interface, l'objectif est de définir un identifiant, si possible automatiquement, qui soit unique au sein du lien. Nous allons étudier les différentes techniques de constructions de ces identifiants. Mais avant, nous allons rappeler une caractéristique d'IPv6 dans l'utilisation des adresses unicast, à savoir la possibilité d'avoir plusieurs adresses unicast allouées à une interface de communication. Ces adresses multiples peuvent être utilisées simultanément ou l'une après l'autre. Un mécanisme de vieillissement est donc nécessaire pour limiter la validité d'une adresse.

Figure 1 : Hiérarchisation de l'adresse unicast en deux parties logiques.

Enfin, pour conclure cette introduction, signalons que les conseils donnés par RIPE NCC sont précieux pour toutes personnes amenées à concevoir un plan d'adressage[1]. L'IETF a également édité un recueil de conseils pour le déploiement d'un réseau IPv6 par le RFC 7381.

Adressage multiple des interfaces

En IPv6, les interfaces de communication des noeuds disposent simultanément de plusieurs adresses. En effet, une interface dispose au moins d'une adresse purement locale sur son lien local (l'adresse lien-local). Celle-ci est automatiquement affectée à l'interface lors de la phase d'activation de cette dernière par le système d'exploitation. Selon la nature du lien de rattachement (liaison point à point, domaine de diffusion ethernet filaire ou wifi...), l'interface peut également disposer d'une ou plusieurs adresses routables soit localement (cas des adresses ULA), soit globalement (cas des adresses publiques : GUA). Ces adresses unicast routables sont constituées en associant le préfixe réseau associé au lien à l'identifiant d'interface. L'affectation de ces adresses routables peut être fait soit par l'administrateur système de la machine, soit par le réseau en s'appuyant sur les mécanismes d'auto-configuration "avec" ou "sans état", comme nous le verrons dans une séquence ultérieure. La figure 2 illustre l'adressage multiple d'une interface de communication pour un noeud.

Figure 2 : Adressage multiple d'une interface de communication.

Nous savons, depuis l'activité "qu'est ce qu'une adresse IP ?", que les adresses IP ne sont pas permanentes. L'adresse IP a une durée de vie régie par des états. Ces états sont : provisoire, préféré, déprécié et invalide. Aussi, il faut comprendre qu'une adresse IP n'est allouée que temporairement à une interface. Il faut voir l'allocation comme un bail de location. Pour continuer d'utiliser une adresse IP, à l'expiration du bail, il faut procéder au renouvellement du bail. Ainsi, le système d'exploitation a en charge de renouveler périodiquement l'allocation d'une adresse IP en cours d'utilisation. Autrement, l'adresse passe dans l'état déprécié afin de rendre inutilisable cette adresse pour les nouvelles connexions et permettre de terminer les sessions et les connexions existantes. Il faut alors, dans un même temps, une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives. L'idée que les adresses IP sont allouées temporairement trouve sa motivation de rendre la renumérotation d'un réseau facile. La renumérotation d'un réseau consiste à remplacer un préfixe réseau par un autre. L'opération de renumérotation peut s'avérer nécessaire lorsque l'organisation change de fournisseur d'accès à Internet ou que le plan d'adressage est devenu obsolète. Il n'en reste pas moins que malgré les facilités qu'offrent IPv6, la renumérotation d'un réseau reste une opération périlleuse [RFC 5887].

Nécessité d'organiser un plan d'adressage

L'espace d'adressage IPv6 est « astronomiquement » grand. Il s'ensuit que le plan d'adressage unicast global adopté aujourd'hui est organisé hiérarchiquement. À l'instar du réseau téléphonique historique, où les appels sont routés en fonction d'un préfixe national (exemple le +33 pour les appels vers la France), l'Internet est bâti selon une organisation hiérarchique. Cependant, cette hiérarchie n'est pas d'ordre géographique mais plutôt administrative et organisée en « régions » (Amérique du nord, Asie Pacifique, Europe,...). Chaque région est gérée par un registre Internet régional (Regional Internet Registry ou RIR). Cette organisation se retrouve au moment de l'acheminement des datagrammes dans l'Internet. Les opérateurs du cœur de l'Internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les RIR leur attribuent des préfixes courts, car le rôle de ces opérateurs internationaux est d'acheminer les datagrammes vers les grandes zones régionales de l'Internet. Ces opérateurs délèguent ensuite à leur clients, registres locaux (LIR) ou opérateurs, des préfixes un peu plus longs, afin qu'eux même puissent déléguer des préfixes à leurs clients ou organisations utilisatrices pour acheminer les datagrammes vers leurs propres réseaux. Ainsi un utilisateur final : organisation, entreprise ou particulier se verra déléguer par son fournisseur d'accès Internet (FAI) un préfixe d'une longueur comprise, en général, entre 48 et 64 bits. La zone de l'adresse, comprise entre la longueur du préfixe alloué par l'opérateur et la limite du /64 des adresses unicast est parfois qualifiée de SID (Subnet ID). En effet elle permet à l'administrateur, d'adresser entre un unique réseau (cas où le client à obtenu un préfixe /64 de son FAI) et 65536 réseaux (cas où le client a obtenu délégation administrative, de son fournisseur d'accès, sur un préfixe /48 : il dispose alors de 16 bits (entre 48 et 64) pour numéroter 2 puissance 16 soit 65536 réseaux). C'est cet espace de l'adressage, dont l'administrateur réseau a la responsabilité, qu'il s'agit d'organiser pour déployer efficacement les réseaux de son organisation. Nous allons maintenant présenter différents modes d'organisation possibles en nous appuyant sur le RFC 5375.

Politique d'assignation des adresses

Les spécifications primitives d'assignation des adresses [RFC 3177] aux utilisateurs finaux recommandaient d'allouer :

  • /48 (65536 sous-réseaux) dans le cas général,
  • /64 (un sous-réseau unique) lorsqu'un et un seul réseau physique était nécessaire,
  • /128 (adresse unique) lorsqu'il était absolument connu qu'un et un seul équipement était connecté.

Le RFC 6177, également connu sous BCP157 (Best Current Practice), est venu remettre en cause les certitudes initiales et le « /48 pour tout le monde » n'est plus la recommandation officielle. La taille du préfixe est maintenant laissée à la discrétion du fournisseur avec la recommandation « floue » d'allouer un bloc d'adresses adapté aux besoins de l'utilisateur en évitant l'allocation d'un réseau unique. Ainsi, si un /48 est adapté pour un réseau de campus, il est clairement surdimensionné dans le cadre d'un usage domestique. Inversement, le réseau unique en /64 est notablement insuffisant ; les besoins actuels et futurs de la plupart des foyers nécessiteront sans doute quelques réseaux cloisonnés en fonction des usages : réseau général (accès internet, les réseaux sociaux, le multimédia...), réseau domotique (lave-linge, sèche-linge, réfrigérateur...), réseau de commande périmétrique (volets, alarme, chauffage, aquarium...), sans parler des promesses médiatiques de l'Internet des objets (IoT Internet of Things). Pour les utilisateurs dits « grand public » ou les sites de taille modeste, un préfixe /56 ou /60 semble donc plus approprié.

Préfixes de sous-réseaux (SID Subnet IDentifier)

Les sous-réseaux IPv6 doivent s'aligner sur les préfixes de longueur /64. Des tailles supérieures sont possibles, mais ne sont pas sans poser problème pour les mécanismes de contrôle tels que l'auto-configuration des adresses, couramment utilisée, et qui présupposent des préfixes des sous-réseaux alignés sur 64 bits. Ces mécanismes d'auto-configuration seront abordés dans une séquence ultérieure.

Ces préfixes de 64 bits sont construits à partir du préfixe global permettant le routage des paquets vers le réseau du site regroupant ces sous-réseaux. Le préfixe global est celui utilisé dans les tables de routage de l'opérateur connectant le site à Internet. A ce préfixe global est ajouté la valeur identifiant le sous-réseau à l'intérieur du réseau du site. Cette valeur est définie sur le nombre de bits restant pour définir un préfixe unique de 64 bits. Ce préfixe sera utilisé dans les tables de routage internes au réseau du site. La figure 3 décrit cette hiérarchie de la partie préfixe de l'adresse.

Figure 3 : Hiérarchisation de la partie préfixe.

Représentation des subdivisions

Dans la suite de cette activité, nous raisonnerons sur la base d'un préfixe de 48 bits (espace SID de 16 bits). Les exemples décrits sur la base d'adresses documentaires pourront ainsi illustrer aussi bien un contexte de réseaux publics (un préfixe /48 unicast global) qu'un réseau privatif (préfixe /48 d'adresse locale unique ULA). Cependant, les règles d'ingénierie présentées pourront également se décliner de manière plus limitée sur des préfixes plus longs /56 ou /60 avec un espace SID réduit à 8 ou 4 bits.

Nous supposons que le préfixe pour notre activité est 2001:db8:cafe::/48. Le préfixe est obtenu :

  • soit par allocation de notre fournisseur d'accès dans le cadre d'un adressage unicast global routable sur l'Internet public,
  • soit par algorithme conforme RFC 4193 dans la cadre d'un adressage privatif (ULA Unique unicast Local Address).

Nous disposons donc d'une zone SID de 16 bits permettant de distinguer 65536 sous-réseaux possibles en préfixes de 64 bits (de 2001:db8:cafe::/64 à 2001:db8:cafe:ffff::/64).

Convention de notation binaire du champ SID

Dans cette présentation, nous adoptons les conventions de notation suivantes pour les illustrations et exemples : Comme les 48 premiers bits sont administrativement fixés et que les 64 bits de poids faible sont réservés pour l'identification de l'interface, chaque référence de sous-réseau sera portée par les bits 48 à 63 (L'IETF numérote les bits en démarrant de zéro de la gauche (most significant : poids fort) à la droite (least significant : poids faible).

Exemple :

2001:db8:cafe:{LLLLTTTTBBBBBBBB}::/64
ou
2001:db8:cafe:ltbb::/64

  • Chaque lettre majuscule encadrée par '{' et '}' représente 1 bit du champ SID. 4 bits successifs représentent un quartet également appelé « nibble » ;
    (Un nibble (ou plus rarement nybble) est, en informatique, un agrégat de 4 bits, soit un demi-octet. On trouve aussi les termes francisés semioctet ou quartet , source wikipédia https://fr.wikipedia.org/wiki/Nibble). 1 quartet peut prendre une valeur entre 0 et 15 et peut se représenter par 1 chiffre hexadécimal (0..9, a..f) (cf. vadémécum de notation hexadécimale) ;
  • Les chiffres et lettres minuscules ['a'..'f'] représentent la valeur hexadécimale d'un quartet ;
  • Dans cette présentation, nous subdivisons les 16 bits du SID en groupes distingués de la manière suivante :
    • B : bit non défini et assignable ;
    • L : bit assigné à l'identification de la localisation du sous-réseau ;
    • T : bit assigné à l'identification du type de sous-réseau.

Ainsi, l'exemple précédent où les 16 bits SID sont positionnés à la valeur {LLLTTTTBBBBBBBB} produira des préfixes IPv6 du type 2001:db8:ltbb::/64. Inversement, si l'on choisit de positionner les bits de "type de sous-réseau" sur le quartet de poids fort et les bits de localisation sur le quartet de poids faible du 1er octet SID de cette manière {TTTTLLLLBBBBBBBB}, cela produira un préfixe de type 2001:db8:tlbb::/64.

Différentes stratégies d'allocation des valeurs de SID sont présentées en annexe. Un administrateur peut les mettre en pratique pour définir un plan d'adressage pour son réseau.

Cas particulier des liaisons point à point

Les liaisons point à point, qu'elles soient concrètement louées auprès du service idoine d'un opérateur (liaison spécialisée, fibre noire...) pour assurer l'interconnexion de deux sites géographiquement distants, ou qu'elles soient logiquement établies sous forme de tunnels (Ip dans IP, VPN MPLS, tunnel IPSec…) constituent un cas particulier. Dans le cas général, on peut allouer un préfixe /64 à chacune des liaisons. Cependant, sur des réseaux maillés où le nombre de liaisons point à point est quelconque, attribuer un /64 à chacune de ces liaisons n'est pas efficace. La caractéristique d'une liaison point à point est de relier uniquement une interface à chacune de ses extrémités, ne nécessitant, de fait, que deux identifiants distincts. De plus, ces liaisons sont administrées et ne sont, en général, pas tributaires d'un mécanisme d'auto-configuration. Aussi, attribuer un /64 offrant la possibilité d'adresser 2 puissance 64 interfaces à un support limité à deux, et uniquement deux interfaces, conduit à la perte de ((2 puissance 64) - 2) adresses qui resteront non attribuées. L'utilisation d'un /64 sur une liaison point à point peut conduire à des problèmes de sécurité (RFC 6164): soit sous la forme d'aller-retours de datagrammes sur cette liaison (syndrome de la balle de ping-pong) entraînant une congestion du support, ou soit sous la forme de déni de service des routeurs connectés au lien au travers d'une saturation des caches de découverte des voisins. A défaut d'un /64, quel est le préfixe approprié pour ce type de liaison ?

  • /127 serait possible dans la mesure où IPv6 n'a pas d'adresse de diffusion (identifiant de host tout à 1 dans le cas d'IPv4). Cependant, l'adresse tout à zéro de chaque sous-réseau est réservée comme l'adresse anycast des routeurs (« all routers anycast address »), ce qui signifie que le plupart des routeurs sont susceptibles de recevoir des datagrammes de service sur cette adresse.
  • /126 évite le problème de l'adresse anycast tout à zéro. Cependant, les 128 adresses hautes de chaque sous-réseau sont également réservées pour diverses adresses de anycast (RFC 2526) ; bien que, dans la pratique, cela ne semble pas poser de problème.
  • /120 permet de s'affranchir des adresses anycast réservées.
  • /112 permet de s'affranchir des adresses anycast réservées et a, en plus, l'avantage d'être facilement lisible par les opérateurs humains car aligné sur le mot de 16 bits final (celui affiché après le dernier séparateur :, cf activité 12 « Notation d'une adresse IPv6 »).

Le RFC 6164 recommande l'utilisation d'un préfixe de longueur /127 pour IPv6, ne permettant ainsi que deux adresses IP.

Identification locale : l'IID (Interface IDentifier)

Les identifiants d'interfaces des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous-réseau. Toutefois, l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas, l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte Ethernet par exemple).

Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (loopback) (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.

Si, initialement, pour des raisons d'auto-configuration, l'identifiant d'interface devait nécessairement être dérivé de l'adresse de niveau 2 (adresse matérielle), c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits [RFC 4941] :

Identifiant manuel

Pour les serveurs les plus utilisés, 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.

Nota : Le résolveur DNS est le cas le plus emblématique. Chaque machine sur le réseau doit être configurée avec son client DNS pointant vers l'adresse du serveur DNS. Si celui-ci a un identifiant d'interface basé sur l'adresse de niveau 2, en cas de changement de la carte réseau sur le serveur DNS, l'ensemble des machines du domaine devraient être reconfigurées. Si l'on ne souhaite pas utiliser de protocole de configuration automatique tel DHCPv6, il est préférable d'attribuer au serveur DNS une valeur manuelle d'identifiant d'interface. Cette valeur statique sera stable dans le temps et pourra être utilisée pour référencer le résolveur DNS sur la configuration de l'ensemble des machines du réseau.

Il existe plusieurs techniques plus ou moins mnémotechniques :

  • Incrémenter l'identifiant d'interface à chaque nouveau serveur créé.

2001:db8:1234:1::1
2001:db8:1234:1::2

  • Reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple, si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 pourra être :

2001:db8:1234:1::7B

ou plus simplement

2001:db8:1234:1::123

  • Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir :

2001:db8:1234:1::192.0.2.123

Identifiant dérivé de l'adresse matérielle 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 en général construites en utilisant ce type d'identifiant. Par contre, pour les adresses globales, il est conseillé de ne les utiliser que pour les machines clientes et de préférer les identifiants d'interfaces manuels pour les serveurs.

Ces identifiants d'interfaces étant stables 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. Ce dernier pourrait donc servir à tracer les déplacements d'un individu[2]. Ce sujet de traçabilité et de respect de la vie privée a fait l'objet d'une prise de conscience collective suite à une actualité récente (affaire Snowden, surveillance de masse par les états, écoute de la NSA...). Mais, la traçabilité par l'identifiant d'interface n'en est qu'un des éléments car les cookies mis en place par les serveurs web ou les recoupements des infos personnelles déposées sur les réseau sociaux 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'extérieur du réseau quel type de matériel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

Identificateur EUI-64

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.

Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure montrée par la figure 7. Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802.3, identifient le constructeur. Les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits, u (septième bit du premier octet), et g (huitième bit du premier octet) ont une signification spéciale :

    • u (Universel) vaut 0 si l'identifiant EUI-64 est universel ;
    • g (Groupe) indique si l'adresse est individuelle (g = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (g = 1), par exemple une adresse de multicast.
Figure 7 : Format de l'identificateur IEEE EUI-64.

Dans le cas d'IPv6, l'identifiant d'interface à 64 bits peut être dérivé de l'EUI-64 en inversant le bit u comme le montre la figure 8. En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.

Figure 8 : Identifiant d'interface dérivé du format EUI-64.
Identificateur MAC-48

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 par l'insertion de 16 bits à la valeur 0xfffe, puis le bit u est mis à 1 comme dans le cas précédent. La figure 9 illustre ce processus.

Figure 9 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).
Cas Particuliers

Si une interface ne possède aucune adresse, par exemple l'interface utilisée pour les liaisons PPP (Point to Point Protocol), 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. 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.

Opacité des identifiants d'interface

Les bits u et g n'ont de signification que pour les adresses de niveau MAC (adresse EUI-64 et EUI-48). Si, aux origines d'IPv6 (RFC 4291), le bit u conservait cette signification d'universalité, c'est qu'à l'époque l'identifiant d'interface dérivait majoritairement de l'adresse matérielle. C'est moins le cas aujourd'hui avec les IID temporaires aléatoires, voire cryptographiques (cf. paragraphes suivant). L'IETF a remis les choses au clair dans le RFC 7136 en précisant maintenant que "les identifiants d'interface doivent être considérés comme opaques et il ne faut pas tirer de conclusion de la valeur de tel ou tel bit". La dérivation d'un IID à partir d'une adresse matérielle reste inchangée mais, inversement, si on ne sait pas comment a été généré l'IID, on ne peut rien déduire de la signification des deux bits de poids faible de l'octet de poids fort de l'IID. N'attachez donc pas plus d'importance à ces bits qu'ils n'en n'ont réellement aujourd'hui.

Valeur temporaire 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 mobile utilisant un portable, chez lui, au bureau, lors de ses déplacements.

Pour couper court à toutes les menaces de boycott d'un protocole qui «menacerait la vie privée », l'IETF a validé d'autres méthodes de construction d'un identifiant d'interface comme celle reposant sur des tirages aléatoires [RFC 4941]. Un utilisateur particulièrement méfiant pourrait activer ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme de hachage, 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 globales comme on le voit dans la figure 10. 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 ou à chaque redémarrage de la machine et sert aux applications clientes. Dans Windows 7, 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. Elle est également présente, mais de manière optionnelle, sur les systèmes d'exploitation Linux, BSD et Mac OS.

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, et 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.

Figure 10 : Adresse IPv6 temporaire de MS-Windows.

Valeur stable opaque

L'identifiant d'interface dérivé de l'adresse matérielle pose le problème de la tracabilité des équipements nomades et de respect de la vie privée qui en découle. Cependant la il dipose de la propriété de stabilité (on éteint la machine et on la rallume, on est sûr de retrouver la même adresse IPv6) qui simplifie les tâches administatives (Ainsi, lorsqu'on regarde le journal des connexions, on peut facilement retrouver la machine qu'on a repéré. Et créer des ACL est simple, puisque les adresses ne changent pas). Le RFC 7217 propose une méthode de génération de l'IID opaque, ne révélant pas d'information relativement à la configuration matérielle, mais stable dans le temps. Le principe est de condenser (à l'aide d'une fonction de hachage telle que SHA-256 par exemple et de ne conserver que les 64 bits de poids faible) un secret (stocké dans une mémoire non volatile), un certain nombre de caractéristiques de la machine et le préfixe, de manière à avoir des identifiants stables, mais préservant quand même partiellement la vie privée de postes nomades : l'identifiant d'interface change quand la machine change de réseau, ne permettant plus de la suivre à la trace. Mais, si on reste sur le même réseau, l'adresse est stable. Le RFC 8064 a confirmé la pré-éminence de cette méthode sur la méthode dérivée de l'adresse MAC pour la procédure d'autoconfiguration sans état (qui sera décrite dans la séquence 3).

L'idée est que la machine aurait une (ou plusieurs) adresses temporaires, une (ou plusieurs) adresses stables et qu'on utiliserait l'adresse temporaire pour les connexions sortantes, et l'autre pour les entrantes. Cela fournit une bonne protection, question vie privée, mais au prix de quelques inconvénients. Comme rien n'est gratuit en ce bas monde, ces adresses compliquent la vie de l'administrateur réseaux : interpréter le trafic qu'on voit passer est moins simple (beaucoup de techniques de protection de la vie privée ont ce défaut).

Cryptographique

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.

Conclusion

Une interface de communication en IPv6 peut avoir plusieurs adresses unicast. Les adresses IP sont allouées temporairement. On parle alors d'une durée de vie d'une adresse qui est fait sa durée d'allocation. L'intérêt est de rendre la renumérotation c'est à dire le changement d'adresse rapide et automatique.

L'adresse unicast IPv6 est découpée en 2 parties. Une partie va servir à l'identification mais aussi à la localisation du réseau au sein de l'Internet. On parle de préfixe réseau. Nous avons étudié comment définir et organiser un plan d'adressage de manière hiérarchique afin de permettre la délégation pour une gestion décentralisée mais aussi rendre les préfixes agrégables, afin de constituer des tables de routage les plus concises possibles. Pour IPv6, vu la taille de l'espace d'adressage, cette caractéristique d'agrégation est essentielle. La seconde partie de l'adresse sert à identifier une interface au sein d'un lien. Nous avons présenté les différents modes de construction des identifiants d'interfaces.

Références bibliographiques

  1. RIPE NCC (2013), publiée sous licence CC-BY par Surfnet (www.surfnet.nl) Preparing an IPv6 address plan
  2. Internet society. (2014) Deploy 360 programm IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

Annexe : Différentes stratégies pour la définition des sous-réseaux (SID)

Lorsque qu'un administrateur a la tâche de déployer IPv6 sur son réseau, une des étapes importantes est la définition du plan d'adressage. Ce plan définit l'ensemble des adresses utilisées sur chacun des réseaux du site concerné. En IPv6, chaque réseau se voit attribuer un préfixe nécessairement de largeur 64 bits (/64). L'administrateur connaissant le préfixe assigné à son site, communément de largeur 48 bits, il lui reste à définir les 16 bits restants pour identifier chacun de ces réseaux. Cette valeur est appelé identifiant de sous-réseau ou SID.

Réseau à plat

Les petites entités sans structure organisationnelle bien définie peuvent éventuellement fonctionner sans plan d'adressage structuré. Cependant si l'infrastructure de niveau liaison est cloisonnée en domaines de diffusion distincts (VLAN), il faudra à minima, affecter 1 identifiant de sous-réseau par domaine. L'attribution de ces identifiants de sous-réseaux pourra être simple, en numérotant éventuellement séquentiellement.
En l'absence de structuration du plan d'adressage, ce type de réseau ne passe pas à l'échelle. Si le nombre de sous-réseaux est amené à croître, l'administration et le contrôle de l'infrastructure deviennent rapidement problématiques. Il y a, également, nécessité de conserver dans une table les différents affectations pour localiser le segment réseau ou la machine à l'origine d'un problème ou d'un dysfonctionnement, puisque les adresses sont peu signifiantes.

Correspondance directe entre les identifiants IPv4 et IPv6

Pour les organisations ayant déjà structuré une infrastructure réseau sous le protocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versions du protocole, il est possible d'adopter une stratégie de correspondance des identifiants de sous-réseau IPv4 et de sous-réseau IPv6. Deux cas peuvent être évalués :

Correspondance directe entre les sous-réseaux IPv4 et IPv6

Si les réseaux IPv4 sont structurés uniquement en sous-réseaux de préfixe /24 (exemple les réseaux privatifs du RFC 1918, un réseau de classe C 192.168.0.0/24 à 192.168.255.0/24 ou que l'on a « subnetté » en /24 le réseau de classe A 10.0.0.0 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.0), une correspondance directe entre l'identifiant de sous-réseau IPv4 peut être eg/html/rfc7136">RFC 7136 S6 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.
172.16.0.0
à 172.31.0.
172.16tml/rfc196.0.0
être egxternal text" href="http://www.bor s'il"http://wwws S (VLl0.<60/b Autoconfiguration .bor s.ésol1 headline" icaption">ehttp://tools.ietf.org/html/rfc1918">RFC 1918, un réseau de classefc191rg/ho teml/rfc:uFC 5887ts (VLAN), il fau0ass="exteu(SID)s, inver-déf0assussiui, au in n'ont réellement e l'adresse de bouc)rmadesillance-and-tracking/"près le der id4es28ge">

Fellhôsesfollow" href5.14s28rs de l'initiw" href5.18s28rs de une ai unhttp://www.bortzmeesse rà plat
Fellhôsesfollowexteés 0s23rs de l'initiwexte9.5s23rs de une ert auxar ces i une il.C3.A98.0.0/24

t comstp://www.bortzmeesse ri une inhamp«hexa>t comls-rét déjà structue, dene" idant sousaiants IPv4 et IPv6 lses (CGement e apes important ne se,s, une léaevc" rer 1 i'adrmlat (qui e préfixe réseauhttp://www.bortzmeess6rmades ee is8.0.0/24t comls(0r 0 0r 0 0r10 0r11)otocole IPv4, et sur laquelle on souhaite faire cohabiter les deux versioructure il est possible d'adopter une stratégie de corrce est choisentifiants de sous-réseau IPvès le dernies8.0.0/24192.168.255.0/24esse uc les liaisoants IPv4 et IPvnts stablenféaquew-headltotar les adr comme adresse choisi xée dans le DNS. La seconde possèdeuctuntift que ra déficonéréset d'adrrét déjà struct4li> Incrémenteheadline" id=omme adresse t structuré1t234rs de ifiee de e" id="mme as un de la mnitibr />

Figure orrce est chois6féaquew-heiliation. orr32rer de conclusion de la valpossèdeuctun( surtion dbal) vauti xée dans le DNS. La se)Pv6">Corr>uuration d au ri est fmat mCepen>Une int>t comlee IPv6i. Unt d'adrcations e privattrdéogsn alemes. c0a801eautilisanreee c6, l'idehexa>t comlauhttp32rer de co comme adresse xternal t structuré1t234rs de epen>Une int>t comlee IPv6i. ,usaiants IPv4 et IPv6 lses (CGtant v>
ier pourla fouous rg/htproblématiques. Il y a, également, nécn cl a co(SID)Pt appelé identifiant de sment de largeur 4lyseAnnexe&#tique.

L'adrel mw gésuomaine de la4ype de car>t cod de gent ln numérotaux interf0;: Identifiantal mw-mag orrce est chvattvalués men'un dysfonli> pourraieow" class="exastructure r.255.0/24ne conppuy au bure), il fau0a'addresses (CGvait ceu'one conlltituer des t maS de réseauue. udié commennier octet de l'adress0 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.0), une correspondance directe entre l'identifiant de sous3réseau IPv4 peut être eg/html/rfc7136">RFC 7136 êt3fetf.org/(CGA)nNe souu.0.0<3tt> ou l'un des 16 classe B 172.16.0.0 à 172.31.0.
êt3fetf.172.31.0.
172.16tm êt3fetfxternal text" href="http://www.bor s'il"http://wwws S (VLl0.<60/b Autoconfiguration .bor s.ésol13headline" icaption">ehttp://tools.ietf.org/html/rfc1918"4r l'idenPt appelé identifiant de sme />

faible?s de sous-réseade cotanés, nelle, ses adrestifiant>t cod de gent ne passe pene coCorresptituer s.llass=rfaible) uit sa durée>
ludra(tp>Le qu'odlinec/DMZ, émeoyanc,le chanu sin pr rests.switchts.fusion s,nscience , ts de sous-rée plapaleur sta,n'ondu

Rprécisant faible) ludrace n'nal ait sa duréde une adres5e MAC IEEE 8Noeesa foénération aléatoire avec le bit u">Lit sa durée> valeur), il serQre non ves de diffusiose
Dtes, mdnffusiun plan d'adre déployere aur"exteu(SID)Le qusimple, en numérotas uestas VPNlp Incrément class="extaue nom de c©seau par IPv6, tie qui clasoce quuola les liplapaee rsnnxe ssréspar a macheCelayepest medentifiaoln problèmIPv6, tie qui clasoce q, c'est mdn de surut la IPv6 r cesimméanutsignificerveuer lesu isé c eceq-64 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.0), une correspondance directe entre l'identifiant de sous3réseau IPv4 peut être eg/html/rfc7136">RFC 7136 êt3fetf.org/(CGA)nNe souu.0.0<3tt> ou l'un des 16 classe B 172.16.0.0 à 172.31.0.
êt3fetf.172.31.0.
172.16tm êt3fetfxternal text" href="http://www.bor s'il"http://wwws S (VLl0.<60/b Autoconfiguration .bor s.ésol13headline" icaption">ehttp://tools.ietf.org/html/rfc1918"6r l'idenPt appelé identifiant de sss="thumbcaption">
, un1r l'idenespondance desfort Nosuomainuit sa durég04-850x380-v2acking/"seau par ait sa durésr l'iden3 class="ext ackb16.#1DNS. Lre d'autor(jà strrelns leswitchtheCevusion s)> totar> =>e3eau, uoaffdémaruola ier plr t d'ait sa durés, /rfc7136"fiavnneminterf0;: Idenlementait alorsinteconde p. Il identitt>10.0.0.itibr /> , un2r l'idenespondance desfort Nosuomaeéudra 'udentg04-850x380-v2acking/"seau par ;: totar> =>e4eau, uoaffdémaruola ier plr t d'ludrsn respondance de,un des2réseaux du site cvnneminterf0;: Idenllementait alorsinteconde p. Il identitt>10.0.0.itibr /> HPv6 est d duréedes2 class=xg04-850x380-v201Dcations est d'a>, uls.ietf.org/hts.ies éseaux du sitecstructure r0;: Idenllementndant sint un r une class=" respondance de sous-a h2>

Une intpr72.yereine"fort t s pourraiesans plan d'adrcstructure r"mme as ur la dé gésite sous-a h2>

Une intpr72.yereine"ettéudra 'udent,r la ges pourraieseau dxplusdéet clded'"eettd'uneclesu p://tool> sondu

href. L ou est ludrsn res de diffusi,iuit sa durée/éudra 'udent,rer chacun é car l'ssoanm2.3er sousinteartirit l'er s.llass=rtil ait lique deen numéropr72.yerillance-and-tr>10.0.0.itibr /> l'er s.llass=rtil ait sa duré> aujnt d'ints lesasinteconde pmanente eer de conclusiol bit64 bi,fdant sorau.t'adrmreysfonut pae préfixe réseauhtsimple, en numérotDNS. Lre d'autore asitesrdes routeurent lemenirau. No'o s, questiolow" hrs lique deipe dplns leies fne s'/,>
p://tools.ielow" hrs lique(oressnll)oine" etion mais I-64,ent OS. < ma arotisui,ettp://top://tools.ielow" hrs lique(oressnll)o la dé gésite, sera în au in ns aienpe enlldecohconde pmdadline" ir IPv6 s n'o s, questiolow" hrt so Irécisant maer s.llass=rtieéudra 'udentisernal ait sa durédentitt>10.0.0.itibr /> La On dtg04-850x380-v201Dcatio, il fau0.ietf.org/hteseau, uocole0;: Idenllementt d'ludrs ar domaine. L'attrte3external ait sa duré,usat la d9es adre Mac 5s2 (2urut la IP9) sans plan d'adre comme"ettéudraee"ettsite sest ines daffda'adrcatiosurlueaseie acasrdes routeur72.1inoncta 'il fiser u2048 uestas VPNlp Inseaufiantaccueploiocédure d'autoc low" hrs poure arersrestade poids e rendfiee de mi55.0/ dede mod fs=rties iser splusdémpsn res de diffusitpr72.yereit r une oyer, ussi nt fme structetml/rfc80ree configuratio Les coe e l'addresses (C On pa état'adress (cf.isées rnteaseiocéduuestas sern4 ludrsn à platsr="172.16wikige, cealion"> IP etioeou l'un d30%"> Tudrrobth Udentg0b>robth obt887ttr0), ack;: 0 obtd Backb16.,'Ile, en numérg0b>robtd obt887ttr 1 obtd Science g0b>robtd obt887ttr0
), ack;: ), ack;: 4 obtd Persrestadg0b>robtd obt887ttr 5 obtd Échanu sig0b>robtd obt887ttr0
), ack;: 6 obtd Ir restg0b>robtd obt887ttr ), ack;: 8 obtd VPNg0b>robtd obt887ttr 9 obtd VPNg0b>robtd obt887ttr0), ack;: a obtd VPNg0b>robtd obt887ttr b obtd VPNg0b>robtd obt887ttr0), ack;: ), ack;: Lque,t s sment de la5geur 4lyseisui,rnaprn d'adres de vie d'une daffda à cIP.iet, nellenot lecasplusdémp4 bicela 1un e" iert auat la d9es ad 'B'esse uiet, 6">Corrduence 3t comlrmades enellenot letrémente de mass,ndclasse C 192.1ainuit sa duréesern4 au, us="mwe=" r3urent ines 55.es réseauxant la il xée dan dess="exteop retrncet ne se la ges.1ainueumérotas , et que sLes d'a>, ulstant v>d://illance-and-tr>10.0.0.itibr /> 10.0.0.itibr /; Mac, epen>Une int/h.16e af,otas , et quenv>10.0.0.itibr /> weyzan/64rs deumbcaptiotr>10.0.0.itibr /> xwyzan/64rs deumbcaptiotrp>tt> ouuen"nibomme" wes d'exploitation aarit sa duréeet xes d'e machine etsans plan d'énération aléatoire avec le bit usion 6 ,t s sment de la5geur ous-réseau par ait sa durésprnaar udrsnar domaine. L'attiant manueommurioriure dtion.mofinit l'e'es, soisse d'adrristincts (VLAN), i6">CorrrnterpaonéstioIuru plan dn nfeonxicastinfl'aubqui serace type de réseau;: Correspondance directe entre l219sous-r219 textet <53with IP<53w texouLsudu, postion déc n'ontapr lehtitp://://tourationntaila IPvcatiosu"enipulysfonut paer de olasture r"cqut t, nelleosu"esr lesu ln nfeonxicastintes zo.A0_ps de vie d'une rcstructure r"ion deueommmpvst er eceq-64ratdomaine. L'attsplan d'everxuer de conclusiol b,osuomaeéudra plan d'aon. e" inaptiméanu pré-édistincts (VLAN),ifl'aubqu tion_ car l'du,ç72 5'ait sa durés, 3 udrsnns 2 sans plan d'adrienait sa duré/udrillance-and-tr>10.0.0.itibr /> ifiee de epvst eri>elentie scénario hypothcos, qusoait ce,ffectt>192.12domm10nespondance detme structt>194 au, uBidentitt>10.0.0.itibr /> Ar di nt ,e c©seau par udrsn 'udentNoufiee de trantesomm5,tme structt>19édtrrtir'admiau, Tidentitt>10.0.0.itibr /> Puixe, pourommilianxe ssré gée l'adress,e c©seau par sites trante de emm50>Figrtérin 6e c©seau sn r e" iLidentitt>10.0.0.itibr /> Si, enr pou,e c©seau par udrsn 'udentNouecttde emm13,e mass,nde de lusdémp4udraeas9édquatrr'admiau, ddreisernal drrtouroùafacilis stiques er de isuincommendentitt>10.0.0.itibr /> N>Unn1r l'ideteiscti>L oudémpsn colel de aonisse d'ads'ene paelentxteordints cla il xnrectees ographique">Cryptographique

Si un identifiant aléatoire permet de rendre beauc53with IP<53w texeexterna0.ietf êtml leies inteconde p. Il déc rrtila IPgauehti(te eer de{B}lnellenot letrémen)," etion ti(te eer de{T}enellenot letrémen)I-64,drrtour(te eer de{L}enellenot letrémen).teisnier octieN>Unn2r l'ideteiscti>Cn'ont les identpndeant êtplapaeete eeesa fopaceion 6 ,t s sarticureav sont S aieni car l'du,atio, ceat> ou objdivrf1es dque,t s sr.ietfonda'adli>">Ide vie d'unee>ratdomaine. L'attctsr di orrpan>ment de largeu IPv4, et sur laquelle on souhaite nfi-mignideratu_.C3.A0_de_t">Résea_de_class=_2_:orsiopan>">e nfi-migni in ns_.C3.A0_plat">Réseau n class="2faible) uellpan>ment de laréseaEthing/mad.C3.p>

Réseautilisehtrucneurat d'adressemd'"epan>e voit als de diffusioinepan>60;: interpnet. On parle d;: l.C3.A9ite_nodrlat">Réseae vé gépan>6Ething/ma>isui,rnaprsse C 19eaucro(pan>-ID)rmrélass="jà strnclass="31es de 'i.p>

Lorspan>6n administés sanprnence de cette ent fonctionner sans plan d'ad à plat<-c/a>

Fht'adret d'ait sa xtsiei unhttppan>6 à platolasne trantes//top://tools.ie résea naptiww.bortzmeyvusion )ufiantfiav liplamrticulrénératiIPv4, et sur laquelle on souhaitMét_en_ants IPv4 et I_pan>-IDt poSID">Mét êtplts IPv4 et IPpan>-IDu/maSIDment de larésean pa étatapr lehti àes de diffusion distincts (VLAN),,osuoml faudra mple, en numér Ceorrduee à l n'sont faites à yant déjà structueyer.o dMAC),t faites à uus_.C3.A_plat">Réseau(pan>-ID)rLorrne fonction ddépan>6Ething/ma(pan>-ID)q-646 à plat isui,éspar 1un e" is d'exploitationn>s ://www.bortzmeess6,le. Cepenmi55.0/ dedendance_diïncod depan>-IDu/maSIDe Mac es. t comla,e Mac es. t comlaénératacking/">b>F 2xrghexa>t comlafaible) êtplréctt la déasttribue>t comlauht'sont faites à yapan>6edehexa>t comlaus d'e macils n'800xée dans le yant déjà str de trrtirquase tse(nibomm). Delleorg/htmlfacilis édquares plusdémp4 biclibr C-64pan>-IDuanente eer de conclusiol bit64 bi .itibr /> 10.0.0trp>ounératmbcaptiotr>10.0.0trp>pan>-IDuanente eer de conclusion de la64 bi .itibr /> s-réseaus.si orrce est chois6 par enen>Une inthexa>t comlau(cf. aor s.enl12),g orrne fonction d yapan>6 par enen>Une int>t comla,eceq-64b>F 2xrg>t comlarml'Internet. plan aisoants IPv4 et IPlque, dau de classe C 192.168.0.0/24 untifsont faites à yapan>,le. Cepennet. plan asttribue>t comlauhuepan>-IDu/mal'0;: Idnrllrt par un sen"mwe="ee"el seconde que l'on a «hexa>t comlrLaiants IPv4 et IPnt m basélrt par un slque, dntmades ee is8.0.0/24 64321e renremaquenes 'infrastent fonctionner sans plan d'adicerveuer udomm4095u. (2i//too nune oes_pour_ aisoence de cettfrat s'/1hexa>t comlase(a..f)laiden isuincommelementait alorssans plan d'ad2/g, queeemenait Noommilepan>e10.0.0 sr="172.16wikige, cealion"> IP etioeou l'un d90%"> pan>-IDrobth la mvsti-idtd 2xrg>t comlarobth la mvsti-idtd 2xrghexa>t comlaus lusion de robth la mvsti-idtd 2xrghexa>t comlaus lusio_pog0b>robth obt887ttr0ls po l'un des0), ack;: 1 obtd 1an/64rs de obtd 001an/64rs de obtd 0010an/64rs dentd obt887ttr0ls po l'un des 12 obtd 12an/64rs de obtd 00can/64rs de obtd 00c0an/64rs dentd obt887ttr0ls po l'un des0), ack;: 2783 obtd 2783an/64rs de obtd adfan/64rs de obtd adf0an/64rs dentd obt887ttr0ls po l'un des 4094 obtd 4094an/64rs de obtd téan/64rs de obtd té0an/64rs dentd obt88obte, class="magnifyp>Cn'ontapr lehtinapondul/rfc80urationntcohconde pmu de clas.

Une inthttp://www.bortzmeess6 relleosu"esr lesùailiaeeu c©2> ites elle. Siseau pacedans lsrecations e préfixe résea o72 'adrmref="http'o s, questioIurra êtreaaccèsofort tNosuomlr ne sentie ar du résénératiIPv4, et sur laquelle on souhaitIde vie d'unederatpan>_>elen5Ide vie d'unee>ratpan>6n lentifiuit sa duréernaaeéudra 'udentg04-850x38réseaI">Correspondance mi55.0/ deueur pentie apan>-IDuPv6i.gr n'nal ait sa duréernaaeéudra 'udent. Delleorg/hti6">CorrCorrespe, ceixenet. plan ai>Figure{W}n tcoplr v> Rprécisant ré cl.C3.e planmireste suhPv6 est d duréedess titclass=xuvufieportance à c)h3>

Les nartirrideuer s.llass=rtsMac al ait sa duréernaaeéudraentie jnt d'ints lesnente eer de conclusiol bénératacking/">b>F 2xrghexa>t comla. Delleor'ontd 2xr,r de mme biclongpar 1un e" ule. n du pla 4 au, uégiestommelementr plr 1unclatancrsn rdéepan>-IDuanente eer de conclusiol bit64 bi ier ocait sa durée{W}nsern4 au, u(1 quase t)ufr s.llasstae ier octitibr /> -IDuanente eer de conclusiol bit64 bi ier ocait sa durée{W}nsern>Figure(2rquase ts)ufr s.llasstae ier octitibr /> -IDuanente eer de conclusiol bit64 bi ier ocudra 'udenti{V}nsern4 au, u(1 quase t)ufr s.llassta ier octitibr /> -IDuanente eer de conclusiol bit64 bi ier ocudra 'udenti{V}nsern>Figure(2rquase ts)ufr s.llassta ier octitibr /> t comlau (uit sa duréesern1 quase t,éudra 'udentisern2rquase ts)dentitt>10.0.0 sr="172.16wikige, cealion"> IP etioeou l'un d90%"> pan>-IDrobth uit sa durég0b>robth Tudra 'udentg0b>robth uctueypan>-IDuhexa>t coml)g0b>robth obt887ttr0ls po l'un des ), ack;: 0 /)obtd 01)obtd 0010an/64rs dentd obt887ttr0ls po l'un des 21/)obtd 11)obtd 2110an/64rs denpentd obt887ttr0ls po l'un des0), ack;: fé)obtd fe)obtd té0an/64rs denpentd obt88obte, class="magnifyacking/">b>F 2xrg>t comlarLl aque,t s sre réseait m basén du pld'evussi ée Fht'adrnalrrtirquase tseementr plr 10, 100I-64,1r 0 ait sa durés, at> ov> 61025,iuit sa durée(1)éudra 'udenti(025) nier occasplustinuit sa duréesern1 quase tn téudra 'udentisern3rquase ts ier ocou ier ocpan>61025,iuit sa durée(10)éudra 'udenti(25)nier occasplustinuit sa duréesern2rquase tsn téudra 'udentisern2rquase ts ier ocou ier ocpan>61025,iuit sa durée(102)éudra 'udenti(5) nier occasplustinuit sa duréesern3rquase tsn téudra 'udentisern1 quase t ier ocseauass="magnifyp>Quel quesd'a>, uls MAC IEd="Correauapg 2xrg>t comlau(uit sa duréesern2rquase ts,éudra 'udentisern2rquase ts)ndentitt>10.0.0 sr="172.16wikige, cealion"> IP etioeou l'un d90%"> pan>-IDrobth uit sa durég0b>robth Tudra 'udentg0b>robth uctuypan>-IDug 2xrg>t comla)g0b>robth obt887ttr0ls po l'un des0), ack;: 0001an/64rs dentd obt887ttr0ls po l'un des 0529an/64rs dentd obt887ttr0ls po l'un des0), ack;: 4094an/64rs dentd obt88obte, class="magnif

Lorscampl.27bâtirôle entease est ,>Corr>s de sous-rmple, pxée dan dee deun a reeconde pe est changée t'adrmref="httpe préfixe résea. Àan clatar#160men'un dysfonut paop retrnce , ert aux avalués l.C3.Adl'idnffusioseeonx de perd'"el n'y articulirreferecations e préfixe résea. C faudra àes de diffusion distincts (VLAN),ie c6i inverxu d'un dysfoncta claidenti.ie poure simple, en numéro Les coe DNS. Lre d'auto,st que l'unicit paop retrnce ective slui resteti.ie poure avaluésDNS. Lre d'autore agre n ou d'un dysfoncénération aléatoire avec le bit u">Tudra 'udenti>g04-850x380-v201510aeéudra 'udentie avalués&#e aucu/div>
les in n'o s, questiolow" hrt souLsurlueaseie amporaire de Mdiolow" hrt s (ease-fege asa tlus concira êt i aaccès, Iurra être st>u
sfonc…)laiden per
elenties udrsn 'udentNous tôtw gésuomainuit sa durée>ratégiestrnce . L ou d'un dysfonctpartirélé plan définit l'er s.llass=rties udrsn 'udentNosuomainuit sa duréeementa d'ierface prellement.L'e. les in n'o s, questioIurra êtreaaccèsons ayanow" hreduré> fort tNosuomin nsa tlus co ne s'/12/g, que,stable et peute d'adresllas dées s amporaire de Mnt le coIdenlldeéudraease-feg,ousesenllfeonxute d'addes indans le d'allocat On pare, pIurra êests.ies flsse par enr pourion ded'"el n addresel np://tools.ieribueait sa durédctet de l'adress0 ou l'un des 16 classe B 172.16.0.0 à 172.31.0.0), une correspondance directe entre l'identifiant de sous4réseau IPv4 peut être eg/html/rfc7136">RFC 7136 êt4fetf.org/(CGA)nNe souu.0.0<4tt> ou l'un des 16 classe B 172.16.0.0 à 172.31.0.
êt4fetf.172.31.0.
172.16tmr / B 3/34c196.0.0
êt4fetf.s/thumb/0/00/Acte, l'a4ministernal text" href="http://www.bor s'il"http://wwws S (VLl0.<60/b Autoconfiguration .bor s.ésol14headline" icaption">ehttp://tools.ietf.org/html/rfc1918"5erface-reseau-entifiant de s