Retour d'expérience du déploiement d'IPv6 sur un réseau de campus

Introduction

Le réseau Osiris interconnecte les sites de 15 établissements membres de la communauté de l'enseignement supérieur et de la recherche des environs de Strasbourg. Il est opéré par le Département Infrastructure de la Direction Informatique (DI), service de l'Université de Strasbourg. Du fait de la variété des missions qui lui sont confiées, la DI gère à la fois un backbone interconnectant les réseaux utilisateurs, des services à portée globale comme le réseau sans fil, le DNS, le DHCP ou la messagerie, et même, pour certaines communautés d'utilisateurs, la DI gère des pare-feu, des commutateurs, et le câblage jusqu'à la prise réseau de l'utilisateur.

Nous nous attacherons à décrire la démarche, initiée au début des années 2000, qui a permis de diffuser IPv6 comme un protocole standard sur le réseau Osiris, aussi bien pour les serveurs et les services applicatifs que pour les clients. Cette démarche s'appuyant autant sur une dimension organisationnelle que sur une dimension technique, nous ferons part de notre retour d'expérience sur ces deux aspects.

1. Aspects organisationnels

1.1 Historique d'IPv6 sur le réseau Osiris

Le protocole IPv6 est proposé comme un service standard sur Osiris depuis plus de 10 ans. Une démarche volontariste de déploiement d'IPv6 avait été mise en œuvre très tôt, bien avant qu'IPv6 ne soit utilisé de façon significative comme protocole de transport par de grands acteurs de l'Internet : 9% des utilisateurs de Google y accèdent en IPv6 en septembre 2015.

Avant que la Direction Informatique ne soit créée en 2008, le réseau Osiris était géré pendant plus de 20 ans par une structure nommée CRC (Centre Réseau Communication). Entre 1996 et 2001, IPv6 était un service expérimental livré via un tunnel raccordé au défunt 6Bone. Ce service était d'abord opéré par une équipe de recherche en réseau puis par le CRC. C'est à partir de 2001 qu'IPv6 a été fourni en standard par RENATER via une interconnexion et un peering BGP entre le routeur RENATER et le routeur de bordure Osiris. Mais le service n'était pas pour autant disponible dans les réseaux utilisateurs.

Directeur du CRC depuis 2001, Pierre David a lancé un projet d'évolution des services Osiris, avec comme objectif une offre plus riche et une plus grande garantie de disponibilité, en s'appuyant sur une véritable industrialisation des services. Les aspects les plus innovants de ce projet passaient notamment par le développement d'IPv6, avec l'idée directrice d'offrir une connectivité et des services applicatifs à parité en IPv4 et en IPv6.

L'aspect organisationnel a été crucial. Plusieurs actions ont été entreprises pour faire globalement évoluer Osiris, et pour faire fonctionner IPv6 à l'échelle du campus :

- un renouvellement des équipements réseaux de cœur et de périphérie ;

- plusieurs recrutements de personnes avec de bonnes compétences en réseau et en système ;

- un plan de déploiement des services applicatifs en IPv6 ;

- un déploiement progressif de la connectivité IPv6 couplé à des formations préalables.

La connectivité IPv6 s'est étendue sur plusieurs réseaux utilisateurs entre 2002 et 2008 et un certain nombre de services a été proposé en IPv6 : SMTP, IMAP, DNS, etc.

1.2 Démarche de déploiement

L'établissement du plan d'adressage IPv6 OSIRIS [1] et la mise en œuvre d'IPv6 sur le backbone Osiris n'a pas présenté de difficulté particulière. Mais aucun utilisateur ne s'est manifesté pour demander un accès IPv6. Il a fallu trouver une stratégie plus directive. La démarche qui a permis de diffuser IPv6 sur Osiris s'est appuyée sur la formation de nos correspondants réseau (les personnes en charge des réseaux utilisateurs).

Plusieurs sessions de formation d'une journée ont été dispensées. Leur contenu couvrait le fonctionnement d'IPv6, et incluait une prise en main très concrète du protocole grâce à des TP. La formation soulignait les similitudes entre IPv4 et IPv6 et insistait sur le fait que l'activation d'IPv6 avait très peu d'impact sur les réseaux clients. À l'issue de chaque formation, le service était immédiatement mis en œuvre réseau par réseau, en plus d'IPv4, pour chaque correspondant formé. Au final, le service a été activé sur une trentaine de réseaux utilisateurs pour environ une centaine de correspondants (un grand nombre avait assisté à la formation, mais certains n'ont pas pu ou n'ont pas souhaité activer IPv6). Initialement, seule une formation de base existait, mais l'offre s'est étoffée dans les mois qui ont suivi par une formation avancée détaillant la mise en œuvre de services en IPv6.

De manière opportuniste, dès qu'un service pouvait fonctionner en IPv6, après l'avoir testé, il était déployé. Pendant longtemps, la disponibilité d'une implémentation du service en IPv6 était le principal facteur limitant. Les services Osiris suivants ont progressivement été V6-fiés :

- le DNS, à la fois pour le transport et pour les enregistrements DNS (Bind et Unbound) ;

- le relayage de messagerie (Sendmail et Postfix) ;

- l'hébergement de messagerie (Dovecot) ;

- le serveur FTP anonyme (Proftpd) ;

- quelques serveurs Web (Apache).

Les enseignements qu'on peut tirer de cette démarche sont que l'accompagnement, un prosélytisme acharné et le choix de la cible sont cruciaux. Certains correspondants ont été enthousiastes à l'idée d'utiliser un nouveau protocole et de contribuer à développer les usages d'IPv6, mais la plupart étaient réticents à ajouter de la complexité opérationnelle à leurs réseaux existants. IPv6 a été déployé partout où cela était possible sans créer de difficulté :

- les réseaux d'accès comme le wi-fi ;

- un certain nombre de réseaux d'enseignement et de recherche pour les correspondants volontaires ;

- certains réseaux de serveur hébergeant des services à portée globale.

Il n'a notamment pas été déployé sur :

- les réseaux des postes clients pour les applications administratives ;

- les réseaux des serveurs hébergeant les applications de gestion (finance, RH, scolarité, etc.).

1.3 Le projet IPv6 ADIRE

Fort de cette expérience du déploiement d'IPv6 sur le réseau Osiris, notre université a été sollicitée pour piloter le projet IPv6 ADIRE [2] en 2005. Ce projet, commandé par la direction de la recherche du ministère de l'enseignement supérieur et de la recherche avait pour but d'initier le déploiement d'IPv6 dans d'autres universités de France.

 

 

Parmi les livrables du projet, une « roadmap » a permis aux différents participants de déterminer leurs priorités quant aux actions de déploiement qu'ils avaient à effectuer :

- plan d'adressage ;

- routage ;

- filtrage ;

- DNS et publication des adresses ;

- autres services (messagerie, web) ;

- réseaux IPv6 only, via un proxy IPv4/IPv6 ;

- métrologie et monitoring.

Cette roadmap reste largement pertinente aujourd'hui pour mesurer la maturité du déploiement. Cependant, certaines options plus avancées ne sont pas utilisées aujourd'hui (mobilité, multicast).

Sur les 11 universités sélectionnées, le déploiement a été effectué avec un niveau de service très variable en fonction des sites. Le projet a montré qu'il y avait des réelles difficultés à pousser pour la V6-fication des réseaux de campus, les principaux obstacles étant le manque de ressources humaines et l'absence de demande utilisateur.

2. Aspects techniques

2.1 Équipements réseau

Nous n'avons pas rencontré récemment de problèmes particuliers avec IPv6 sur les équipements réseau de cœur. La difficulté se situe parfois au niveau de l'interconnexion avec le réseau utilisateur. Tous les firewalls ne supportent pas IPv6. Pour certains firewalls commerciaux, le support est partiel avec la seule possibilité d'écrire des règles sans états, ou bien le filtrage IPv6 fonctionne, mais pas en mode bridge. Ces aspects évoluent plus ou moins rapidement en fonction des constructeurs. Cependant, nous avons une très bonne expérience avec des firewalls basés sur des OS libres comme Linux, FreeBSD et OpenBSD, qui sont utilisés en production depuis plusieurs années et qui offrent un support très complet du filtrage IPv6. Un autre aspect qui avait été envisagé très tôt et qui manque toujours cruellement est la métrologie. Aucun de nos équipements réseau n'est supervisé en SNMP sur un transport IPv6 à ce jour.

2.2 Clients

2.2.1 Autoconfiguration avec SLAAC

La majorité des systèmes d'exploitation client ont un support correct d'IPv6, que ce soit Linux, Mac ou Windows. Nous avions fait le choix de l’autoconfiguration basée sur SLAAC [3] au départ. Ce choix a été fait au début des années 2000, à un moment où aucun autre protocole n'avait été implémenté avec suffisamment de maturité. Le choix n'a pas été remis en question depuis, même si à plusieurs reprises, nous nous sommes interrogés sur l'opportunité de changer pour DHCPv6.

Pourquoi utilisons-nous encore SLAAC 15 ans après ? SLAAC a d'énormes avantages : sa simplicité et sa compatibilité avec presque tous les systèmes d'exploitation. Il est sans état : aucun serveur central ne doit maintenir les états de configuration des clients. Une fois que SLAAC a annoncé un préfixe IPv6 dans un Router Advertisement, le poste client configure son adresse IPv6 tout seul à partir de son adresse MAC. De plus, SLAAC offre une grande flexibilité au niveau opérationnel :

- il permet de faire changer sa route par défaut au client, il suffit par exemple qu'un routeur de backup se mette à envoyer des RA ;

- il permet de changer les adresses de tous les postes en annonçant un nouveau préfixe et en rendant obsolète le préfixe actuel.

2.2.2 Autoconfiguration du DNS

Il nous a semblé qu'il y avait toujours eu une limitation dans SLAAC : il ne fournissait pas en standard de mécanisme pour que le client connaisse l'adresse du serveur de nom en IPv4. En apparence, SLAAC est une solution incomplète pour pouvoir faire fonctionner un poste en IPv6 uniquement. Certains mécanismes ont été développés par la suite, entre 2003 et 2007, pour adresser ce manque :

- RDNSS : l'annonce du serveur de nom dans les Router-Advertisement [4] n'est pas supportée par tous les clients et proposée par peu de constructeurs d'équipements réseaux [5] ;

- les Router-Advertisement peuvent indiquer qu'il faut utiliser DHCPv6 uniquement pour récupérer le DNS.

Nous n'avons déployé aucun de ces mécanismes en production.

En réalité, c'est un problème théorique. Sur la plupart des réseaux de campus, l'obtention de l'adresse IPv6 du DNS est inutile. Les ordinateurs sont en double pile IPv4 et IPv6, et IPv4 est encore là pour longtemps. Il suffit d'accepter pour l'instant que les postes client fassent des résolutions DNS qui seront transportées sur IPv4.

2.2.3 Les adresses temporaires

Un certain nombre de systèmes d'exploitation activent par défaut l’autoconfiguration d'adresses temporaires [6], parfois aussi appelées adresses anonymes, pour protéger la vie privée des utilisateurs. Chaque appareil va avoir de nouvelles adresses IPv6 construites à partir du préfixe annoncé via les RA de SLAAC, mais ces adresses sont opaques (générées aléatoirement et donc non liées à l'adresse MAC ou à un élément permettant d'identifier la machine) et ont une durée de vie limitée. Une adresse temporaire est obsolète au bout de quelques heures (elle n'est plus préférée pour de nouvelles connexions TCP), mais elle maintenue tant qu'une connexion TCP établie l'utilise. La difficulté pratique que représentent les adresses IPv6 temporaires pour l'exploitant du réseau est que chaque ordinateur ou téléphone va utiliser plusieurs adresses IPv6 au quotidien.

La jurisprudence semble indiquer que les entreprises et les administrations peuvent être assimilées à des fournisseurs d'accès internet et à ce titre, sont astreintes à l'obligation légale de conservation des données de connexion pendant un certain temps.

Maintenir un lien entre toutes les adresses temporaires et l'ordinateur qui les utilisent a un coût. Cela est possible avec un outil comme NDPMon [7], mais le placement du serveur faisant tourner cet outil est contraint : il doit pouvoir capturer les paquets de Neighbour Discovery sur plusieurs réseaux. Ceci peut être réalisé avec du port-mirroring à des endroits stratégiques d'un grand réseau niveau 2. D'autres approches consistent à faire des collectes régulières des tables de Neighbour Discovery en SNMP ou encore à avoir des sondes Netflow avec un format étendu liant l'adresse MAC et d'autres informations à l'adresse IPv6. C'est le système qu'utilise l'université de Brno en République tchèque [8].

Le problème d'identification d'une machine en IPv6 ne s'est pas encore présenté : à ce jour, toutes les réquisitions judiciaires que nous avons reçues ne portaient que sur des adresses IPv4. Mais cela peut changer rapidement.

2.2.4 Autoconfiguration avec DHCPv6

Il y a deux façons d'utiliser DHCPv6 :

- comme DHCPv4, pour attribuer des adresses (mode dit « Managed configuration ») ;

- en complément de SLAAC pour récupérer par exemple l'adresse du DNS (mode « Other Configuration »).

Dans les deux cas, SLAAC est utilisé pour permettre à DHCPv6 de fonctionner.

Certains administrateurs de réseau d'entreprise considèrent que la première façon de faire, attribuer une adresse avec DHCPv6, est préférable à l’autoconfiguration autonome des adresses via SLAAC. Le fait que SLAAC soit sans état pose problème : en effet, dans certains réseaux, une traçabilité stricte des postes clients est exigée. Pour garantir cela, en plus de DHCPv6, il faut recourir à d'autres mesures :

- interdire la configuration manuelle d'adresse ;

- désactiver l’autoconfiguration d'adresses temporaires sur les postes clients ;

- faire en sorte que les commutateurs réseaux intermédiaires fassent respecter automatiquement l'attribution des adresses par DHCPv6 avec un mécanisme similaire au DHCP Shield ou DHCP snooping en IPv4 (la fonction DHCPv6 Shield est disponible sur peu de commutateurs à l'heure actuelle).

2.2.5 Retours d'expérience de l’autoconfiguration

L'expérience opérationnelle de plusieurs sites atteste que SLAAC fonctionne bien. Quelque cas de réseaux de campus qui ont tenté d'utiliser DHCPv6 montrent qu'il peut engendrer des difficultés d'exploitation.

Par exemple, la DSI de l'université Paris I Panthéon-Sorbonne, en cessant d'utiliser DHCPv6, a simplifié plusieurs aspects de l'exploitation de son réseau, et notamment le nommage dynamique des machines dans le DNS, y compris pour effectuer des résolutions inverses [10].

La décision de ne pas faire de DHCPv6 a été prise par les administrateurs du réseau de campus de l'université de Brno en République tchèque, Matej Gregr et Tomáš Podermański. Ils constatent plusieurs problèmes.

SLAAC est autonome : il ne dépend que du bon fonctionnement du routeur qui émet les Router Advertisement (RA) avec un préfixe IPv6. DHCPv6 quant à lui nécessite à la fois :

- que le routeur émette des RA indiquant que les postes clients doivent utiliser DHCPv6 ;

- qu'un serveur DHCPv6 fonctionne (et, à l'échelle d'un campus, sans doute sur un autre composant matériel que le routeur qui émet les RA).

Cela signifie qu'il faut faire fonctionner deux protocoles en même temps pour qu'un client obtienne une adresse IPv6. Cela augmente vraisemblablement le coût et la complexité d'exploitation.

Une autre raison pour laquelle DHCPv6 n'est pas recommandé est l'absence de support de ce protocole sur les téléphones et les tablettes Android. Il y a eu un long débat sur la liste de diffusion NANOG [11] et un bug est ouvert chez Google [12], mais il n'y a pas de solution pour le moment. Lorenzo Colitti, développeur chez Google refuse de l'implémenter sur Android. Son raisonnement est le suivant : dans le cas du tethering IPv6, les équipements situés derrière l'appareil qui partage la connexion seront obligés de faire du NAT en IPv6 (ou du 464XLAT), ce qui n'est pas implémenté actuellement sur Android et qui risque d'engendrer des dysfonctionnements.

L'exploitation de DHCPv6 est différente de DHCPv4 parce qu'il utilise un identifiant persistant, DUID [13] (dont il existe plusieurs types), là où DHCPv4 utilisait simplement l'adresse MAC. Cela complique la traçabilité des ordinateurs.

Il est possible de combiner SLAAC et DHCPv6 : un préfixe annoncé dans un Router-Advertisement est accompagné d'un autre flag, « A » (pour « Autonomous ») [14][15]. En mode « Managed », il suffit d'annoncer en plus un préfixe IPv6 avec un flag « A » à 1 et la plupart des clients [16]auront une adresse issue de SLAAC en plus d'une adresse configurée par DHCPv6 conformément aux spécifications.

Cela règle le pseudo-problème de l'obtention du DNS en IPv6 et les éventuels problèmes de compatibilité. Cette approche présente d'autres risques : chaque équipement connecté au réseau n'aura pas moins de 4 adresses IPv6 à un instant donné: 1 adresse SLAAC, 1 adresse DHCPv6, et plusieurs adresses temporaires sur des grands réseaux de campus (notre réseau sans fil a en pic 9000 clients simultanés), il faudra veiller à dimensionner correctement la CAM des routeurs.

2.2.6 Sécurité de l'autoconfiguration

Les principales mesures de sécurité appliquées aux sous-réseaux où IPv6 est activé protègent contre des attaques accidentelles. L'incident le plus fréquent est une machine qui, suite à une erreur de configuration, annonce un préfixe IPv6. Dans ce cas, tous les autres ordinateurs du sous-réseau vont utiliser le préfixe, et parfois même router les paquets Ipv- vers cette machine. La perception utilisateur est que la connectivité vers certains sites (dont Google) ne fonctionne plus.

Il existe des moyens de filtrer ces annonces indues directement sur les commutateurs Ethernet. Mais le support de fonctions de sécurité IPv6 sur la plupart des commutateurs est très limité. En fonction des constructeurs, il nécessite souvent l'acquisition de modèles de commutateurs plus évolués et plus chers, et l'installation de versions de logiciel réseau relativement récentes.

Ce type d'incident se produisait le plus souvent sur le réseau sans-fil. En effet, une grande quantité de machines non administrées s'y connectant, l'erreur de configuration était fréquente (y compris pour IPv4 où certains postes se comportaient comme des serveurs DHCP, avec des conséquences encore plus importantes). La solution déployée a réglé globalement le problème : au niveau Ethernet, toutes les communications entre les clients étaient filtrées et seule la communication vers la passerelle était autorisée. Ce dispositif était implémenté par des ACL au niveau MAC sur les points d'accès. Suite à la refonte de l'architecture du réseau sans fil, l'infrastructure est basée aujourd'hui sur un contrôleur centralisé. Le principe de filtrage entre les clients a également été appliqué. C'est le contrôleur qui implémente cette fonction (sur les contrôleurs Cisco, l'option se nomme « Peer-to-Peer Blocking »).

2.3 Serveurs et services

2.3.1 Les différentes phases de déploiement d'un service

Pour tous nos services v6-fié, les serveurs ont une double pile IPv4 et IPv6. Le principal problème sur les services n'est pas d'avoir une adresse IPv6 sur le serveur ou une entrée AAAA dans le DNS, mais bien de garantir que l'application fonctionne en IPv6. Aussi, l'activation d'un service en IPv6 nécessite de suivre une démarche structurée [17] :

- préparation : définir les services qui seront v6-fiés ;

- bien prendre connaissance du protocole et faire des maquettes pour évaluer le fonctionnement en IPv6 ;

- activer IPv6 sur le réseau des serveurs cibles, mais sans autoconfiguration d'adresse IPv6 (il est recommandé de désactiver aussi l’autoconfiguration sur les serveurs) ;

- mettre au point le plan d'adressage des serveurs (cela peut être une règle simple : le dernier octet de l'adresse IPv4 du serveur dans le réseau /24 -> dernier octet de l'adresse IPv6, mais c'est sans doute une mauvaise idée pour des masques de sous réseau qui ne sont pas à la frontière d'un octet) ;

- commencer à superviser l'adresse IPv6 du service ;

- mettre en place le service v6-fié en préproduction et le tester ;

- activer le service en production et vérifier notamment que la politique de filtrage pour le service en IPv6 est cohérente ;

- publier le service dans le DNS : ajouter un enregistrement AAAA avec l'adresse IPv6 du service.

2.3.2 V6-fication de la messagerie

La mise en œuvre d'IPv6 sur nos relayeurs de messagerie (d'abord Sendmail, puis Postfix) s'est faite sans difficulté. Le principal problème rencontré a été un problème d'exploitation : des MTA d'autres sites tournant sous Postfix et n'ayant pas réellement de connectivité IPv6 (uniquement des adresses lien-local) n'arrivaient plus à nous envoyer des mails en SMTP. En effet, Postfix est configuré par défaut pour envoyer des mails en IPv6 (directive inet_protocols=all). Mais en raison d'un comportement [19] contraire à la RFC 3493, la résolution de nom se fait pour des enregistrements AAAA alors même qu'il n'y a pas d'adresse IPv6 globale. Le MTA distant initie une connexion vers l'adresse IPv6 de notre MTA et cette connexion, très logiquement, échoue. Le nombre de tickets d'incident concernant ce type de problème s'élevait à 2 par mois. Nous avons pris la décision de dégrader le service en n'annonçant des adresses IPv6 uniquement en backup : les enregistrements MX les plus prioritaires sont uniquement en IPv4. Bien évidemment, nous tenterons à moyen terme de republier nos relais de messagerie avec la même priorité à la fois en IPv4 et en IPv6.

Concernant la plateforme d'hébergement de messagerie, le support d'IPv6 a fonctionné pendant de longues années sur les serveurs IMAP et POP Dovecot, ainsi que sur le webmail (Horde puis SOGo). Mais le coût d'exploitation de la double-pile est devenu plus important, et le contexte a changé. Suite à la fusion des universités et à la réorganisation des équipes, la poursuite du déploiement d'IPv6 est devenue moins prioritaire. Par exemple, la nouvelle plateforme de messagerie, en production depuis mi-2015, basée sur Cyrus et le module mail de Nginx n'ont pas encore été V6-fiés, même si là aussi cela ne présente pas de difficulté majeure.

2.3.3 V6-fication d'autres services

La plupart des services V6-fiés sont une survivance de l'époque où la volonté de déployer IPv6 était plus ferme qu'aujourd'hui. Il y a notamment les DNS, des serveurs LDAP, et des serveurs web.

Le cas de notre plateforme d'hébergement web actuelle, qui héberge le site de l'université est intéressant et représentatif : elle ne supporte officiellement que des accès en IPv4. Les raisons sont à chercher dans la diversité des éléments qui la composent (load-balancer OpenBSD basé sur relayd, containerx LXC, etc.) et dans le fait que certains éléments n'étaient pas compatibles au moment de la conception de la plateforme. Actuellement, la tendance est de regrouper l'ensemble des applications web derrière des frontaux Nginx. C'est dans doute le meilleur moyen de mutualiser cet effort de V6-fication. Il est donc important de prendre en compte la V6-fication au moment de la définition de l'architecture des plateformes. Et il ne faut pas oublier que la v6-fication d'une application peut consister simplement à la mise en place d'un proxy.

Techniquement, la V6-fication d'un service est en général l'affaire d'une ou deux lignes de configuration, voire rien si IPv6 est activé par défaut. Voici quelques exemples de configuration :

DNS Bind (named.conf) :

DNS Unbound (unbound.conf) :

Serveur Web Apache : 

Serveur LDAP OpenLDAP :

Il peut être intéressant de vérifier au niveau du système que le service est vraiment à l'écoute en IPv6. Mais il faut faire attention à l'implémentation. En effet, il y a deux possibilités [20] pour un service d'être à l'écoute en double-pile :

- le serveur écoute sur un socket IPv4 et sur un socket IPv6 ;

- le serveur sur un socket IPv6 et pour IPv4 des adresses IPv6 de type IPv4-mapped sont utilisées.

Sur BSD, en général, c'est le premier cas. Par contre, sur la plupart des distributions Linux, sauf configuration explicite, c'est en général le deuxième cas qui est utilisé. Par exemple, si on lance apache et on liste le socket :

seul un socket IPv6 est affiché et pourtant le service est également accessible en IPv4.

Pour connaître la compatibilité IPv6 des applications, il existe des sites qui les recensent, comme DeepSpace6 [21].

2.3.4 Dispositifs de filtrage

Nous utilisons essentiellement PF sous OpenBSD, en général sous forme de firewall ou de load-balancer redondés avec CARP, et PFSYNC pour la synchronisation des états. La politique de filtrage à appliquer doit suivre la même logique qu'IPv4 : « tout est interdit sauf... ». Il faut être vigilant au traitement de certaines extensions de l'en-tête du paquet IPv6. Par exemple, il est envisageable de bloquer les paquets fragmentés. Mais il ne faut surtout pas empêcher le fonctionnement normal d'IPv6 sur le réseau. Par rapport à IPv4, l'ensemble de la signalisation se fait dans ICMPv6.

À titre d'illustration, voici un jeu de filtre raisonnable pour un réseau de serveur [17] qui autorise la découverte des voisins, le Path MTU discovery, le ping, le traceroute, etc. :

Il faut bien sûr ajouter les règles autorisant l'accès au service. Par exemple, pour un serveur web :

Conclusion

Le trafic IPv6 sur OSIRIS reste faible proportionnellement au trafic IPv4, mais les usages augmentent lentement : de 10 Mb/s en moyenne il y a 4 ans, le trafic moyen est à environ 20 Mb/s actuellement avec des pics très importants. Le déploiement d'IPv6 sur un réseau de campus est une aventure qui n'a sans doute pas de fin. La gestion de la double-pile engendre des coûts d'exploitation supplémentaires manifestes. Il faut reconnaître qu'IPv6 est un objet technique complexe, mouvant et pas tout à fait fonctionnel dans certaines situations. Malgré tout cela, la volonté de proposer de service en IPv6 n'a jamais complètement disparu et le renouvellement de nos infrastructures réseau dans les mois qui viennent devrait donner un souffle nouveau à cet effort.

 

 

Références et liens

[1] « Plan d'adressage IPv6 OSIRIS », https://di.u-strasbg.fr/pub/doc_ipv6_plan_adressage

[2] « LeProjet IPv6-Adire –Infrastructure IPv6 et Mobilité »,Pierre David, Thomas Noël, Guillaume Schreiner, Jean-Paul Le Guigner,Actes du Congrès JRES, décembre 2005, Marseille, http://2005.jres.org/paper/128.pdf

[3] « RFC4682 : IPv6 Stateless Address Autoconfiguration », https://tools.ietf.org/html/rfc4862

[4] « RFC6106 :IPv6 Router Advertisement Options for DNS Configuration », https://tools.ietf.org/html/rfc6106

[5] « Comparison of IPv6 support in operating systems », https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

[6] « RFC4941 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 », https://tools.ietf.org/html/rfc4941

[7] « NDPMon », http://ndpmon.sourceforge.net/

[8] « Flow Based Monitoring of IPv6», GEANT GN3 Project NA3/T4 « Campus Best Practice », Campus Network Monitoring Workshop, 24-25 avril 2012, Brno, République Tchèque, http://archiv.ces.net/events/2012/campus-monitoring/p/podermanski-flow-ipv6.pdf

[9] « [RFC 4861 : ,Neighbor Discovery for IP version 6 (IPv6), section 4.2 : Router Advertisement Message Format », https://tools.ietf.org/html/rfc4861#section-4.2

[10] « Solution transitoire de mise à jour dynamique des adresses IPv4 et IPv6 dans le DNS », Nicolas CUISSARD, Université Paris I Panthéon-Sorbonne, Actes du Congrès JRES 2013, https://2013.jres.org/archives/27/paper27_article.pdf

[11] « Android (lack of) support for DHCPv6 », Liste de diffusion NANOG (North-American Network Operator Group), juin 2015, http://mailman.nanog.org/pipermail/nanog/2015-June/075915.html

[12] « Issue 32621: Support for DHCPv6 (RFC 3315) », https://code.google.com/p/android/issues/detail?id=32621

[13] « RFC3315:Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Section 9, DHCP Unique Identifier (DUID) », https://tools.ietf.org/html/rfc3315#section-9

[14] « RFC4861 : Neighbor Discovery for IP version 6 (IPv6), section 4.6.2, Prefix Information », https://tools.ietf.org/html/rfc4861#section-4.6.2

[15] « RFC4862 : IPv6 Stateless Address Autoconfiguration, Section 5.5.3, Router Advertisement Processing », https://tools.ietf.org/html/rfc4862#section-5.5.3

[16] « DHCPv6/SLAAC Address Configuration Interaction Problem Statement, Appendix A.2: Host Behavior in the Initial State », V6OPS Draft, octobre 2014, https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-02#appendix-A.2

[17] « Déployer des services en IPv6 », Jean BENOIT, Simon MUYAL, Christophe PALANCHÉ, Projet RENATER/GEANT Campus Best Practice, Novembre 2013,https://www.renater.fr/IMG/pdf/Deployer_des_services_en_IPv6_v271113.pdf

[18] « Bug 12377 - getaddrinfo() with AI_ADDRCONFIG won't suppress AAAA DNS queries when only IPv6 loopback and link-local addresses are present », https://sourceware.org/bugzilla/show_bug.cgi?id=12377

[19] « RFC3493 : Basic Socket Interface Extensions for IPv6 », https://tools.ietf.org/html/rfc3493

[20] « Introduction to IPv6 Programming », Rino Nucara, EuChinaGrid IPv6 Tutorial, janvier 2008, https://twiki.cern.ch/twiki/bin/viewfile/EGEE/IPv6FollowUp?rev=1;filename=Introduction_to_IPv6_programming_C_Java_PHP_perl.pdf

[21] « Current Status of IPv6 Support for Networking Applications », DeepSpace6, http://www.deepspace6.net/docs/ipv6_status_page_apps.html