Difference between revisions of "MOOC:Compagnon Act14-s7"
From Livre IPv6
| Line 1: | Line 1: | ||
| − | |||
| − | |||
<!-- __NOTOC__ | <!-- __NOTOC__ | ||
--> | --> | ||
| Line 28: | Line 26: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Nécessité d'organiser un plan d'adressage == | == Nécessité d'organiser un plan d'adressage == | ||
| Line 481: | Line 360: | ||
|} | |} | ||
</center> | </center> | ||
| + | |||
| + | |||
| + | == Identifiant d'interface (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]: | ||
| + | |||
| + | * 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éé. | ||
| + | <center> | ||
| + | <tt>2001:db8:1234:1::1<br> | ||
| + | 2001:db8:1234:1::2</tt> | ||
| + | </center> | ||
| + | |||
| + | * 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 : | ||
| + | <center> | ||
| + | <tt>2001:db8:1234:1::7B</tt><br> | ||
| + | </center> | ||
| + | ou plus simplement<br> | ||
| + | <center> | ||
| + | <tt>2001:db8:1234:1::123</tt> | ||
| + | </center> | ||
| + | |||
| + | * Reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à saisir : | ||
| + | <center> | ||
| + | <tt>2001:db8:1234:1::192.0.2.123</tt> | ||
| + | </center> | ||
| + | |||
| + | ==== 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<ref>Internet society. (2014) Deploy 360 programm [http://www.internetsociety.org/deploy360/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ IPv6 Privacy Addresses Provide Protection Against Surveillance And Tracking]</ref>. 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, <tt>u</tt> (septième bit du premier octet), et <tt>g</tt> (huitième bit du premier octet) ont une signification spéciale : | ||
| + | ** <tt>u</tt> (Universel) vaut 0 si l'identifiant EUI-64 est universel ; | ||
| + | ** <tt>g</tt> (Groupe) indique si l'adresse est individuelle (<tt>g</tt> = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (<tt>g</tt> = 1), par exemple une adresse de multicast. | ||
| + | |||
| + | <center> | ||
| + | [[Image:activite-14-adresses-interface-reseau-img02-800x406-v20151012-01.jpg|666px|thumb| Figure 2 : Format de l'identificateur IEEE EUI-64.]] | ||
| + | </center> | ||
| + | |||
| + | '''L'identifiant d'interface à 64 bits d'une adresse IPv6 est dérivé de l'EUI-64 en inversant le bit <tt>u</tt>'''. 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. | ||
| + | |||
| + | <center> | ||
| + | [[Image:activite-14-adresses-interface-reseau-img03-800x405-v20151012-01.jpg|666px|thumb| Figure 3 : Identifiant d'interface au format EUI-64 "modifié".]] | ||
| + | </center> | ||
| + | |||
| + | ===== 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 <tt>u</tt> est mis à 1 comme dans le cas précédent. La figure 4 illustre ce processus. | ||
| + | |||
| + | <center> | ||
| + | [[Image:activite-14-adresses-interface-reseau-img04-850x380-v20151012-01.jpg|666px|thumb|center| Figure 4 : Identifiant d'interface dérivé de l'adresse MAC (EUI-48).]] | ||
| + | </center> | ||
| + | |||
| + | ===== 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 <tt>u</tt> 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 <tt>u</tt> et <tt>g</tt> 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 <tt>u</tt> 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. | ||
| + | |||
| + | <center> | ||
| + | [[image:activite-14-adresses-interface-reseau-img05-679x510-v20151012-01.png|666px|thumb| Figure 5 : Adresse IPv6 temporaire de MS-Windows.]] | ||
| + | </center> | ||
| + | |||
| + | ==== 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 == | == Conclusion == | ||
Revision as of 05:33, 20 April 2016
Contents
- 1 Activité 14 : L'utilisation des adresses sur une interface réseau
- 1.1 Introduction
- 1.2 Adressage multiple des interfaces
- 1.3 Nécessité d'organiser un plan d'adressage
- 1.4 Politique d'assignation des adresses
- 1.5 Préfixes de sous Réseaux (SID Subnet IDentifier)
- 1.6 Différentes stratégies pour la définition des sous réseaux
- 1.6.1 Réseau à plat
- 1.6.2 Correspondance directe entre les identifiants IPv4 et IPv6
- 1.6.3 Plan d'adressage structuré
- 1.6.4 Identification des sous-réseaux d'après les VLAN
- 1.7 Identifiant d'interface (IID Interface IDentifier)
- 1.8 Conclusion
- 1.9 Références bibliographiques
- 1.10 Pour aller plus loin
Activité 14 : L'utilisation des adresses sur une interface réseau
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 élement vise à localiser le réseau dans l'Internet. Il sert à l'acheminement des paquets à travers l'Internet. Le second élément identifie l'interface au sein de son réseau. Il sert à la remise du paquet à l'interface de destination. 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é 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. 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.
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 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.
L'activité introductive de la séquence ("Qu'est ce qu'une adresse IP ?") nous a présenté les différents états d'une adresse que sont l'état : test, préféré, déprécié et invalide. Ces états 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. Le renouvellement est assuré par le système d'exploitation. Il passe une adresse dans l'état déprécié afin de clore les sessions et les connexions existantes. En même temps, Il active une nouvelle adresse valide pour les nouvelles connexions ou sessions applicatives.
Nécessité d'organiser un plan d'adressage
Comme nous l'avons vu dans les activités précédentes, l'espace d'adressage IPv6 est « astronomiquement » grand. Le plan d'adressage unicast global agrégé adopté aujourd'hui sur l'Internet public est organisé hiérarchiquement. A 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), les réseaux IP sont bâtis 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,...), gérées par les registres Internet régionaux (RIR Regional Internet Registry). Cela permet d'acheminer efficacement les datagrammes. Les opérateurs du cœur de l'internet routent (aiguillent) les datagrammes selon les préfixes les plus courts. Les registres régionaux 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 une 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 au cours de cette activité, présenter différents modes d'organisation possibles, que nous compléterons par un cas d'école simple[1].
Politique d'assignation des adresses
Les spécifications primitives, (RFC 3177) de 2001, d'assignation des adresses 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 était nécessaire
- /128 (adresse unique) lorqu'il était absolument connu qu'un et un seul équipement était connecté
Le RFC 6177, de 2011, é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 le 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 (machine à laver, 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)
Cas général
Les sous réseaux IPv6 devraient 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.
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. Comme 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 mais qui peuvent sur certains équipements, limités ou mal configurés, conduire à des situations de surcharge sous forme d'aller retour de datagrammes sur cette liaison (syndrome de la balle de ping pong), ou de tentatives de déni de service par attaque exhaustive de découverte de 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é comme l'adresse anycast des routeurs (« all routers anycast address »), ce qui signifie que le plupart des routeurs sont susceptibles 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éseaux 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 lisibles 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 »)
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 héxadécimal (0..9, a..f) (cf vademecum de notation hexadécimale) ; - Les chiffres et lettres minuscules ['a'..'f'], 'b', 'l', 't', 'v', 'w', 'x', 'y' et 'z' 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 de type 2001:db8:tlbb::/64 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}).
Différentes stratégies pour la définition des sous réseaux
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 envisagée avec l'identifiant SID d'IPv6 par transcription directe. Exemple
Dans ce plan d'adressage, le lien direct entre les sous réseaux IPv4 et les sous réseaux IPv6 est directement visible. Pour les équipements d'infrastructure disposant d'une adresse fixe (routeur, serveurs applicatifs,...) on peut également transposer l'identifiant d'hôte (les 4ieme octet d'adresse IPv4 d'un /24) en identifiant d'interface de l'adresse IPv6. Ainsi, par exemple, le serveur web d'adresse IPv4 192.168.1.123 peut être adressé 2001:db8:cafe:1::123 en IPv6.
Cependant cette stratégie ne peut s'envisager uniquement si les sous réseaux IPv4 sont alignés sur 24 bits (/24). En effet des sous réseaux IPv4 de taille plus étendue (préfixe < à /24) ou plus réduite (préfixe > à/24) ne peuvent s'insérer dans le champs SID de 16 bits d'un préfixe IPv6 en /64 (le débordement au delà du /64 posant de problème pour l'auto-configuration). Ainsi :
- un préfixe IPv4 /28, par exemple les hôtes 172.16.5.14/28 et 172.16.5.18/28 sont dans des sous réseaux IPv4 distincts, le sous réseau 172.16.5.0/28 pour le premier et le sous réseau 172.16.5.16/28 pour le second. Alors que la transposition simple en IPv6 va les placer dans le même sous réseau : les hôtes 2001:db8:cafe:5::14/64 et 2001:db8:cafe:5::18/64 sont tous les deux dans le sous réseau 2001:db8:cafe:5::/64.
- Un préfixe IPv4 /23, par exemple les hôtes 10.0.8.250/23 et 10.0.9.5/23 sont tous le deux dans le même sous réseau IPv4. Alors que la transposition simple les placera dans des sous réseaux IPv6 distincts : 2001:db8:cafe:8::250/64 et 2001:db8:cafe:9::5/64
On notera également que la transposition directe des identifiants décimaux des sous réseaux IPv4 dans le champ SID hexadécimal du sous réseau IPv6, si elle facilite la correspondance de lecture pour l'administrateur humain, n'est en revanche pas optimale pour les tables de routage des sous réseaux IPv6. Ainsi le sous réseau IPv4 10.0.23.0/24 est sélectionné (filtré / masqué) sur 1 octet de valeur binaire 0001 0111, alors qu'il sera sélectionné par le SID 0x0023 hexadécimal (0000 0000 0010 0011)
Correspondance directe entre les adresses IPv4 et IPv6
Si le préfixe de sous réseau IPv4 n'est pas aligné sur un /24, il sera impossible de maintenir une relation directe entre les sous réseaux IPv4 et IPv6. Cependant, dans ce cas il peut être envisagé de maintenir une correspondance d'adresse en embarquant la totalité de l'adresse IPv4 dans l'identifiant d'interface de l'adresse IPv6 et en gérant le SID indépendamment du sous réseau IPv4. Par exemple la machine d'adresse IPv4 192.168.1.234 pourrait être adressée en IPv6 2001:db8:cafe:deca::192.168.1.234. En effet pour les adresses IPv6 embarquant une adresse IPv4, si celle ci occupe les 32 bits de poids faible de l'adresse IPv6 (la partie basse de l'identifiant d'interface) il est autorisé de continuer à la noter en notation décimale pointée. Cependant, si cette commodité facilite la saisie de la configuration d'un système, celui ci l'affichera sous la forme canonique 2001:db8:cafe:deca::c0a8:1ea, notamment dans les journaux et log diverses. . c0a801ea étant la conversion hexadécimale des 32 bits de l'adresse IPv4 écrite 192.168.1.234 en notation décimale pointée, la correspondance de lecture devient tout de suite moins évidente.
Plan d'adressage structuré
Lorsque que l'on définit un plan d'adressage, il faut décider quelle structure doit être utilisée pour assigner les adresses aux réseaux de l'organisation. Plusieurs stratégies peuvent être envisagées. En nous appuyant sur l'exemple d'architecture suivante, nous allons présenter différents plans possibles.
Structuration basique du plan d'adressage
Nous pouvons, par exemple, assigner les adresses des équipements par type d'usage ou par localisation, voire une combinaison des deux. Ainsi nous pouvons choisir d'adresser d'abord par type localisation, puis par type. Une fois les sous-réseaux définis, il restera les bits de poids faible qui pourront être utilisés pour d'autres usages
Dans cet exemple , 4 bits sont assignés pour la localisation {L}, les 4 bits suivants sont assignés pour le type d'usage {T}, il reste 8 bits {B} pour d'autres affectations. Ainsi, ce plan d'adressage permet d'addresser une infrastructure qui peut être étendue sur 16 (4 bits) localisations, chacune pouvant déployer 16 (4 bits) types de-réseaux. On dispose encore de 8 bits restants permettant éventuellement 256 sous réseaux différents pour chaque localisation et chaque type.
Routeur vs firewall : Localisation ou type d'usage d'abord ?
Nous devons dans un premier temps décider quelle affectation nous souhaitons privilégier : localisation d'abord puis type (tels que, public(DMZ), employés, étudiants, invités, switchs, routeurs, serveurs, administration, comptabilité, production, etc,) ou inversement type avant la localisation.
Localisation d'abord
Quand la structuration se fait d'abord sur la localisation, chaque campus, bâtiment, département est administrativement identifié par une référence. Cela permet d'optimiser les tables de routage. A l'instar de l'organisation des opérateurs, tous les réseaux de même destination seront agrégés en une unique route dans les tables de routage. Ce type de structuration du plan d'adressage convient aux organisations qui sont chargées de l'infrastructure globale d'interconnexion, en général de opérateurs ou les entités chargés des réseaux d'interconnexion des grandes organisations.
Type d'usage d'abord
Si le type d'usage des réseaux est d'abord privilégié, l'optimisation des entrées dans les tables de routage n'est alors pas envisageable. Cependant, cela n'est en général pas un problème pour la plupart des routeurs modernes, qui peuvent gérer un nombre conséquent d'entrées de table de routage. L'avantage de grouper les réseaux par catégorie d'usage, est que cela facilite l'application des politiques de sécurité. La plupart des équipements de sécurité (pare-feux, listes de contrôles d'accès, contrôle des autorisations,…) sont régis selon les types d'usage plutôt que sur la localisation des utilisateurs. Les organisations choisissent communément de privilégier les types d'usage sur la localisation pour des raisons pratiques. L'application des politiques de contrôle d'accès et de sécurisation, basées sur des listes de filtres logiques, est généralement déléguée à des équipements spécialisés, de type pare feu, placés frontalement à l'entrée du réseau. Une fois contrôlés les flux sont ensuite acheminés en interne en fonction de leur localisation.
Détermination de l'espace nécessaire au plan d'adressage
Nous devons déterminer, quelle proportion des 16 bits du SID sera nécessaire pour chaque partie de cette structuration. Le nombres de bits nécessaires pour coder chacune des catégories de la structuration est conditionné par le nombre de types et de localisations de sous-réseaux de l'infrastructure en ne négligeant pas les évolutions.
- Déterminer le nombre de localisations ou types de réseaux de votre organisation,
- augmenter le nombre d'une localisation supplémentaire, nécessaire pour le backbone,
- augmenter le nombre de localisations pour tenir compte d'éventuels sous-réseaux qui n'ont pas de localisation fixe, tels que les l'infrastructure des tunnels VPN par exemple,
- augmenter le nombre de chacune des catégories pour tenir compte des expansions de court et moyen terme,
Pour chacune des catégories déterminer la puissance de deux immédiatement supérieure ou égale, ce qui nous indiquera le nombre de bits nécessaires pour en coder les références.
Exemple 1 : sous réseaux basés sur la localisation
- nombre de localisations : 3
- backbone d'interconnexion (réseau reliant swithches et routeurs) : 1
- réseaux non localisés (tunnels VPN) : 1
- extension future : 2
total : 7 sous réseaux => 3 bits suffisent pour encoder les localisations, le reste pouvant être utilisé pour d'autres référencements
Exemple 2 : sous réseaux basés sur le type d'usage
- nombre de groupes d'usage (personnel, étudiants, invités, serveurs, infra VPN) : 5 sous-réseaux,
- backbone et infrastructure (réseau reliant swithches et routeurs); 1 sous-réseau,
- usages futurs : 4 sous-reseaux
total : 10 sous-réseaux => 4 bits suffisent pour encoder les types de sous-réseaux, les 12 bits restants pouvant être utilisés pour d'autre référencements au besoin
Hiérarchisation à 2 niveaux
Dans les deux exemples précédents les bits restants peuvent être utilisés pour numéroter un second niveau de sous-réseaux. Si la numérotation primaire est basée sur la localisation, plusieurs sous-réseaux peuvent être adressés sur chaque site. Si la numérotation primaire est par type d'usage, alors plusieurs réseaux de chaque type peuvent être crées (par les réseaux internes réservés au personnel peuvent être décliné pas service ou fonction : comptabilité, RH, direction, production,...). Les deux types de structuration, localisation / type d'usage, peuvent également se combiner. Si on choisit de privilégier la location en structure primaire
Il reste alors 9 bits pouvant coder 512 instances de sous-réseaux de chaque type sur chaque site. Le fait de privilégier la localisation, en positionnant sa référence sur les bits de poids fort du SID facilitera l'optimisation des tables de routage de l'infrastructure d'interconnexion des sites. Cependant elle alourdira les politiques de sécurisation, en multipliant les filtres, si la fonction de sécurisation (firewal)l est centralisée, ou elle imposera de disposer d'une fonction de sécurisation (firewall) sur chaque site entraînant des difficultés de cohérence de déploiement des politiques de sécurité. Inversement privilégier le type d'usage sur la localisation
réduira le nombre de filtres de la politique de sécurisation, au détriment du nombre d'entrées dans les tables de routage de l'interconnexion. Cependant, cela ne pose en général pas de difficultés majeures compte tenus des capacité des routeurs modernes.
Latitude
Dans l'exemple précédent, 4 bits sont utilisés pour les types de sous-réseaux et 3 pour la localisation, laissant 9 bits soit 512 (2 puissance 9) sous réseaux possibles par type et par site. Cela sera suffisant dans la plupart des cas. Cependant, imaginons qu'il faille 2048 tunnels VPN par site pour accueillir les connexions sécurisées des personnels nomades. On pourrait envisager de modifier les tailles de champs de structuration primaire et secondaire, mais cela nécessiterait une reconfiguration globale de l'architecture. Une autre option consiste à répartir les tunnels sur 4 types distincts, chacun pouvant gérer 512 tunnels. De cette manière on conserve politique de sécurité simple et cohérente
| Type | Usage |
|---|---|
| 0 | Backbone, infrastructure |
| 1 | Serveurs |
| 2 | Réservé expansion future |
| 3 | Réservé expansion future |
| 4 | personnels |
| 5 | étudiants |
| 6 | invités |
| 7 | Réservé expansion future |
| 8 | VPNs |
| 9 | VPNs |
| a | VPNs |
| b | VPNs |
| c | Réservé expansion future |
| d | Réservé expansion future |
| e | Réservé expansion future |
| f | Réservé expansion future |
Lisibilité
Lorsque que l'on dispose d'un espace d'identification suffisamment large, dans notre cas de champ SID sur 16 bits nous laissant 9 bits 'B' de marge, il est de bonne pratique d'aligner les identifiants sur des frontières de mots de 4 bits (quartet) pour faciliter la lisibilité des préfixes notés en hexadécimal. Ainsi dans notre exemple si on étend l'identifiant de la localisation sur 4 bits au lieu de 3, elle sera visuellement facilement identifiée par un opérateur humain lors de la lecture des adresses. Le format des adresses de nos exemple devient donc :
soit en notation canonique des adresses rescpectivement
avec les "nibbles" w pour identifier la localisation et x pour le type sous réseau.
Extensibilité
Si le nombre de localisations ou de types de sous réseaux, n'est pas à priori connu au moment de l'établissement du plan d'adressage, il est recommandé de conserver des frontières flexibles entre les différents groupes de bits identifiants les différents niveaux de la structuration. Cela peut être réalisé en adoptant une des stratégies décrites dans les RFC 1219 et RFC 3531. La contrepartie de cette approche est q'une certaine aisance dans la manipulation des bits doive être acquise, dans la mesure ou les frontières des zones d'identification peuvent être amenées à évoluer, ce qui peut nécessiter des mises à jour des règles et filtres de la politique de sécurité. Ainsi, par exemple, en assumant une structuration où l'on privilégie d'abord la localisation des sous-réseaux, assignée aux bits de poids fort, sur le type assigné au bits intermédiaire, un plan d'adressage flexible initialement conçu pour 5 localisations, 3 types et 2 sous-réseaux par localisation/type :
Pourrait évoluer selon le scénario hypothétique suivant : passant de 2 à 10 sous-réseaux nécessitant 4 bits B
Après cela, le nombre de types d'usage pourrait passer à 5, nécessitant un troisième bit T
Puis suite à une expansion géographique, le nombre de sites passerait à 50, portant à 6 le nombres de bits L
Si ensuite le nombres de types d'usage passait à 13, on étendrait le champ type par un quatrième bit pris sur la droite où il reste plus de bits disponibles
Nota 1 : Les champs dont l'agrandissement s'effectue par la droite ({L} et {T} dans notre exemple) encodent les nombres selon un ordonnancement inhabituel. Le RFC 3531 décrit précisément les référencements de croissance gauche (les bits {B} dans notre exemple) centrale (les bits {T} dans notre exemple) ou droite (les bits {L} dans notre exemple).
Nota 2 : Cette stratégie prenant en compte les besoins d'extensibilité peut s'avérer difficilement conciliable avec l'objectif de lisibilité préconisant un alignement sur les quartets tel que décrit dans le paragraphe précédent.
Identification des sous-réseaux d'après les VLAN
Confinement des domaines de diffusion de niveau 2 : les VLAN
Ethernet est le protocole dominant de niveau liaison de données (niveau 2 de la pile protocolaire), support du niveau réseau IPv6, des infrastructures de réseaux de la plupart des organisations. Les architectures Ethernet modernes, constituées de commutateurs (switch ethernet) sont généralement subdivisées en différents domaines de diffusion étanches, couramment dénommés VLAN. Cette structuration en VLAN permet de constituer des groupes logiques de machines partageant un même support de diffusion. Chaque VLAN ethernet dispose d'un identifiant propre (VLAN-ID). Au niveau réseau (niveau 3 de la pile protocolaire), où opère le protocole IPv6, chaque VLAN se voit affecter un (ou plusieurs) identifiants de sous réseaux distincts. En effet deux postes, localisés dans des VLAN distincts ne peuvent échanger directement des données et doivent passer une une fonction de routage inter-réseaux (routeur) pour pouvoir communiquer.
Mise en correspondance VLAN-ID et SID
Une autre approche de structuration du plan d'adressage, sur ce type d'infrastructure, est de dériver l'identifiant de sous-réseau IPv6 (SID) de l'identifiant du domaine de diffusion (VLAN-ID). Les identifiants de VLAN ethernet (VLAN-ID) ont une taille de 12 bits, 4094 VLAN distincts (les valeurs 0 et 4095 étant réservées) peuvent être créés sur une infrastructure locale. Dans notre cas de figure (préfixe en /48) où nous disposons de 16 bits pour identifier nos sous réseaux IPv6, on peut envisager de faire coïncider VLAN-ID et SID soit sous leur forme hexadécimale soit sous leur forme décimale.
- forme hexadécimale : en convertissant la valeur décimale de l'identifiant de VLAN en hexadécimale pour le transposer en identifiant de sous-réseau sur trois quartets (nibble). Dans ce cas, il reste un quartet du champ SID libre, qui peut être utilisé pour éventuellement coder 16 localisations ou 16 types. Il faut alors décider la position du quartet libre, soit sur le quartet de poids fort, soit sur le quartet de poids faible
VLAN-ID sur les bits de poids fort du SID 2001:db8:cafe:{VVVVVVVVVVVVBBBB}::/64 ou VLAN-ID sur les bits de poids faible du SID 2001:db8:cafe:{BBBBVVVVVVVVVVVV}::/64
Cependant, si les adresses IPv6 sont en notation hexadécimale (cf activité 12), les identifiants de VLAN sont en notation décimale, ce qui ne facilite pas la lisibilité de correspondance lors de la lecture de l'adresse IPv6.
- forme décimale : Afin de conserver une correspondance lisible, entre identifiant de sous réseau IPv6 et l'identifiant de VLAN on peut conserver la valeur décimale du VLAN-ID et l'utiliser directement en lieu et place de l'identifiant SID hexadécimal. La correspondance est alors directement lisible. Ainsi le sous réseau IPv6 2001:db8:cafe:4321::/64 sera affecté au VLAN 4321. On remarquera que les identifiants de sous réseaux supérieurs à 4095 ainsi que ceux comportant une ou plusieurs lettres hexadécimales (a..f) sont disponibles pour d'autres sous-réseau logiques non liés à un VLAN.
Tableau récapitulatif des deux approches
| VLAN-ID | IPv6 vlan-id forme décimale | IPv6 vlan-id forme hexadécimale poids faible | IPv6 vlan-id forme hexadécimale poids fort |
|---|---|---|---|
| 1 | 2001:db8:cafe:0001::/64 | 2001:db8:cafe:0001::/64 | 2001:db8:cafe:0010::/64 |
| 12 | 2001:db8:cafe:0012::/64 | 2001:db8:cafe:000c::/64 | 2001:db8:cafe:00c0::/64 |
| 2783 | 2001:db8:cafe:2783::/64 | 2001:db8:cafe:0adf::/64 | 2001:db8:cafe:adf0::/64 |
| 4094 | 2001:db8:cafe:4094::/64 | 2001:db8:cafe:0ffe::/64 | 2001:db8:cafe:ffe0::/64 |
Cette approche introduit une certaine cohérence entre l'infrastructure de niveau 2 et l'adressage de niveau 3 et simplifie la numérotation des sous-réseau IPv6 dans la mesure où une seule numération doit être gérée. Cependant elle n'est pas optimale pour minimiser le nombre d'entrees dans les tables de routage ou pour optimiser les politiques de contrôle d'accès basées sur le filtrage des préfixes.
Identification des VLAN selon la localisation ou le type d'usage
Il est possible d'envisager un codage des VLAN-ID intégrant la localisation ou le type d'usage. Dans ce cas il est souhaitable de conserver un alignement sur frontières de quartet (nibble), de ce fait on peut choisir de coder la localisation sur 4 ou 8 bits {W} et coder respectivement le type sur 8 ou 4 bits {V} ou inversement. De même, comme pour la hiérarchisation à deux niveaux vue précédemment) il faudra choisir de privilégier soit la localisation ou le type en le positionnant sur les bits de poids fort.
- forme hexadécimale : dans cette forme sur un SID long de 16 bits, on conserve 4 bits utilisables pour coder 16 instances de chaque localisation/type.
VLAN-ID sur les bits de poids fort du SID
localisation {W} sur 4 bits (1 quartet) privilégiée
2001:db8:cafe:{WWWWVVVVVVVVBBBB}::/64
ou
VLAN-ID sur les bits de poids fort du SID
localisation {W} sur 8 bits (2 quartets) privilégiée
2001:db8:cafe:{WWWWWWWWVVVVBBBB}::/64
inversement, si on privilégie le type d'usage
VLAN-ID sur les bits de poids fort du SID
type d'usage {V} sur 4 bits (1 quartet) privilégié
2001:db8:cafe:{VVVVWWWWWWWWBBBB}::/64
ou
VLAN-ID sur les bits de poids fort du SID
type d'usage {V} sur 8 bits (2 quartets) privilégié
2001:db8:cafe:{VVVVVVVVWWWWBBBB}::/64
Quelques exemples illustratifs de la forme hexadécimale (localisation sur 1 quartet, type d'usage sur 2 quartets)
| VLAN-ID | localisation | Type d'usage | IPv6(VLAN-ID hexadécimal) | |||
|---|---|---|---|---|---|---|
| décimal | hexa | décimal | hexa | décimal | hexa | |
| 0001 | (001) | 0 | (001) | 1 | (001) | 2001:db8:cafe:0010::/64 |
| 0529 | (211) | 2 | (211) | 17 | (211) |
2001:db8:cafe:2110::/64 |
| 4094 | (ffe) | 15 | (ffe) | 254 | (ffe) |
2001:db8:cafe:ffe0::/64 |
- forme décimale : La lisibilité directe est alors conservée, mais chaque quartet (nibble) ne peut prendre qu'une valeur numérique (0..9), il ne reste plus de bits du SID disponibles pour coder d'éventuelles instances de chaque type/localisation. Cependant on pourra choisir d'affecter un, deux ou trois quartet pour coder 10, 100, ou 1000 localisations, avec respectivement 1000, 100, 10 types d'usage.
2001:db8:cafe;1025::/64
VLAN 1025, localisation (1) type d'usage (025)
cas de la localisation sur 1 quartet et type d'usage sur 3 quartets
ou
VLAN 1025, localisation (10) type d'usage (25)
cas de la localisation sur 2 quartets et type d'usage sur 2 quartets
ou
VLAN 1025, localisation (102) type d'usage (5)
cas de la localisation sur 3 quartets et type d'usage sur 1 quartet
Quelques exemples illustratifs de la forme décimale (localisation sur 2 quartets, type d'usage sur 2 quartets)
| VLAN-ID | localisation | Type d'usage | IPv6(VLAN-ID forme décimale) |
|---|---|---|---|
| 0001 | 00 | 01 | 2001:db8:cafe:0001::/64 |
| 0529 | 05 | 29 | 2001:db8:cafe:0529::/64 |
| 4094 | 40 | 94 | 2001:db8:cafe:4094::/64 |
Identifiant d'interface (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]:
- 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éé.
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.
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.
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.
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.
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.
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
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
- ↑ « Preparing an IPv6 address plan », publiée sous licence CC-BY par Surfnet (www.surfnet.nl) Preparing an IPv6 address plan
- ↑ 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 :
- 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 5375 IPv6 Unicast Address Assignment Considerations Analyse
- RFC 6177 IPv6 Address Assignment to End Sites 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
