L’annonce est un peu passée inaperçue à la fin de l’année dernière: CNR (CISCO Network Registrar) supporte maintenant DNS64 (composante essentielle du mécanisme NAT64). Je ne manquerai pas de recommencer mes tests NAT64 en tentant de remplacer Bind par CNR et vous faire mon retour dans un prochain post!
Vous vous en souvenez surement .. Janvier 2011 .. un an déjà.
Ce mois marquait alors l’annonce par un grand nombre d’acteurs de l’internet d’un test grandeur nature de déploiement IPv6 – Le World IPv6 Day.
Cisco fut un des premiers à annoncer sa participation et après des mois d’un travail plutôt intense, il apparu clairement que ce jour était à marquer d’une pierre blanche dans l’histoire d’IPv6.
Cette journée fut en effet riche en enseignements de tout ordre et le consensus apparu rapidement sur la nécessité de ne pas seulement prévoir un nouveau test d’une journée .. mais cette fois d’activer IPv6 une bonne fois pour toute et de le laisser.
Le 6 juin 2012 l’industrie s’unira donc de nouveau, activera IPv6 et le laissera en place : c’est le World IPv6 Launch.
Comme l’an dernier, l’accès IPv6 des sites Web se fera par les annonces DNS qui resteront cette fois en place. On verra également la participation d’ISP avec l’activation par défaut d’IPv6. Bien sur IPv6 est disponible sur un certain nombre d’équipements résidentiels, bien sur IPv6 est aussi disponible chez un certain nombre d’ISP, mais généralement IPv6 n’est pas activé par défaut. Pour supprimer les barrières qui existent dans le déploiement d’IPv6 et pour accélérer son adoption, les nouvelles souscriptions verront IPv6 activé par défaut chez les opérateurs participants.
Bien évidemment Cisco a le plaisir d’annoncer sa participation, en activant IPv6 sur son site web www.cisco.com ainsi qu’en activant par défaut IPv6 sur sa nouvelle série de routeurs résidentiels (E-Series). De même nous allons accompagner nos clients dans cette démarche vers IPv6 avec le soutien de nos équipes Services et des équipes de développement.
Pour en savoir plus, regardez la vidéo de Mark Townsley:
Dans 3 semaines, Paris accueille l’IPv6 world congress pour la deuxième année consécutive. Après un bon millésime 2011 nous aurons cette fois-ci surtout des retours d’expérience d’opérateurs et d’entreprises après le jump day de juin dernier. Profitez de la proximité de cette conférence et venez nombreux: des annonces intéressantes devraient être faites pour 2012: http://www.uppersideconferences.com/v6world2012/v6world2012intro.html
Un petit cadeau de Noël: on a un article IPv6 ce mois-ci dans CISCO MAG! Il explique pourquoi tout le monde est concerné par IPv6 (même ceux qui ont encore une énorme quantité d’adresses IPv4 en stock!) Lire l’article: IPv6 – L’affaire de tous
L’auto-configuration a du bon mais on aimerait la contrôler: comment s’assurer que les RA (Router Advertisements) sont bien envoyés par le bon équipement? Cette question revient régulièrement… Par exemple à la conférence JRES en novembre dernier, où l’on a longuement parlé IPv6, ce point a été soulevé dans plusieurs présentations. Faisons rapidement le point…
Les solutions à mettre en place pour garantir une protection d’IPv6 sur l’accès sont regroupées sous l’appellation IPv6 FHS (First-Hop Security). Un bon whitepaper décrit toutes les fonctionnalités qui se cachent derrière ce terme, entre autres:
IPv6 RA Guard (vérifie que les RA sont “normaux” et arrivent bien depuis le port du switch sur lesquels des routeurs sont connectés)
ND inspection (associe chaque adresse IPv6 à une entrée dans la table MAC, pour éviter par exemple du spoofing fait par un autre équipement sur le même lien-local)
IPv6 Device Tracking (supprime les équipements qui ne sont plus actifs de la table des hosts IPv6 maintenue par le switch)
PACL IPv6 (Port ACL)
SEND (sécurisation plus complexe de NDP à base de certificats)
La fonction RA Guard répond bien au problème que beaucoup rencontrent: en effet on aimerait éviter qu’un host mal-intentionné (ou mal configuré) se mette à envoyer un RA sur le lien, devenir passerelle par défaut de tous les hosts sur le lien-local et avoir accès à toutes les communications. Problème: IPv6 FHS dans sa globalité n’est disponible “que” sur catalyst 6500 avec sup2T et non sur les plateformes plus souvent à l’accès. Que l’on se rassure tout cela changera en 2012… mais pour ceux qui ne veulent pas attendre et qui ont des catalyst 3750 ou 4500 à l’accès il reste possible de configurer une PACL qui filtrera les RA et les paquets DHCPv6 émis par les serveurs. On appliquera cette PACL sur tous les ports du switch (excepté bien sur celui/ceux sur lequel/lesquels on branchera le/les routeur/s)
ipv6 access-list ACCESS_PORT
remark Block all traffic from DHCP server to client
deny udp any eq 547 any eq 546
remark Block Router Advertisements
deny icmp any any router-advertisement
permit any any
!
interface gigabitethernet 1/0/1
switchport
ipv6 traffic-filter ACCESS_PORT in
Je reviendrai sur IPv6 FHS, avec je l’espère un petit lab à la clé! 2 cartes sup2T arrivent dans mon lab pour Noël et je compte bien les faire chauffer un peu C’était mon dernier post sur ce blogue avant la trêve des confiseurs… Rendez-vous début janvier et d’ici je vous souhaite à tous d’excellentes fêtes de fin d’année!
Je sais que beaucoup attendaient cette fonctionnalité pour basculer le management plane en IPv6, c’est disponible depuis une quinzaine de jours sur les ISR G2 (3900, 2900, 1900, 800) avec la release 15.2(2)T. Ca arrivera progressivement sur les autres plateformes… On avance!
Et si on pondérait les allocations IPv6 par la taille des réseaux IPv4 concernés? C’est l’idée qu’a eu Rene Wihelm et qu’il nous expose brillament dans RIPE labs.
On n’aurait donc plus 47% de LIR avec un préfixe IPv6 mais on doit plutot considérer 81% de l’Internet susceptible d’être adressé en IPv6!
Idem ne parlons plus de 29% des LIR routés en IPv6: 61% de l’Internet serait déjà potentiellement routé en IPv6!
Intéressant, certains commencent à mouiller un peu le maillot et jouent le jeu IPv6 à 100% ! Ils nous décrivent les tests réalisés et nous donnent leurs observations:
Pour ce test une dizaine de personnes ont accepté de travailler au quotidien sur un réseau v6-only. Leur conclusion reste que travailler dans un réseau IPv6-only est possible mais ne s’applique pas à tous, surtout en raison de problèmes au niveau de certaines applications qui ne sont pas NAT64-ables en raison du transport d’adresses IP dans les payloads. Ils suggèrent donc un déploiement basé sur du dual-stack mais n’ont pas de doutes sur la très prochaine résolution des problèmes identifiés qui permettra un modèle IPv6-only. Ci-dessous un extrait:
Comme vous le savez peut-être, nous avons maintenant des webinars réguliers tous les trimestres sur différentes technologies. Les présentateurs sont du Network Software Technology Group, groupe ayant en charge le software de toutes les plateformes routeurs/switchs (IOS, IOX-XR et NXOS).
Une présentation qui vaut la peine d’y passer un peu de temps. Celle de Goeff Houston, Chief Scientist à l’APNIC, sur les difficultés et les risques d’une longue transition IPv6.