Retour d'expérience : déploiement d'IPv6 sur un réseau régional

Magazine
Marque
MISC
Numéro
83
Mois de parution
janvier 2016
Domaines


Résumé

On parle depuis plus de 20 ans d'IPv6 et de l'urgence de migrer nos infrastructures vers ce nouveau protocole. Pour autant il est parfois difficile de prendre la mesure des impacts de cette migration. Cet article se propose de faire un retour d'expérience sur le déploiement d'IPv6 sur un réseau de collecte régional pour la communauté enseignement recherche. Nous nous intéresserons aux choix techniques réalisés pour cette migration ainsi qu'aux difficultés rencontrées durant plus de 10 ans d'exploitation d'IPv6. Nous aborderons également un aspect plus prospectif sur IPv6 et ce qui nous attend au-delà de la problématique de migration en elle-même.


1. Contexte

1.1 SYRHANO

SYRHANO est un réseau régional qui raccorde aujourd'hui les établissements d'enseignement, de recherche et de santé en Haute-Normandie. C'est à la fois un réseau de transport qui fournit des services de transport (connectivité IPv4 et IPv6 unicast et multicast, VPN MPLS, VPLS), mais également des services applicatifs en mutualisant des infrastructures lourdes pour ses utilisateurs comme par exemple des services de visioconférences multi-point ou des services de stockage de grande capacité pour les données de recherche.

SYRHANO est raccordé au réseau national RENATER et prolonge dans ce cadre l'ensemble des services spécifiques pour l'enseignement et la recherche en région. Techniquement, le réseau est composé d'équipements actifs (routeurs, commutateurs) hébergés au sein de points de présence (PoP) localisés chez nos principaux utilisateurs (Universités, laboratoire de recherche, centres hospitaliers). Pour relier ces...

Cet article est réservé aux abonnés. Il vous reste 97% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite
Références

[1] « RFC 4213 : Basic Transition Mechanisms for IPv6 Hosts and Routers », https://tools.ietf.org/html/rfc4213

[2] « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », http://www.bortzmeyer.org/fragmentation-ip-1280.html

[3] « RFC 5969 : IPv6 Rapid Deployment on IPv4 Infrastructure (6rd) », https://tools.ietf.org/html/rfc5969

[4] « RFC 2080 : RIPng for IPv6 », https://tools.ietf.org/html/rfc2080

[5] « RFC 5308 : Routing IPv6 with IS-IS », https://tools.ietf.org/html/rfc5308

[6] « RFC 5340 : OSPF for IPv6 », https://tools.ietf.org/html/rfc5340

[7] « RFC 5838 : Support for Address Families in OSPFv3 », https://tools.ietf.org/html/rfc5838

[8] « RFC 4760 : Multiprocol Extensions for BGP-4 », https://tools.ietf.org/html/rfc4760

[9] « Global Internet Routing Table Reaches 512k Milestone », http://blogs.cisco.com/sp/global-internet-routing-table-reaches-512k-milestone

[10] « Predicting the IPv6 BGP table size », http://blog.ipspace.net/2013/03/predicting-ipv6-bgp-table-size.html

[11] « RFC 4659 : BGP-MPLS IP Virtual Network (VPN) Extension for IPv6 VPN », https://tools.ietf.org/html/rfc4659

[12] « The Ugly Side of IPv6 : Carrier-Grade NAT », http://www.lightreading.com/ethernet-ip/the-ugly-side-of-ipv6-carrier-grade-nat/d/d-id/687459

[13] « ARIN reaches IPv4 depletion », https://blog.apnic.net/2015/09/25/arin-reaches-ipv4-depletion/

[14] « Sunsetting IPv4 (sunset4) », https://datatracker.ietf.org/wg/sunset4/charter/

[15] « RFC 7439 : Gap Analysis for Operating IPv6-Only MPLS Networks », https://tools.ietf.org/html/rfc7439

[16] « RFC 6146 : Stateful NAT64 : Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers », https://tools.ietf.org/html/rfc6146

[17] « RFC 6147 : DNS64 : DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers », https://tools.ietf.org/html/rfc6147

[18] « RFC 6877 : 464XLAT : Combination of Stateful and Stateless Translation », https://tools.ietf.org/html/rfc6877

[19] « World IPv6 Launch », http://www.worldipv6launch.org/

[20] « Apple Will Require IPv6 Support For All IOS 9 Apps », http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/



Articles qui pourraient vous intéresser...

Netcat, l’histoire d’un couteau suisse pour le réseau

Magazine
Marque
Linux Pratique
Numéro
123
Mois de parution
janvier 2021
Domaines
Résumé

Lier le monde de l’administration système et celui du réseau n’est pas chose aisée, ni donné à tout le monde. De nombreux outils présents issus du monde de l’open source essaient désespérément d’y trouver une place. L’un d’entre eux a par ailleurs une longueur d’avance. Permettant de jouer avec la création de socket sur la couche transport du modèle OSI, Netcat rayonne dans le monde underground depuis déjà de nombreuses années. Rien de tel qu’une petite histoire pour parler de ce programme légendaire...

Zerologon pour les (mots de passe) nuls

Magazine
Marque
MISC
Numéro
113
Mois de parution
janvier 2021
Domaines
Résumé

ZeroLogon est LA vulnérabilité de septembre 2020 qui expose de nombreux domaines Windows à une compromission totale via un scénario d’exploitation réaliste et fiable. Mais ce qui donne à Zerologon ses lettres de noblesse c’est qu’elle repose essentiellement sur la mauvaise utilisation d’un algorithme cryptographique permettant de réaliser une attaque à clair choisi particulièrement astucieuse. Zoom sur la vulnérabilité la plus passionnante de la rentrée 2020 !

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.