Revision as of 11:59, 10 June 2015

> MOOC>Contenu>Séquence 4 > Activité 42

Contexte de déploiement

Le mécanisme de double pile IP (Dual Stack) présenté par le RFC 4213 consiste à doter un équipement du réseau de la pile protocolaire IPv6 en plus de celle d'IPv4 et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. L’utilisation paralèlle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux noeuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi les noeuds double pile sont capables de communiquer dans les deux versions du protocole IP.

La double pile a été proposée dès le début d'IPv6. Le plan originel de migration de l'Internet reposait d'ailleurs sur ce mécanisme comme le rappelle G. Huston [1] par la figure 1.

Figure 1: Plan de migration vers IPv6.

Cependant le problème de la pénurie d'adresses IPv4 n'est pas résolu avec ce mécanisme. Comme l'interface réseau d'un équipement en double-pile possède une adresse de chaque version IP. La croissance de l'internet continue d'épuiser l'espace d'adressage IPv4. Mais cela offre la possibilité de déployer des noeuds IPv6 afin de vérifier dans un premier temps la compatibilité de son réseau à ce nouveau protocole. Les problèmes inhérants à l'utilisation d'IPv6 peuvent donc être identifié très tôt. Ensuite dans un second temps, cela augmente la base des noeuds IPv6 installés. Au fur à mesure du déploiement de ces noeuds, les communications pourront se faire de plus en plus souvent en IPv6. En effet, le client en double pile utilisera en priorité IPv6 pour joindre un serveur lui-même en double pile. Le protocole IPv4 reste cantonné au cas ou la tentative échoue en IPv6 ou si le serveur est resté sur la vieille version d'IP. Enfin dans un dernier temps, quand la majorité des services est accessible en IPv6, la croissance de l’Internet aurait pu se poursuivre en IPv6 uniquement. Il devenait envisageable de se passer d'IPv4 et de ses NAT (Network Address Translation) comme la valeur de l'Internet était sur IPv6. Un cercle vertueux était enclénché. L'effort d'interopéarbilité aurait changé de camp rendant IPv4 encore plus complexe à utiliser par conséquent accélérant encore le passage à IPv6.

Malgré la disponibilité des équipements supportant le double pile, les acteurs de l'Internet tels que les FAI (Fournisseur d'accès à Internet), les hébergeurs et les administrateurs de sites n’ont pas perçu l’urgence d’integrer IPv6 dans leurs activités. Les doubles piles déployées sur les noeuds de l’Internet restent largement inutilisées par rapport au plan initial comme le montre la figure 2. Comme la croissance de l’Internet s’est poursuivie en IPv4. Celle-ci a été affectée avec plusieurs conséquences nefastes comme nous l'avons vu dans l'activité précédente. L'échec du plan initial est largement due à la dérégulation appliquée dans le secteur des télécommunications qui l'a rendu hautement compétitif. Cette dérégulation a conduit les acteurs à privilégier le court terme et les rend incapables de prendre en compte les besoins à plus long terme dans leurs activités [2] .

Figure 2: Etat du plan de migration initial.

Avec l'intégration d'IPv6 dans les principaux OS [3] et routeurs [4] et malgré l'attentisme d'une grande majorité des acteurs de l'Internet, de plus en plus d'infrastructures de communications, d’hébergeurs proposent leur service en IPv6. Certains FAI donnent maintenant une connectivité IPv6 à leurs clients et ceux qui n’ont pas cette chance peuvent se rabattre sur un accès IPv6 via des tunnels. Ces derniers sont souvent gratuits url. Les performances en IPv6 ont été fortement améliorées avec la multiplication des points de présence des FAI en IPv6. Un point de présence est un lieu géographique du FAI contenant un noeud de son réseau fédérateur autrement dit un point de connectivité pour son réseau de connexion de ses utilisateurs. De nos jours, comme un grand nombre d’applications (Mail, spam, supervision, Firewall...) intégre désormais IPv6 [5], il est beaucoup plus aisé de déployer IPv6 dans son réseau qu'il y a une dizaine d'années. Mais il vaut faire ce passage le tôt possible de manière à traiter progressivement et sereinement les inévitables bugs logiciels et erreurs de configuration qui surviendront. En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer, le réseau domestique de l'utilisateur résidentiel qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.

• Au sein d’un réseau domestique, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de nom et configuration d’adresse ainsi qu’aux performances perçues par l’utilisateur.
• Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage et la configuration du routage IPv6 en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ses services.

Pour ce qui est de l’administration des équipements réseaux en double pile, cela demande clairement un double travail de configuration. Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments non v6 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de coeur de réseaux supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire (cf. ISIS).

La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, les problématiques d’adressage et de configuration. Ensuite le deploiement des principales applications réseaux (DHCP, DNS, parefeu, supervision). Enfin, les problèmes induits par l’utilisation de la double pile et comment les contourner.

Obtenir un préfixe IPv6

Lorsque vous consultez les interfaces réseaux de votre machine, vous pouvez voir que des adresses IPv6 sont déjà alloués.

MacOSX 10.9.2

ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 14:10:9f:f0:60:46
    inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4
    inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: active

Linux 2.6.32 :

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 60:eb:69:9b:87:97  
          inet addr:195.154.87.139  Bcast:195.154.87.255  Mask:255.255.255.0
          inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5
          TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6583563265 (6.5 GB)  TX bytes:5944865545 (5.9 GB)
          Memory:feae0000-feb00000

Windows :

c:\> ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : 
IPv6 Address. . . . . . . . . . . :  2001:db8:21da:7:713e:a426:d167:37ab
Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54
Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6
IPv4 Address. . . . . . . . . . . : 157.60.14.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6
IPv4 Default Gateway  . . . . . . : 157.60.14.1
Tunnel adapter Local Area Connection* 6:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11
Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9
Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1
Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9
fe80::5efe:131.107.25.2%9
Tunnel adapter Local Area Connection* 7:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Ces adresses sont dites lien local [Séquence 1]. Elles sont utilisées pour le mécanisme de découverte de voisins [RFC4861] ainsi que pour la composition de l'identificateur pour l'auto-configuration avec DHCPv6. Elle ne sont valides que sur un lien et ne sont donc pas utilisables pour assurer une communication indirecte (passant par un routeur).

Pour le cas d'une communication indirecte, Il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable, au moins au sein d’un site. Il existe deux types d’adresses qui répondent à ce critère : les adresses unicast locales ULA [RFC4193] et les adresses globales GUA [RFC3587]. Pour rappel, les différences majeures entre ces deux types d’ adresses sont les suivantes :

• Portée: comme leur nom l’indique, les adresses GUA sont globales, une adresse GUA est utilisé par au plus une machine de l’internet à un instant donné. Les adresses ULA sont valide au sein d’un site.
• Routage: Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA doivent être filtrées par les routeurs en bordure de site. Les prefixes ULA ne doivent pas être annoncés ni accepté par les routeurs inter AS.
• Obtention: Les adresses ULA peuvent être générées de manière arbitraire par l’administrateur du site auquel impute la responsabilité de maintenir ces adresses uniques au sein du site. Dans le cas des GUA, le site fait la demande à son ISP un préfix unique dans l’internet. Notez qu’il est possible de demander un prefix independant des ISPs i.e. lorsque le site change d’ISP, il pourra garder son prefix; il pourra également être multi-domicilié.
• Gestion du plan d’adressage : Pour les ULA, le GID (40bits) est généré par l’administrateur pour créer un préfixe de 48bits. Pour les GUA le GID est fixé par l’ISP qui fournit généralement au client un préfixe de 48bit. Les SID (16 bits restant pour former des préfixes de 64 bits) sont gérés par l’administrateur pour la structuration de l’espace d’adressage interne.

Cas d’utilisation : ULA ou GUA ?

Il faut tout d’abord noter que même lorsque qu’un site obtient un prefix /48, il peut avoir 2^16 sous réseaux différents et 2^64 hôtes dans chacun de ces réseaux. Certains ISP délivrent à leur clients des adresses /64. Même dans ce cas, le nombre d’adresses administrables par l’utilisateur dépasse par plusieurs ordre de grandeur le nombre d’interfaces qu’il peut d’y avoir dans un réseau.

ULA pour gerer la carence d’adresse IP publique ? Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique obtenu n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.

ULA pour accroitre le niveau de sécurité ? L’utilisation des adresses privée dans IPv4 induits que les machines situées derrière un NAT sont plus difficilement accéssibles de l’exterieur. Cela la rend les attaques plus difficiles à réaliser. Cet effet de bord des adresses privées leur vaut la réputation d’être plus sécurisée que des adresses publiques. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquant de l’internet et qu’il faut donc maintenir l’utilisation d’adresse privée au sein des sites et chez les clients. En pratique, même avec une adresse privé, il faut malgré tout utiliser un pare feu pour prévenir les attaques, filtrer le trafic entrant et sortant, restreindre les applications utilisables par les utilisateurs (...). Un simple règle sur un pare feu peut interdire l’ouverture de connection depuis l’exterieur et donc fournir le même niveau de sécurité qu’un NAT.

ULA plus facile à deployer ? Pour utiliser des adresses ULA et fournir un accès internet à vos utilisateurs il vous faudra un NAT66 pour la translation d’adresses ULA en GUA. Cet équipement devra être acheté et maintenu par l’administrateur. De plus il vous faudra néanmoins demander une adresse publique ou un prefixe /48 à votre ISP. Un réseau basé sur les adresses ULA necessite donc plus de travail qu’un équivalent GUA.

Les seuls cas où l’utilisation des adresses ULA est réellement motivé sont les réseaux de tests (TPs, testbeds, déploiements prototype) et les réseaux necessitant un niveau de sécurité très élevé et dont les équipements n’ont pas à être connecté à l’internet (réseaux tactiques, hopitaux ...). Dans tous les autres cas, les adresses GUA sont plus faciles à deployer et à administrer.

Obtention de préfixes ULA

La première tache à effectuer par l’administrateur et de generer son prefix /48. Les 8 premiers bit servant à identifier le type d’adresse, seul 40bit sont spécifiques à ce site. Afin de mettre en évidence le fait que ces blocs d’adresse ne peuvent pas être aggregé et donc routé sur l’internet, les 40bits du GID sont générés aléatoirement. Notons qu’avec cet assignement aléatoire sur un espace aussi large, la probabilité que deux sites aient le même GID est quasi nulle. Cette propriété est particuliérement appreciable lorsque deux sites doivent fusionner.

La RFC 4193 suggère d’utiliser une fonction de hash (i.e.. SHA-1) du timestamp et de l’EUI-64 de la machine executant l’algorithme. Le script, sous licence libre GPL, développé par Hartmut Goebel, disponible à l'URL 3, peut vous générer une série de préfixes conforme en utilisant une des adresses MAC ethernet de votre poste de travail.

Obtention de préfixes GUA

Votre préfixe global peut vous être alloué par votre ISP, par un Local Internet Registery ou par un RIR. Il y a plusieurs cas à distinguer : si vous representez un organisme, on parlera d’assignement de site, si votre site est multidomicilié il vous faudra des prefix dits “provider independent” et enfin le cas où vous souhaitez obtenir un prefix pour votre usage personnel.

Internet Registery, des acteurs structurés : Pour rappel, les prefixes d’adresses IPv6 global unicast sont gérés par l’IANA qui délégue aux Regional Internet Registry (RIR). Les RIRs deleguent aux National Internet Registery (NIR) puis aux Local Internet Registery (LIR) et/ou aux ISP. En Europe, le RIR est le RIPE-NCC. Il delegue directement aux ISP/LIR sans passer par des NIR. Les LIR et certains ISP se voient déleguer des prefixes de longueur 32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des ISP. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des prefixes alloués par les LIRs aux ISPs.

Assignement de site : Les ISP/LIR font des assignements de site aux utilisateurs. Le bloc d’adresse associé est donc spécifique à un site et associe un organisme à un ISP qui assure les services suivant : l’ISP assigne le bloc d’adresse à l’organisme; assure un service de transit entre l’utilisateur et les autres sites; transporte le trafic de l’utilisateur et annonce un prefix BGP dans lequel est inclu celui de l’utlisateur. Les prefixes alloués sont au maxmimum sur 64 bits. Si un utilisateur souhaite avoir un prefix de moins de 48 bit pour son site, sa demande doit être motivée.

Multidomiciliation - Provider Independent prefix : Comme pour IPv4, si vous souhaitez que votre site soit multidomicilié ou si vous souhaitez changer d’ISP sans changer d’adresses, vous aurez besoin de prefix dits “Provider Independent”. La demande doit être faite directement à RIPE-NCC qui assignera un prefix /48 ou un prefix de longueur inferieur si la demande est motivée. Il faudra que votre organisation soit membre de RIPE ou que votre demande soit parainée par un ISP/LIR membre de RIPE. Il est ensuite necessaire que vos ISP annoncent et routent votre préfix.

Client d’un ISP : Si vous êtes client d’un ISP qui propose IPv6, vous recevrez par défaut un prefix sur 64bit. Votre routeur ADSL sera configuré avec cette adresse et c’est ensuite à vous de configurer vos autres équipements (e.g. routeurs WiFi ..) pour permettre la configuration des machines, via RADV ou DCHPv6. Si votre ISP ne propose pas IPv6, il vous faudra utiliser un service de tunnels. Certains d’entre eux (e.g. hurricane electric) vous proposent l’assignement gratuit de prefixes sur 48 bit lors de l’etablissement de votre tunnel.

Définition du plan d’adressage réseau avec IPv6

Une fois votre préfixe obtenu pour votre site, il vous reste sans doute de nombreux bits pour gerer vos sous réseaux. Si tel n’est pas le cas e.g. si vous avez un prefix /64, deux solutions s’offrent à vous :

• mettre en place un adressage privé avec un NAT66 pour faire la conversion. Cette solution vient avec le double inconvénient de necessiter un équipement supplémentaire et de rompre le principe de bout en bout.
• mettre en place des sous réseaux avec des prefixes de plus de 64 bits. La RFC7421 décrit les avantages et inconvenients de cette pratique. Il en ressort que même si les protocoles de routage et la pile protocolaire des hôtes supportent jusqu’à des prefixes de 128 bits, ce cas de figure n’est pas prévu par IPv6 qui indique clairement que le IID doit faire 64 bits. La RFC7368 considère même que le cas ou il n’y a pas suffisamment de bits pour l’adressage interne comme “une erreur”, le site devant à minima recevoir 16 bits pour le SID.

Si on fait l’hypothèse que le site s’est vu alloué un /48, le SID alors de 16 bits, ce qui est a priori suffisant pour structurer le routage interne. Plusieurs solutions s’offrent à nous :

• reproduire le schema IPv4 déjà déployé : Le bloc privée de classe A 10.0.0.0/8 offre 24 bit à l’administrateur pour la structuration des sous réseaux. En réalité, les plus petits sous réseaux ont rarement des prefixes >24, ce qui ne laisse que 16 bits pour la structuration. Dans la plupart des cas, il sera donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID.
• numéroter de manière incrémentale les sous réseaux (e.g. 0001,0002,0003…). Simple à mettre en oeuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agregation.
• utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’eviter de mémoriser plusieurs niveaux de numérotation.
• séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau suivant contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs :

Ainsi, le préfixe:

• 2001:DB8:1234::/52 servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs seront prises dans cet espace;
• 2001:DB8:1234:8000::/52 servira pour le réseau Wi-Fi des invités. La manière dont sont gérés les 12 bits restants du SID ne sont pas spécifiés;
• 2001:DB8:1234:E000::/52 servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.

Déploiement double pile

Une fois vos préfixes et votre connectivité double pile assurée pour votre réseau, il faut deployer les services qui lui seront indispensable e.g. la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématique liées au déploiement de ces services.

Configuration des adresses

Pour la configuration des interfaces réseaux, plusieurs méthodes s’offrent à vous. Pour rappel, avec la méthode SLAAC (StateLess Address Auto Configuration), l’interface génère elle même ses adresses. Cependant cette méthode peut présenter des inconvénients :

• Absence du DNS : la RFC définissant le protocole de decouverte de voisins ne prévoyait pas de champs pour renseigner le DNS. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via l’interface le DHCP de l’interface IPv4. Cela rend donc indispensable l’existence d’une telle interface. Notons toutefois que la RFC6106 prévoit l’ajout d’une option DNS dans les message RA.
• Il n’y a pas de contrôle sur les adresses utilisées par les interfaces et il n’y a pas moyen fiable d’enregistrer l’association machine / adresse IP.

Le Stateless DHCP [RFC3736] permet de contourner certains de ces problèmes. En effet, il utilise le méthode SLAAC pour définir les adresses et permet à l’hote de demander explicitement les informations manquantes à un serveur DHCP dit sans état.

Avec DHCPv6, le client obtient son adresse et ses informations aupres du serveur DHCP. Ce dernier peut donc controler les informations renseignées à chaque machine, controler les adresses assignées et mémoriser ces dernières.

Précaution lors du déploiement du DHCPv6 en double pile

Lors du déploiement de DHCPv6 en double pile, l’inconvenient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans la [RFC4477]. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème peut être d’autant plus prononcé si le réseau IPv6 et IPv4 n’ont pas les mêmes administrateurs.

Des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (e.g. /etc/resolv.conf) peuvent être effacées par le client DHCPv4.

Notons que lorsque DHCPv6 et SLAAC sont deployés simultanement sur le réseau, leur interaction peut également être problématique.

Résolution d’adresses

Dans IPv6, l’adresse IP est d’autant moins évidente à retenir ce qui renforce la necessité du DNS. Afin d’integrer le possibilité qu’une machine identifiée par son nom soit accèssible en IPv4 et en IPv6, la RFC3596 prévoit un nouveau type d’entrée dans les fichiers de zone. L’adresse IPv4 associée à un nom est toujours renseigné par le type “A” tandis que le nouveau type “AAAA” permet maintenant de renseigner l’adresse IPv6.

Les resolveurs DNS doivent être capable d’interpreter les deux types d’entrée. Lorsque les deux types sont retournés par le serveur, le resolveur doit influencer l’ordre des entrées retournées de manière à favoriser IPv6. Par ailleurs, le client doit pouvoir spécifier au resolveur s’il souhaite obtenir les entrées de type A ou AAAA.

Administration du réseau double pile

L’administration d’un réseau peut se décomposer en trois principales taches :

• La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.
• La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.
• La sécurité : assure l’integrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (firewall) et le chiffrement des informations qui transitent sur le réseau.

Les firewalls sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont generalement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.

La difficulté principale a été porté sur les outils de supervision. En effet, le protocole SImple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).

Evolution de SNMP vers IPv6 : Le protocole SNMP étant independant de la couche réseau L’évolution vers IPv6 du protocole SNMP n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, implementation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.

Evolution des MIBs vers IPv6 : A l’inverse, l’evolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champs IP a initialement été prévu sur 4 octets (RFC1902) ce qui ne permettait pas de representer les adresses IPv6 sur 16 octets. La RFC2465 a par la suite speficifié le champs IP sur 16 octets. Cette modification a eu des repercutions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendante pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.

Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.

Au niveau des applications

Quelque soit la version de protocole utilisée au niveau de l'application cela ne doit rien changer. Il faut cependant que l'application puisse exprimer l'adresse de son correspondant que ce soit en IPv4 ou en IPv6. Pour cela, les adresses doivent être codées sur 128 bits. Un type d'adresse IPv6 a été défini à cet usage à savoir comporter l'adresse IPv4 d'une communication IPv4. (IPv4 mapped IPv6 address) L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 3. Le format des adresses IPv4 imbriquées est ::FFFF:<ipv4 address> comme par exemple ::FFFF:1.2.3.4. Avec ce type d'adresse l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6. Le problème au niveau des applications est par conséquent que les applications utilisent le format d'adresse IPv6 pour leur communication. Car nous venons de le voir une application compatible IPv6 peut dialoguer indifférement en IPv4 et en IPv6. Alors qu'une application utilisant un format d'adresse IPv4 reste cantonné à ce protocole.

Figure 3: Adresse IPv4 imbriquée dans une adresse IPv6.

Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application s'est enregistrée via une socket IPv6 (famille de protocoles PF_INET6), les adresses IPv4 imbriquées source et destination sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement quand une application IPv6 émet des paquets avec une adresse IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.

L'exemple suivant illustre ce fonctionnement. Le client telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais bien sur les équipements IPv6 avec leur adresse IPv6.

>telnet rhadamanthe
Trying 2001:db8:1002:1:2b0:d0ff:fe5c:4aee...
Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.
Escape character is '^]'.
 
FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)
 
login:^D
>telnet bloodmoney
Trying ::ffff:193.52.74.211...
Connected to bloodmoney.rennes.enst-bretagne.fr.
Escape character is '^]'.
 
 
SunOS UNIX (bloodmoney)
 
login:

Précaution: Eviter le pbs pour les "eye balls"

Conclusion