Problèmes courants lors du déploiement de IPv6

Cette section décrit les problèmes que vous pouvez rencontrer lors du déploiement de IPv6 sur votre site. Pour toute question liée aux tâches de planification réelles, reportez-vous au Chapitre 4Planification d'un réseau IPv6 (tâches).

Impossible de mettre à niveau un routeur IPv4 vers IPv6

Si votre équipement ne peut pas être mis à niveau, vous devrez vous procurer un équipement compatible avec IPv6. Lisez attentivement la documentation du fabricant afin de connaître les procédures de prise en charge spécifiques à l'équipement.

Certains routeurs IPv4 ne peuvent pas être mis à niveau vers IPv6. Si votre topologie se trouve dans cette situation, raccordez un routeur IPv6 au routeur IPv4. Vous pourrez alors créer un tunnel sur le routeur IPv4 partant du routeur IPv6. Pour une description des tâches de configuration des tunnels, reportez-vous à la section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches).

Problèmes survenant après la mise à niveau de services vers IPv6

Vous pouvez rencontrer les problèmes suivants lors de la préparation des services au protocole IPv6 :

• Certaines applications préparées pour IPv6 ne prennent pas en charge IPv6 par défaut. Vous devez activer IPv6 sur ces applications pour que la prise en charge soit effective.

• Des problèmes peuvent survenir sur un serveur exécutant plusieurs types de services (certains ne prenant en charge qu'IPv4, d'autres prenant en charge IPv4 et IPv6). En effet, certains clients nécessitent l'utilisation de ces deux types de services, ce qui peut semer la confusion au niveau du serveur.

Le FAI actuel ne prend pas en charge IPv6

Si vous envisagez de déployer IPv6 sur votre réseau alors que votre FAI actuel ne prend pas en charge l'adressage IPv6, vous pouvez remplacer votre FAI actuel ou opter pour l'un des choix suivants :

• Louer un FAI fournissant au site une seconde ligne dédiée aux communications IPv6. Cette solution est onéreuse.

• Acquérir un FAI virtuel. Les FAI virtuels fournissent un accès IPv6 sans connexion physique. La connexion s'effectue de fait par le biais d'un tunnel reliant le FAI virtuel et le site à travers le FAI IPv4.

• Créer un tunnel 6to4 vers d'autres sites IPv6 à travers le FAI actuel. Configurez l'adresse IPv4 enregistrée du routeur 6to4 en tant qu'entité topologique publique de l'adresse IPv6.

Problèmes de sécurité lors de la création d'un tunnel vers un routeur relais 6to4

De par sa nature, un tunnel reliant un routeur 6to4 à un routeur relais 6to4 ne constitue pas une connexion sécurisée. Les problèmes de sécurité suivants sont inhérents à ce type de tunnel :

• Les routeurs relais 6to4 encapsulent et décapsulent des paquets, mais ne vérifient pas leur contenu.

• La mystification d'adresses est l'un des problèmes majeurs des tunnels sur routeurs relais 6to4. En effet, lorsque le routeur 6to4 reçoit des données du trafic entrant, il est incapable de faire correspondre l'adresse IPv4 du routeur relais et l'adresse IPv6 de la source. L'adresse de l'hôte IPv6 peut alors être facilement mystifiée. Il en va de même pour l'adresse du routeur relais 6to4.

• Par défaut, il n'existe aucun mécanisme de validation entre le routeur 6to4 et le routeur relais 6to4. Un routeur 6to4 ne peut donc pas déterminer si le routeur relais 6to4 est digne de confiance ou s'il est légitime. Une relation de confiance doit exister entre la source 6to4 et la destination IPv6 pour que ces deux sites ne s'exposent pas à d'éventuelles attaques.

Tous les problèmes de sécurité inhérents aux routeurs relais 6to4, y compris ceux cités précédemment, sont expliqués dans le brouillon Internet intitulé Security Considerations for 6to4. D'une manière générale, n'activez la prise en charge des routeurs relais 6to4 que dans l'un des cas suivants :

• Votre site 6to4 tente de communiquer avec un réseau IPv6 de confiance privé. Par exemple, activez la prise en charge du routeur relais 6to4 sur un réseau universitaire constitué de sites 6to4 isolés et de sites IPv6 natifs.

• Il est essentiel que votre site 6to4 communique avec certains hôtes IPv6 natifs.

• Vous avez implémenté les modèles de vérification et de validation suggérés dans le brouillon Internet intitulé Security Considerations for 6to4.

Problèmes connus du routeur 6to4

Les bogues suivants concernent la configuration 6to4 :

• 4709338 – Implémentation RIPng nécessaire à la reconnaissance des routes statiques

• 4152864 – Fonctionnement de la configuration de deux tunnels avec la même paire tsrc/tdst

Implémentation de routes statiques sur le site 6to4 (ID 4709338)

Le problème suivant se produit sur les sites 6to4 équipés de routeurs internes au routeur de bordure 6to4. Lors de la configuration de la pseudointerface 6to4, la route statique 2002::/16 est automatiquement ajoutée à la table de routage du routeur 6to4. Ce bogue (ID 4709338) indique que le protocole de routage Oracle Solaris RIPng empêche la publication de la route statique sur le site 6to4.

Deux opérations permettent de résoudre ce problème.

• L'une consiste à ajouter la route statique 2002::/16 aux tables de routage de tous les routeurs intrasites du site 6to4.

• L'autre consiste à utiliser un autre protocole de routage que RIPng sur le routeur interne au site 6to4.

Tunnels configurés avec la même adresse source (ID 4152864)

Ce bogue (ID 4152864) décrit les problèmes liés à la configuration de deux tunnels avec la même adresse source de tunnel qui peuvent gravement affecter la configuration des tunnels 6to4.

Vous ne devez pas configurer un tunnel 6to4 et un tunnel automatique (atun) avec la même adresse source de tunnel. Pour plus d'informations sur les tunnels automatiques et la commande atun, reportez-vous à la page de manuel tun(7M).