Difference between revisions of "Identifiant d'interface"

From Livre IPv6

(EUI-64)
(Valeur aléatoire)
 
(16 intermediate revisions by 4 users not shown)
Line 7: Line 7:
 
Les chapitres suivants décrivent ces différentes méthodes ainsi que leur intérêts et leur défauts.
 
Les chapitres suivants décrivent ces différentes méthodes ainsi que leur intérêts et leur défauts.
  
== EUI-64 ==
+
== Différents types d'identifiants 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.
 
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.
Line 18: Line 19:
 
** <tt>u</tt> (Universel) vaut <tt>0</tt> si l'identifiant EUI-64 est universel,
 
** <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.
 
** <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.
: L'ordre des bits ne doit pas porter à confusion. Dans la représentation numérique des valeurs,
+
: 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.  
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.  
+
  
 
[[image:Fig3-9.png|thumb|right|350px|Figure 3-9 ''Identificateur d'interface dérivé d'une EUI-64'']]
 
[[image:Fig3-9.png|thumb|right|350px|Figure 3-9 ''Identificateur d'interface dérivé d'une EUI-64'']]
Line 28: Line 27:
 
[[image:Fig3-10.png|thumb|right|350px|Figure 3-10 ''Transformation d'une adresse MAC en identifiant d'interface'']]
 
[[image:Fig3-10.png|thumb|right|350px|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 suivante.
+
* 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 <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.
 
: 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.
  
Line 35: Line 34:
 
* 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.
 
* 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.
  
== Manuel ==
+
=== 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.
 
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 <tt>/etc/resolv.conf</tt> 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.
+
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 machine 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.
  
== Valeur aléatoire ==
+
=== 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.
 
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.
Line 51: Line 54:
 
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.
 
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.
+
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 ==
+
[[image:Fig3-A.png|thumb|right|350px|''Configuration des interfaces sous Windows'']]
 +
 
 +
La figure Configuration des interfaces sous Windows illustre cette propriété, en retournant le résultat de la commande <tt>ipconfig</tt>. On peut noter que l'interface du réseau sans-fils possède trois adresses IPv6 (une lien locale et deux globales). Les adresses globales possèdent le même préfixe de 64 octets (<tt>2001:660:7307:6030::/64</tt>). La première adresse globale a le bit <tt>u=0</tt> dans l'identifiant d'interface, il s'agit de celle générée aléatoirement. La deuxième à le bit <tt>u</tt> à <tt>1</tt> et l'on retrouve la séquence <tt>0xFFFE</tt> au milieu de l'identifiant d'interface; cette adresse est dérivée de l'adresse MAC. Sous Windows, par défaut, les adresses aléatoires ont une durée de vie d'une semaine. Par exemple, en utilisant la commande <tt>netsh</tt> :
 +
 
 +
'''netsh interface ipv6 show address'''
 +
Recherche du statut actif...
 +
 +
 +
Interface 7 : Connexion réseau sans fil
 +
 +
Type adr.  État DAD  Vie valide Vie préf.  Adresse
 +
---------  --------- ---------- ---------- -----------------------------------
 +
Temporaire Préféré    6d21h18m38s    21h15m51s 2001:660:7307:6030:c853:e48b:aafb:c354
 +
Public    Préféré    29d23h58m59s  6d23h58m59s 2001:660:7307:6030:204:e2ff:fe5a:9f
 +
Liaison    Préféré        infinite    infinite fe80::204:e2ff:fe5a:9f
 +
 
 +
=== 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.
 
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.
 +
 +
==Selection du type d'identifiant d'interface==
 +
 +
Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv4. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.
  
 
{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}
 
{{suivi |Lien-local|Adresses Lien-local|Site-local|Site-local}}

Latest revision as of 09:52, 13 July 2009

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'identifiants 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 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 machine 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.

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.

Configuration des interfaces sous Windows

La figure Configuration des interfaces sous Windows illustre cette propriété, en retournant le résultat de la commande ipconfig. On peut noter que l'interface du réseau sans-fils possède trois adresses IPv6 (une lien locale et deux globales). Les adresses globales possèdent le même préfixe de 64 octets (2001:660:7307:6030::/64). La première adresse globale a le bit u=0 dans l'identifiant d'interface, il s'agit de celle générée aléatoirement. La deuxième à le bit u à 1 et l'on retrouve la séquence 0xFFFE au milieu de l'identifiant d'interface; cette adresse est dérivée de l'adresse MAC. Sous Windows, par défaut, les adresses aléatoires ont une durée de vie d'une semaine. Par exemple, en utilisant la commande netsh :

netsh interface ipv6 show address
Recherche du statut actif... 


Interface 7 : Connexion réseau sans fil 

Type adr.  État DAD  Vie valide Vie préf.  Adresse
---------  --------- ---------- ---------- -----------------------------------
Temporaire Préféré     6d21h18m38s    21h15m51s 2001:660:7307:6030:c853:e48b:aafb:c354
Public     Préféré    29d23h58m59s  6d23h58m59s 2001:660:7307:6030:204:e2ff:fe5a:9f
Liaison    Préféré        infinite     infinite fe80::204:e2ff:fe5a:9f

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.

Selection du type d'identifiant d'interface

Si l'on sélectionne correctement le type d'identifiant d'interface, la gestion de l'adressage IPv6 est aussi facile (voire plus simple) qu'en IPv4. Ainsi, il est préférable de donner aux serveurs des identifiants d'inteface construit manuellement. Il sera ainsi beaucoup plus facile de se rappeler de leur adresse. De plus si l'équipement est remplacé et par conséquent que la carte réseau est différente, l'adresse IPv6 restera stable. Pour les clients, il est plus simple d'utiliser l'identifiant d'interface construit à partir de l'adresse MAC.

Adresses Lien-local Table des matières Site-local
Personal tools