Ayant démarré ma carrière il y a déjà pas mal d’années au GIP RENATER à faire de la R&D sur IPv6 (et même multicast IPv6!) je dois dire que cela fait longtemps que je m’étais préparé à l’épuisement du stock d’adresses IPv4. Cette fois-ci ce n’est pas une énième fausse alerte ou une tentative de buzz d’un nouvel ayatollah d’IPv6… on arrive bien au bout du bout. Pour s’en convaincre il suffit d’aller faire un tour sur la page du RIPE NCC montrant en temps réel l’état du stock d’adresses IPv4. Pour ceux qui n’auraient pas voulu cliquer de peur de se rendre compte de la réalité, je rajoute ci-dessous le graphique à la date de rédaction de cet article pour être certain que la situation est bien intégrée.
Allons allons, tout cela n’est pas si grave! Après tout il ne s’agit que de la croissance de votre business! Ce n’est pas si grave de se couper de ses clients et de ses fournisseurs! Vous rajouterez une nouvelle couche de NAT, vous vous casserez encore la tête pour que vos applications restent fonctionnelles dans un contexte de translation d’IP et vous vous en sortirez… ou peut être à un moment vous réaliserez que le meilleur choix est d’adopter le standard IPv6 conçu il y a déjà 24 ans pour répondre à ce tarissement que tout le monde avait prévu.
J’ai l’énorme chance aujourd’hui de travailler dans une entreprise qui a compris de longue date l’importance du protocole IPv6, avec une volonté de délivrer depuis le sommet de la hiérarchie. Notre ancien CEO John Chambers avait annoncé il y a bien longtemps:
“If we don’t overcome the challenges of IPv4 we will slow down the growth of the Internet and lose momentum as an industry. IPv6 is important to all of us, to everyone around the world. It is crucial to our ability to tie together everyone and every device.”
Le patron a changé mais la volonté est toujours bien présente. Qui peut penser une seule seconde que l’adoption massif du cloud, l’utilisation de containers à tout-va, le développement de l’IoT, la multiplication des équipements mobiles… peut se faire sans augmenter le nombre d’IP? Les rachats d’adresses IPv4 des grands acteurs du net lors de ces dernières années montrent combien on ne peut espérer croître sans IP.
Avoir des adresses IPv6 est aisé et ne vous obligera pas à débourser plusieurs millions au marché noir (ou gris pour être politiquement correct). En revanche il faut encore être certain que le réseau est prêt. Il ne s’agit pas juste de pouvoir router/commuter des paquets IPv6, mais de supporter vos services, les gérer, offrir des fonctionnalité de sécurité, de segmentation… Tous les services IPv4 doivent pouvoir être fournis en IPv6 (à l’exception du NAT!) Un exemple marquant est sans doute IPv6 first hop security disponible sur les commutateurs d’accès et contrôleurs Wi-Fi: le commutateur d’accès a de multiples rôles à jouer pour empêcher qu’un client du réseau se fasse passer pour la passerelle par défaut, ou encore qu’il n’usurpe l’identité d’un tiers. Ces fonctionnalités sont depuis très longtemps présentes dans notre gamme d’accès comme je l’avais démontré dans ce blog en 2012! Comment peut-on croire encore que le réseau n’est qu’un tuyau quand n’importe qui peut compromettre tout un VLAN en envoyant un simple message RA (IPv6 Router Advertisement).
Evidemment nous ne nous sommes pas arrêtés au support de fonctionnalités. Ce sont nos architectures complètes qui supportent IPv6 comme par exemple SD-Access, l’IoT ou SD-WAN qui fera l’objet d’un prochain article. Sur SD-Access nous avons introduit le support en version 1.3 cet été et nous avons déjà un déploiement massif en cours en France. Automatisation, Visibilité et Segmentation, tout est disponible dans la version 6 du protocole de l’internet. Les gestes opérationnels pour IPv6 sont les mêmes que pour IPv4: il vous suffit de définir des pools d’adresses IPv6 et de les associer à des Virtual Networks de la fabric et le tour et joué. Je rappelle qu’Un Virtual Network est une structure logique de la fabric SD-Access qui permet de faire de la macro-segmentation: 2 clients de la fabric dans des virtual network différents ne peuvent pas communiquer entre eux. Sur un commutateur, un VN est d’ailleurs instancié par une VRF: la segmentation est une chose trop sérieuse pour être implémentée par quelques ACLs hasardeuses.
Pour vous permettre de mieux apprécier comment IPv6 est supporté, j’ai fait quelques tests dans mon lab que je documente ci-après. Je me suis contenté de rajouter un préfixe IPv6 à mon pool existant qui était uniquement IPv4, activant ainsi le réseau en dual-stack. Moins de cinq minutes m’ont permis de déployer IPv6 avec la sécurité associée.
Tout d’abord, j’ai défini mon pool global d’adresses IPv6 (préfixe dans lequel j’irai ensuite puiser mes ressources pour chaque site). J’ai utilisé des ULA dans mon lab et choisi le préfixe FC00:666:666::/48
Dans un second temps je viens simplement dériver de ce pool global un “sub-pool”, préfixe plus spécifique que je vais pouvoir associer à un segment de ma fabric. Ci-dessous on voit le subpool nommé ILM-Pool18 contenant à la fois un préfixe IPv4 et le préfixe IPv6.
Ci-après vous pouvez voir comment est défini ce subpool dual-stack, et comment une simple option permet d’activer SLAAC (Stateless Address Autoconfiguration). Vous constatez aussi comment il est simple de rajouter un serveur DHCPv6.
Un simple re-provisionning de la fabric permet ensuite en un click d’activer IPv6 sur le segment désiré. On voit bien ici la force de l’architecture SD-Access: les changements et l’ajout de services sont extrêmement aisés. Tout comme le déploiement du multicast se faisait déjà en quelques clicks comme dans vos rêves les plus fous, vous pouvez maintenant activer IPv6 en très peu de gestes opérationnels. Vous pouvez voir ci-dessous comment j’avais préalablement associé le subpool précédent à un VN.
Et ensuite? Les clients connectés sur ce segment (suite à authentification 802.1X, MAB ou bien assignement statique) reçoivent un préfixe IPv6 de la fabric et réalisent leur auto-configuration.
La communication devient immédiatement possible en IPv6 comme en IPv4 pour tous les clients du segment. Le tour est joué, IPv6 est déployé!
Mais on ne s’arrête pas là: une des forces de SD-Access est de pouvoir réaliser une micro-segmentation en se basant sur des groupes, les SGT – Scalable Group Tag. Chaque client connecté se voit placé dans un groupe en fonction des politiques définies sur le réseau. Les règles de segmentation dans la fabric ne sont pas définies pour des adresses IP mais pour les groupes de sécurité (SGT). Aussi votre déploiement IPv6 héritera nativement de toutes les règles de sécurité que vous aurez mises en oeuvre pour IPv4! Inutile donc de refaire pour IPv6 une nouvelle configuration, avec le risque au final d’avoir des incohérences fortes entre vos règles de sécurité pour les 2 protocoles.
Si par exemple j’active un filtrage entre les groupes “Developers” et “Marketing” via le DNA Center, je vais contrôler la connectivité entre ces 2 groupes (ici un filtrage simple) sur l’ensemble de la fabric (single- ou multi-sites) et ce sans me soucier des adresses IP utilisées (ni de la version du protocole IP!).
On voit ci-dessous l’impact immédiat de mon filtrage. Le client n’arrive plus à communiquer en IPv4 comme en IPv6 avec un autre client pourtant sur le même segment (dans le même préfixe). Vous avez défini votre sécurité sur des attributs logiques (ou business) et DNA Center a traduit cela en une implémentation logique et fonctionnelle. La promesse d’Intent-Based Networking est tenue, vous pouvez vous focaliser sur votre objectif, le système l’implémentera proprement pour vous!
Evidemment si vous n’êtes pas très familier avec SD-Access c’est peut-être allé un peu vite pour vous! Il va falloir rattraper le train en route car il va vite 🙂 Je pense au moins vous avoir convaincu que le support d’IPv6 sur nos solutions allait au-delà de pouvoir commuter une trame Ethernet contenant un paquet IPv6! Je ferai un webinar sur SD-Access dans les prochaines semaines. En attendant vous pouvez:
- Lire le livre SD-Access
- Regarder l’enregistrement d’un ancien webinar reseauxblog fait sur le sujet (même si les choses ont beaucoup changé depuis juillet 2017!)
- Vous inscrire au webinar du 19 novembre prochain à 11H consacré aux nouveautés de Cisco DNA Center.
N’hésitez pas non plus à commenter cet article, le relayer sur vos réseaux sociaux favoris. Il serait dommage de laisser vos peers dans le monde IPv4 qui appartient au passé!
Authors
