Guide « Entreprises : comment déployer IPv6 »
Crée pour la Task-Force IPv6 Arcep


« Nous sommes en 2022, il a finalement dépassé 50% des accès en ligne à l’échelle du pays l’hiver précédent, ce protocole aux longues adresses qui rebutent. Il envahit petit à petit toutes les strates du pays, sur mobile comme sur fixe. Toutes ? Non ! Une catégorie d’irréductibles adeptes de Legacy IP résiste encore et toujours à l’hexadécimal. Et la vie n’est pas facile pour les légions de paquets IPv4 qui traversent les chantres du partage d’IP entre abonnés que représentent 4rd, MAP-T/E et autres technologies d’IPv4aaS. »

Voici peut-être l’introduction d’un futur album d’une célèbre BD expliquant pourquoi IPv4 n’est plus natif chez la plupart des opérateurs mais offert comme un service encapsulé sur un réseau IPv6 natif, BD qu’on pourrait d’ailleurs titrer les 12 travaux d’ipévessix.



Plutôt qu’une BD c’est finalement un guide que propose la taskforce IPv6 ARCEP afin d’aider les entreprises à migrer différentes parties de leur système d’information après avoir établi leur stratégie.

Guide « Entreprises : comment déployer IPv6 » : (cliquez sur les miniatures ci-dessous - les documents sont au format PDF)
   

Car à contrario des acteurs majeurs d’internet, IPv6 est encore relativement peu présent sur les bordures de systèmes d’information d’entreprise que sont leur site-web, leur messagerie ou des services plus privés comme l’accès au VPN corporatif ou le proxy permettant aux salariés de naviguer sur internet. Mais derrière ces quelques exemples de services, ce sont des pans entiers du système que l’on tire. Par exemple le filtrage, l’outillage de configuration, la collecte des logs, autant de briques où l’enchaînement du déploiement est à établir minutieusement. Il est difficile de trouver sujet plus vaste tant la verticalité d’un SI d’entreprise et l’unicité des applicatifs qu’on y trouve demandent du temps pour parvenir à une transition effective. Ce qui est certain c’est qu’il ne faut plus reculer.

IPv4 devient une ressource tellement rare que certains commencent déjà à la facturer en sus des services tels que l’hébergement. Pratique qui va probablement se répandre. Les modifications de trafic IPv4 deviennent légion et vont progressivement rendre IPv4 moins efficace qu’IPv6 sur internet pour toutes les connections initiés par particuliers, clients comme télétravailleurs. Modifications guidées par la rareté de la ressource et le besoin de partage d’IP publiques, qu’on regroupe sous les appellations Approche Adresse + Port (A+P) ou encore IPv4aaS. Arrêtons-nous sur ce dernier terme, il indique bien que l’industrie de transport IP considère qu’IPv4 n’est plus la fondation obligatoire mais devient un simple service offert au-dessus du nouvel IP. Service qui finira bien par voir sa présence disparaître. D’autres pourront également saisir l’opportunité au-delà de la question d’internet, notamment les grandes structures qui sont arrivées au terme de l’adressage privé IPv4 RFC 1918 en interne et pratiquent aujourd’hui du recouvrement (overlap) d’adresses. Là aussi, le guide vous apportera des réponses et vous permettra d’établir vos orientations. Il contient également des préconisations de sécurisation, des pratiques pour se simplifier la gestion de l’adressage, et bien d’autres choses encore.

Ce guide a vocation à évoluer, alors n’hésitez pas à poser des questions, à suggérer des modifications et ajouts, et surtout rejoignez la taskforce IPv6 ARCEP afin que nous puissions partager ensemble sur les défis de cette grande traversée vers ce nouveau paradigme.

La 4 avril 2022 avait lieu à Paris la conférence MPLS "IPv6 Enhanced: Boosting the Digital Economy" où j'ai présenté ce guide :

J'ai pris le soin de tout lire. C'est un sacré travail!

J’envisageai de mon côté de faire un tuto à usage du particulier pour partager mon expérience de plusieurs années de déploiement à domicile. J'ai trouvé pas mal de choses utiles dans les 125 pages mais je pense qu'il rate une partie de sa cible selon moi car il est trop tourné vers les grosse structures.

Peut-être qu'une version PME moins complète pourrait être envisagée, plus centrée sur le parc bureautique. Il serait adapté aux structures qui n'hébergent pas eux-même leurs sites internet et pourrait aborder plus profondément les problématiques liées au recours massif aux SAAS comme Office365. Le genre de structures où le service informatique repose sur une seule personne.

Si vous souhaitez faire une version pour la maison, je suis partant pour participer.
J'ai pas mal galéré pour trouver des informations pour pas mal de produits ou outils pas encore adaptés à IPv6 dans le cadre de mon réseau personnel et j'ai pas mal de bonnes recettes pour le particulier.

Comme mentionné dans le guide, l'utilisation de préfixes aléatoires avec des adresses ULA est problématique et j'ai contourné le problème en séparant le trafic local ULA du trafic global avec des VLAN. Les VLAN m'ont apporté quelques problèmes sous windows alors que c'est du velours ou presque sous linux.

Mon NAS Synology m'a donné pas mal de sueurs froides bien que c'est grâce à lui que j'ai trouvé comment configurer samba en IPv6 only.

...
Comme mentionné dans le guide, l'utilisation de préfixes aléatoires avec des adresses ULA est problématique et j'ai contourné le problème en séparant le trafic local ULA du trafic global avec des VLAN. Les VLAN m'ont apporté quelques problèmes sous windows alors que c'est du velours ou presque sous linux.
...

Bonjour Wanou et bonne année, merci pour le retour, ils sont rares et précieux. 

Je suis plutôt orienté grande structure et je ne me suis pas trop penché sur les cas de petites et PME effectivement.
Je conseille juste de faire du NPTv6 avec un préfixe ULA aléatoirement défini si on est trop petit pour avoir un bloc RIPE en PI.

Une toute petite structure avec quelques PC, un copieur, un NAS peut tourner avec le préfixe opérateur dynamique. Dans le LAN les services vont s'annoncer en mDNS et on ne paramètre rien sur les IP. On subit un flash renumbering en cas de changement de préfixe FAI mais c'est très rapide si les timers sont bons.

Dès qu'on veut des VLANs et du filtrage ça devient coton.
On peut continuer avec mDNS, mettre des proxy mDNS et ND mais il faut que le filtrage puisse s'adapter à un changement de préfixe et traquer les hôtes, presque impossible en pratique.
On peut également affecter les adresses via DHCP pour fixer les 64 bits des hôtes, et encore ça ne marchera pas pour Android. On doit là aussi avoir un firewall qui supporte ce comportement.
DHCPv6 a d'ailleurs une option pour demander aux clients de venir se rafraichir, utile pour le flash renumbering.

Avec NPTv6 on supprime ces problèmes.

OPNsense a beaucoup de requêtes en ce sens:
https://forum.opnsense.org/index.php?topic=9438.0
https://github.com/opnsense/core/pull/5574
https://github.com/opnsense/core/issues/5284

Je ne me souviens pas avoir vu qu'un produit entreprise comme un Fortigate ou un PaloAlto supportait un tel dynamisme sur les ACL.

Je vois même des gens proposer d'avoir 2 ISP, de laisser les 2 préfixes cohabiter partout etc... Et des utopistes de proposer de faire du MPTCP via les 2 blocs. On en revient un peu à ce que proposait le défunt SHIM 6.

Dans le monde réel, un serveur Windows ou Linux ne va généralement pas accepter un réadressage dynamique, même si le socket est en écoute sur ::0.
Alors on script un reboot de toute sa prod de PME si M. le FAI refile un nouveau préfixe ?

C'est un vrai challenge, et je ne vois pas de bonne réponse, juste des problèmes différents.
Même si je penche pour NPTv6 en entreprise, ça revient à modifier le header et re-casser la philosophie d'IPv6, il faut alors refaire du NAT ALG sur le SIP, etc. 

Mais il serait très intéressant de se pencher dessus, à minima pour exposer les avantages et inconvénients des solutions.
Cela pourrait tout à fait intégrer le travail de la taskforce cette année.

De mon côté je dois travailler à la création d'une checklist pour ISP sur les capacités des CPE en partant des usecase (P2P, gaming, self-hosting,...)
Le self-hosting étant plutôt pour les PME ou "enthusiasts".   


à ta dispo pour échanger dessus, avec Vivien aussi bien sûr

Les FAI ne fournissent-ils pas un préfixe qui dure toute la durée de l'abonnement ?

Ils peuvent en fonction des offres, il faut en faire la demande.

Étant chez free, mon préfixe IPv6 tout comme mon IPv4 ne changent jamais même si cela n'est pas garanti contractuellement. Je n'ai donc pas travaillé sur des solutions à ce problème.

Par contre, j'ai basculé tous mes services internes sur des VLAN avec des préfixes ULA dédiés. Mais je garde le SLAAC pour organiser tout cela. C'est un raspberry pi qui qui diffuse les préfixes ULA sur les quelques VLAN que j'ai mis en place. Il me sert également de DNS menteur (coupure de youtube et de pas mal de pub, traceurs...), et de DNS local pour résoudre le domaine « home ». Il ne faut surtout pas utiliser le domaine « local » pour cela vu qu'il est réservé au mDNS.

Cette architecture permet de cloisonner totalement le trafic interne (les partage SMB du NAS, les échanges entre VM...), du trafic potentiellement externe sur préfixe global. Les différents chevaux de Troie de la maison (TV connecté, aspirateur robot, périphériques android...), ne voient potentiellement que le trafic global anycast.

La grosse difficulté d'un tel cloisonnement vient des machines Windows pour lesquelles la gestion d'un port réseau en trunk n'est pas native à l'OS. Il faut donc une carte réseau Intel ou Realtek pour permettre à une machine Windows d'être connectée à la fois au réseau global et au VLAN SMB.

Au final, j'ai un gain de sécurité et une certaine tolérance au changements de préfixes IPv6 globaux.

Côté services globaux, j'ai pu mettre en place une délégation de préfixe depuis la box vers des serveurs sous Linux pour proposer ces préfixes à des VM. Un changement de préfixes globaux serait bien plus compliqué à gérer dans ce cas.