See i pv6

IPv6
Dans le milieu universitaire
français
Réunion SEE
Mise en œuvre de l'adressage IPv6 dans les
réseaux
- 17 Novembre 2010 -
1

AGENDA
¢  IPv6 à Renater
¢  IPv6 à Télécom Bretagne
¢  IPv6 et les nouvelles BCP
¢  Perspectives

pag
e 4
HISTOIRE
¢  1993: Premiers travaux sur IPv6
¢  1995: Mise en place du G6 autour de la première
pile IPv6 de l’INRIA
—  Création du 6bone (DK-FR-JP)
¢  Réseau à base de tunnels sur IPv4
¢  2000: Intégration du 6bone dans l’architecture de
Renater
¢  2002: Développement d’un plan d’adressage propre
à Renater
¢  2006: Fin du 6bone

IPv6 addressing case studies
5
RENATER-5: NATIONAL & INTERNATIONAL LINKS

7
SERVICE IPV6 DE PRODUCTION
¢  Besoin d un transport IPv6:
—  Projets de recherche IPv6
—  Sites avec des réseaux IPv6
—  à Mise en place d un cœur IPv6
—  à Les deux versions du protocole IP sur un même
équipement.
⇒  Supervision du service IPv6 de la même manière
qu’IPv4

8
SUPPORT NATIF DU PROTOCOLE IPV6
¢  Sur le cœur à 10 Gbps
¢  50 Nœuds Régionaux (NR)
¢  IPv6 natif sur tous les nœuds régionaux
—  Réseaux double pile à IPv4 et IPv6
¢  Service IP Global
—  IPv4 unicast et multicast
—  IPv6 unicast
¢  IPv6 et IPv4 traité de la même manière
—  Performance
—  Availability
—  Management
—  Support
¢  Prochainement
—  IPv6 L3VPN: utilisant la technologie 6VPE

9
ADRESSAGE
¢  Adressage hierarchique
¢  RENATER
—  Prefix = 2001:0660::/32
—  Alloué par le RIR (RIPE NCC)
¢  Nœud régionaux
—  POP-ID =2001:0660:xy::/40
¢  Site
—  Site-ID : un /48
¢  Dérivé du nœud régional où il est connecté
—  Les Site-ID sont alloués par Renater (LIR)
¢  Exceptions:
—  Région parisienne:
¢  4 POP-IDs aggregated = 2001:0660:3000::/38
—  Outremer: Pas de transport natif => Tunnels IPv6 dans IPv4

10
ADDRESSAGE
2001:0660: ----------------
POP-ID
8 bits
Site-ID
8 bits
/32 /48 /64
Interface IDLIR Site sn
2001:0660:4400:/40 Lille RI
2001:0660:5400:/40 Marseille RI
(…)
eg:2001:0660:4401:/48
RIR

11
SCHÉMA D’ADRESSAGE
2001:660:20xx::/48
RENATER
backbone
2001:660:{3-F}xxx::/482001:660:{3-F}xxx::/48
Regional
Network
Sites
Campuses

pag
e 13
IPV6 ET IPV4 INTÉGRÉS

INFRASTRUCTURE
¢  Pas de pb. particulier au niveau du réseau.
—  Le plus dur fut d'obtenir 2 ::/48 pour Rennes et Brest
auprès de Renater (lourdeurs administratives).
—  Première demande, maintenant résolu
¢  Dans un 1er temps tunnel dans IPv4 puis BGP natif avec
Renater
¢  Le routeur de frontière (cisco 2821) était compatible ipv6
mais pas le switch L2/L3 de cœur de réseau (cisco c6500 1ere
génération) .
¢  Le FW (PIX V6) entre le routeur de frontière et le switch
interne n'était pas compatible ipv6:
—  le routage et filtrage intervlan était effectué sur le
routeur de frontière (c2821)
¢  A ce jour le switch cisco c6500 a été mis à jour et route aussi
v6 en interne.
¢  Le FW va être changé car il "route" v6 mais n'est pas FW
statefull en v6

INFRASTRUCTURE
¢  Adressage :
—  IPv6 déployé sur pratiquement tout le réseau :
—  Plusieurs ::/52 pour la recherche:
¢  Mobilité, Multi-domiciliation, Réseaux de Capteurs, ITS,
sécurité
—  ::/52 pour les résidences étudiantes .
¢  Interco native v6 entre les 2 campus.
¢  Accès complet vers l'extérieur (en v4 : natés et "shapés", pas
en v6)
—  plusieurs ::/54 pour les salles de TPs
¢  Formation initiale, Formation Continue
¢  Tous les vlans de production sont v4/v6

INFRASTRUCTURE
¢  services :
—  WWW, messagerie , ssh sur rennes , soit en natif soit via
des proxy v4/v6 (stunnel pour les accès ssl ipv6)
—  WWW: pas encore sur Brest (au départ, problème de
compatibilité du proxy/load balancer)
¢  DNS : support des AAAA, record AAAA pour les services:
—  pas de gestion de reverse pour l'instant
¢  Préfixes enregistrés pour un accès IPv6 vers Google

SÉCURITÉ MINIMUM
¢  pas de FW
¢  Filtrage par adresses et par ports (screen router), tout est
autorisé en sortie, mais un minimum en entrée (sauf pour la
recherche)
¢  le routeur central fait du RIPng avec les salles TPs mais
filtre un minimum les annonces
¢  autoconf v6 sur les vlan de prod:
—  projet de sécurisation avec déploiement de 802.1X sur
tout le réseau
¢  monitoring cacti/mrtg (pas encore nagios)
IPv4 IPv6

ENSEIGNEMENT
¢  Formation Initiale
—  IPv6 Banalisé
¢  Formation continue
—  Formation faite en collaboration avec le G6Formation
¢  Projets Etudiants
—  Enseignement par la recherche
¢  Réseaux de capteurs
¢  Pénurie (tranche de ports)
¢  Projet soutenu par Cisco

pag
e 22
QUELS CHANGEMENTS ?
¢  En théorie : mineurs
—  Respect des règles CIDR:
¢  Un seul préfixe par site et par fournisseur
—  Mêmes protocoles de routage
—  Mêmes firewalls :
¢  Extensions peu utilisées
¢  Filtrage des connexions entrantes
¢  Nouveauté : Neighbor Discovery

G6Tutorial
pag
e 23
AUTO-CONFIGURATION : EXEMPLE
Router
host
Internet
Crée l’@ lien-local
RS
Envoie un RS en utilisant
l’addresse multicast (ff02::2)‫‏‬
RA
Reçoit le(s) préfixes globaux
(DNS Dynamic Update ?)‫‏‬
Exécute un DAD
Exécute un DAD
Paramètre son routeur
de sortie (DHCPv6 ?)‫‏‬

pag
e 24
LE DIABLE ...
¢  Par exemple : EDUROAM
¢  Traçabilité
—  L'établissement doit garder les traces nécessaires à
l'identification d'un usager à partir de l'adresse IP
utilisée en cas d'abus constaté : accounting RADIUS,
logs DHCP, NAT,... Ces traces doivent comporter un
horodatage fiable.
¢  Plus de NAT, plus de DHCP
—  RADIUS va autoriser, mais on ne connait pas la source
—  Tout est dans les « ... »

pag
e 25
DEUX FAMILLES DE BCP
¢  On continue a faire comme en IPv4:
—  Rendre obligatoire l'attribution d'adresse par un
serveur DHCPv6
—  Doit fonctionner sur le matériel existant
¢  On adapte le fonctionnement du réseau à IPv6:
—  Avec le développement de nouvelles fonctionnalités si
nécessaire.

pag
e 26
AUTO-CONFIGURATION SANS ÉTAT
¢  Pas de nouveaux problèmes de sécurité
—  Comment empêcher un utilisateur d'entrer dans le
réseau?
¢  Mais de nouveaux problèmes de mauvaises
configuration.
—  Comment empêcher un équipement d'annoncer un faux
préfixe?
—  SEND: Lier un routeur annonçant les préfixes et un
certificat.
¢  Pas adapté au monde de l'entreprise (chaîne de certificats)‫‏‬

pag
e 27
PROBLÈME DE NIVEAU 3?
¢  En IPv4
—  Généralement sur DHCP,
—  Mais est-ce la bonne place
¢  En IPv6
—  Rendre obligatoire l'authentification au niveau 2 avant
l'auto-configuration (IEEE 802.1X, WPA, PANA,...)‫‏‬
—  Associer les adresses IPv6 aux interfaces pour log
—  Filtrer les annonces RA sur les port identifiés comme
équipement terminal

pag
e 28
INSCRIPTION DANS LE DNS
¢  En IPv4
—  Le serveur DHCP inscrit l'information dans le DNS
¢  Direct et inverse
¢  En IPv6
—  Si l'équipement construit son adresse, il ne peut pas
s'inscrire dans le DNS:
¢  Problème de clé
¢  Doit-on inscrire un client dans le DNS ?
—  A t-on besoin d'être dans le reverse DNS
—  Problème de confidentialité, sécurité.

pag
e 29
CONCLUSION
¢  Le déploiement d'IPv6 va modifier les BCP :
—  Basés sur des compromis entre le matériel et
l'architecture.
—  Les équipements vont devoir évoluer pour prendre en
compte plus intelligemment IPv6
¢  Actuellement peu de problème de compatibilité sur les
fonctions basiques.
¢  Manque d'intégration outils d'administrations
—  Prévoir certaines fonctionnalités dans les appels
d'offres
¢  Par exemple IEEE 802.1X

pag
e 31
CONCLUSIONS
¢  IPv6 est prêt depuis des années pour un
déploiement dans le milieu universitaire.
—  Frein de la demande
¢  Projets de recherche incluant IPv6
¢  GRID 5000, SensLab
¢  Projets Européens
—  Renforcer la formation autour d’IPv6:
¢  Partage de savoir (http://livre.g6.asso.fr)
¢  Concours d’applications
¢  Nouvelles architectures logicielles, Internet des objets

See i pv6

Contenu connexe

Tendances

En vedette

Similaire à See i pv6

See i pv6