Revision as of 20:55, 12 April 2016

Activité 14  : L'utilisation des adresses sur une interface réseau

Introduction

Nous allons appréhender les différents modes de construction des identifiants d'interface pour des adresses unicast. Puis, nous observerons l'intérêt de la durée de vie et du choix d'une valeur aléatoire.

Structure de l'adressage

Lors de l'activité précédente, nous avons vu que les adresses unicast sont construites hiérarchiquement (voir la figure 1). Un premier niveau de hiérarchisation découpe l'adresse en deux parties logiques : un préfixe réseau/sous-réseau qui sera utilisé pour acheminer le datagramme à travers le réseau, et un identifiant d'interface qui sera utilisé sur le dernier saut pour remettre le datagramme à l'interface de destination.

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

Identifiant d'interface

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]:

• manuelle,
• basée sur l'adresse de niveau 2 de l'interface [RFC 4291],
• aléatoire,
• cryptographique.

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

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

ou plus simplement

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

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

Il existe plusieurs méthodes pour construire l'identifiant :

Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure suivante : 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 2 : Format de l'identificateur IEEE EUI-64.

L'identifiant d'interface à 64 bits d'une adresse IPv6 est dérivé de l'EUI-64 en inversant le bit u. 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 : Identifiant d'interface au format EUI-64 "modifié".

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 4 illustre ce processus.

Figure 4 : 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 2 (adresse EUI-64 et EUI-48 (MAC)). 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. Pour plus de précisions, vous pouvez consulter l'interprétation personnelle de la lecture du RFC 7136 de Stéphane Bortzmeyer : http://www.bortzmeyer.org/7136.html.

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

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 (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 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. 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 5 : Adresse IPv6 temporaire de MS-Windows.

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.

Adressage multiple des interfaces

En IPv6, les interfaces des équipements disposent simultanément de plusieurs adresses. Ainsi, comme nous l'avons vu dans l'activité précédente, une interface dispose au moins d'une adresse purement locale sur son lien de rattachement (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. 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 globales), en associant le préfixe d'adresse du lien support à l'identifiant d'interface. L'affectation de ces adresses routables peut être soit assurée par l'administrateur système de la machine, soit gérée automatiquement 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.

Figure 6 : Adressage multiple des interfaces.

Gestion de la durée de validité de l'adresse

L'activité introductive de la séquence ("Qu'est ce qu'une adresse IP ?") nous a présenté les différents états de validité d'une adresse (test, préféré, déprécié, invalide) qui régissent la durée de vie de l'adresse. Comme nous venons de le voir avec les adresses aléatoires respectueuses de la vie privée, certaines adresses sont temporaires et doivent être renouvelées périodiquement. C'est le système d'exploitation gérant l'interface qui assure la cohérence, notamment en passant une adresse dans l'état déprécié pour permettre la clôture des sessions et des connexions existantes, parallèlement à la procédure d'activation d'une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives.

Figure 7 : Gestion de la durée de validité des adresses.

Conclusion

Nous avons appréhendé les différents modes de construction des identifiants d'interfaces pour des adresses unicast. Puis, nous avons vu l'intérêt de la durée de vie et du choix d'une valeur aléatoire. Enfin, nous avons observé l'intérêt d'un adressage multiple.

Références bibliographiques

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
• RFC 3972 Cryptographically Generated Addresses (CGA)Analyse
• RFC 4291 IP Version 6 Addressing Architecture Analyse
• RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Analyse
• RFC 7136 Significance of IPv6 Interface Identifiers Analyse
• RFC 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) Analyse