Revision as of 08:56, 4 March 2006

Adresses Lien-local

Table des matières

Site-local

Les types d'adresses global ou lien-local utilisent un identifiant sur 64 bits pour désigner une interface connectée sur un lien. Si cette longueur n'est pas directement imposée par la norme d'adressage d'IPv6 RFC 3513, elle bénéficie d'un fort consensus car elle permet de garantir facilement une unicité sur le lien et par conséquent de faciliter l'auto-configuration des équipements.

Plusieurs techniques ont été élaborées à l'IETF. La plus répandue est basée sur l'utilisation d'une valeur unique par construction comme l'adresse MAC de la machine. Mais l'on peut également choisir une valeur aléatoire pour garantir plus de confidentialité ou au contraire la dériver d'une clé publique pour mieux authentifier l'émétteur du message. La taille de 64 bits permet de réduire à une valeur proche de zéro la probabilité de conflits. Enfin dans certains cas l'affectation manuelle de cette valeur peut se justifier.

Les chapitres suivants décrivent ces différentes méthodes ainsi que leur intérêts et leur défauts.

Différents types d'identifiant d'interface

EUI-64

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 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 :

Figure 3-8 identificateur global IEEE EUI-64

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

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 g, puis le bit u puis les bits suivants sont transmis.

Figure 3-9 Identificateur d'interface dérivé d'une EUI-64

• L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit u (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 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 3-10 Transformation d'une adresse MAC en identifiant d'interface

• Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou FDDI), cette adresse est utilisée pour construire des identifiants d'interface sur 64 bits, comme indiqué sur la figure ci-contre.

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 0xFFFE 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é 0xFFFF. 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 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.
• 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.
  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.

Manuel

L'utilisation de l'adresse MAC pour construire l'adresse IP de la machine peut conduire dans certains cas à des problèmes de configuration, en particulier si la machine est un serveur. En effet, s'il l'on change la carte Ethernet de l'équipement (voire l'équipement) l'adresse IPv6 qui en dépend change également.

Le resolveur DNS est le cas le plus flagrant, chaque machine sur le réseau doit posséder dans le fichier /etc/resolv.conf l'adresse IPv6, en cas de changement de carte réseau, l'ensemble de machine du domaine devront être reconfigurée manuellement pour prendre en compte le changement d'adresse. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au resolver DNS une adresse manuelle.

Valeur aléatoire

L'identifiant d'interface tel qu'il a été défini 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.

L'adresse publique globale est conservée, mais ne sera jamais choisie pour initier des communications. Elle permettra par contre d'en recevoir, même si l'anonymat est validé.

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.

Ces identifiants privés ne sont pas incompatibles avec les identifiants publics. Une machine peut attendre des ouvertures de connexions sur ses adresses publiques, par contre initier les connexions en utilisant ses identifiants privés. Il suffit de considérer que les adresses publiques sont dépréciées pour une durée indéterminée.

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.

Adresses Lien-local

Table des matières

Site-local