ipv6 analyse et mise en oeuvre - memoire stage ingénieur réseau
DESCRIPTION
Mémoire de fin d'étude sur IPv6TRANSCRIPT
IPv6 étude et mise en œuvre et sécurité réseau
Etudiant : Benoît DE MIANVILLE
Responsable pédagogique UTT : Florent RETRAINT
Branche : SIT6
Année : 2012
Semestre : P12
Entreprise : 2SI SYSTEMES
Lieu : Soissons
Responsable : Stéphane CANIVET
Mots clés (CF Thésaurus)
Nature de l’activité : Mise en place, mise en œuvre
Branche d’activité économique : Services aux entreprises
Domaines technologiques : Réseaux d’ordinateurs
Application physique directe : machines
Ce stage s'est déroulé dans l'entreprise 2SI, au sein du service infrastructure; les clients de 2SI sont des
PME/PMI, petites industries et groupes nationaux. Les missions du service infrastructure sont la conception
et le déploiement d'architectures systèmes et réseaux, l'hébergement de serveurs et d'applications et
l'infogérance.
Ce stage a consisté à analyser IPv6, à déterminer les enjeux de cette technologie et à préparer son
déploiement, il a également consisté à améliorer la sécurité réseau interne et à capitaliser ces savoirs.
Les étapes ont consisté à mettre en œuvre IPv6 sur un site pilote, à former l'équipe technique et
commerciale et à aider à définir un plan d'action commercial.
Au final, un grand travail d’étude a mis en évidence la nécessité d’IPv6, a proposé et mis en œuvre des
solutions permettant de donner accès à des postes utilisateurs à l’Internet IPv6 et de rendre disponible
l’accès à des serveurs interne en IPv4 via IPv6.
Remerciements
Je tiens à remercier très sincèrement mon maitre de stage, Stéphane Canivet, qui a su dès mon
premier entretien m’écouter et m’aider à construire un déroulement de stage passionnant et qui a
continué à m’accompagner tout au long du stage.
Je remercie mon parrain de stage, Daniel Doulbeau, qui m’a formé au quotidien et m’a transmis son
savoir faire et sa grande expérience dans le domaine des réseaux et des systèmes, tout cela avec
beaucoup de bonne humeur.
Je remercie chaleureusement chaque collaborateur de 2SI pour leur aide précieuse et leur confiance.
Je remercie M. Alain Crémont pour m’avoir accueilli dans son entreprise et m’avoir fait confiance.
Enfin je remercie l’équipe éducative de l’UTT qui assure une qualité de formation très pointue.
Sommaire
1 2SI .................................................................................................................................................... 1
2 Contexte .......................................................................................................................................... 2
3 Qu’est-ce qu’IPv6 ............................................................................................................................ 3
4 Qui va avoir besoin d’IPv6 ............................................................................................................... 7
5 Quelles différences par rapport à IPv4 ............................................................................................ 8
5.1 Adressage et notation ............................................................................................................. 8
5.2 Types d’adresses...................................................................................................................... 9
5.3 Répartition des adresses par l’IANA ........................................................................................ 9
5.4 Unicast : notion de scope/portée .......................................................................................... 11
5.5 Autres types d’adresse .......................................................................................................... 13
5.6 Entête .................................................................................................................................... 13
5.7 ICMP v6 .................................................................................................................................. 14
5.7.1 Auto configuration ........................................................................................................ 15
5.8 Problème de sécurité de l’auto configuration....................................................................... 15
5.9 DHCP ...................................................................................................................................... 16
5.10 Sécurité .................................................................................................................................. 17
6 2SI et IPv6 ...................................................................................................................................... 19
7 Planning du projet ......................................................................................................................... 20
8 Comment mettre en œuvre IPv6 .................................................................................................. 22
8.1 Techniques les plus utilisées ................................................................................................. 22
8.1.1 La double pile ................................................................................................................ 22
8.1.2 La traduction d’adresses – NAT-PT, NAT-64 et DNS-64 ................................................ 23
8.2 Offre des FAI .......................................................................................................................... 26
8.3 Méthodes adaptées ............................................................................................................... 27
8.4 Quel matériel ......................................................................................................................... 28
8.4.1 Les terminaux des utilisateurs ....................................................................................... 28
8.4.2 Les serveurs ................................................................................................................... 28
8.4.3 Equipements réseau de niveau 2 (commutation) ......................................................... 29
8.4.4 Pare feu et routeur ........................................................................................................ 29
8.4.5 Translation NAT 64 ........................................................................................................ 29
8.5 Autres techniques.................................................................................................................. 30
8.5.1 Tunnels .......................................................................................................................... 30
8.5.2 Fournisseurs de tunnel .................................................................................................. 33
8.5.3 Autres tunnels ............................................................................................................... 33
8.5.4 6PE (MPLS) ..................................................................................................................... 33
9 Ce qui a été mis en œuvre ............................................................................................................. 34
9.1 Formation .............................................................................................................................. 34
9.2 Site pilote ............................................................................................................................... 34
9.2.1 Etude de FAI proposant IPv6 ......................................................................................... 34
9.2.2 Etude du matériel nécessaire ........................................................................................ 35
9.2.3 Etapes de déploiement .................................................................................................. 35
9.2.4 Mise en œuvre avec un tunnel IPv6 .............................................................................. 37
10 Critique de ce qui a été fait ....................................................................................................... 49
11 Conclusion ................................................................................................................................. 51
12 Bibliographie .............................................................................................................................. 52
13 Annexe ......................................................................................................................................... 1
13.1 Configuration du pare feu Cisco 1941 ..................................................................................... 1
13.2 Cisco VPN IPSec site à site (sur routeur) ................................................................................. 6
13.3 Cisco NAT PT explication et mise en œuvre ............................................................................ 9
IPv6 – étude et mise en œuvre Benoît de Mianville
1
1 2SI Le groupe 2SI est un intégrateur de nouvelles technologies à la portée nationale. L’expertise est
apportée dans l’ingénierie informatique, le conseil, la communication interactive, le e-learning et la
production audiovisuelle.
120 collaborateurs sont répartis sur 6 sites dans la France, 2SI compte 2500 clients :
Figure 1 : 2SI, 6 sites sur la France, Google Maps 2012
2 agences sont à Soissons dont celle de 2SI Systèmes qui comporte les services suivants :
Service intégration de progiciels
o Intégrateur des progiciels DIVALTO et SAGE, spécialiste des solutions pour les
cabinets d’expertise comptable et développement de logiciels sur mesure
Service infrastructure
o Conception et déploiement d’architectures systèmes et réseaux
o Déploiement de services réseaux (messagerie, annuaire, outils de travail collaboratif)
o Hébergement de serveurs et d’applications
o Infogérance
C’est dans le service infrastructure que j’ai effectué mon stage de fin d’étude, dont je vais décrire le
contenu dans la partie suivante.
IPv6 – étude et mise en œuvre Benoît de Mianville
2
2 Contexte Mon sujet de stage était IPv6 et la sécurisation des réseaux, il consistait à analyser le protocole
Internet de nouvelle génération, à former l’équipe technique composée de 13 personnes puis à aider
à déployer un plan d’action commerciale pour accompagner les clients dans l’introduction de cette
technologie, je devais également m’intéresser à l’étude et à l’amélioration de la sécurité réseau au
sein de l’infrastructure technologique interne pour ensuite proposer ces solutions éprouvées aux
clients.
Concrètement le sujet initial a été suivi et développé en profondeur puisque l’équipe technique a été
formée au cours d’une séance qui abordait IPv6 par la théorie puis par des travaux pratiques, j’ai
assisté à un séminaire concernant le lancement mondial d’IPv6 organisé par G6 associé à Neo
Telecoms, Cisco, l’AFNIC et l’Institut Mines-Telecom, un site pilote a été déployé et l’équipe
commerciale a été formée ; concernant la sécurisation des réseaux, une formation a été donnée à
l’équipe technique pour consolider les bases des réseaux et de la sécurité. De plus, le renouvellement
du pare feu de l’infrastructure réseau interne est en cours à la suite d’une étude technique et
financière.
Ma place dans le service était celle d’un ingénieur réseau et système en apprentissage avec les autres
ingénieurs, j’ai participé à des missions techniques de maintenance et de déploiement
d’infrastructure réseau et système virtualisée haute disponibilité jusqu’à une échelle d’un système
accueillant 400 utilisateurs.
IPv6 – étude et mise en œuvre Benoît de Mianville
3
3 Qu’est-ce qu’IPv6 IPv6 – Internet Protocol version 6 est un protocole qui permet à deux machines de communiquer à
travers un réseau, en particulier le réseau Internet. Nous allons décrire l’histoire de l’ancien
protocole Internet puis la venue du nouveau protocole.
Le berceau d’Internet, Arpanet, a fait peu à peu apparaitre le premier protocole Internet largement
utilisé en 1981 : IPv4, décrit dans le RFC1 791. IP est un protocole de communication de « bout en
bout » ou chaque pair est identifiable par une adresse, cette adresse est composée de quatre octets.
A l’origine ces quatre octets pouvant théoriquement permettre d’adresser jusqu’à 4 milliards
d’ordinateurs paraissaient démesurés étant donné que les ordinateurs pouvaient prendre l’espace de
pièces entières et coûtaient très cher. Aujourd’hui l’Internet s’est démocratisé en commençant par
les communications inter universités puis le développement de la bulle internet par les
commerçants, finalement l’Internet est petit à petit rentré dans nos foyers et depuis le
développement des appareils mobiles grand public pouvant accéder à Internet suivi de la récente
généralisation de l’accès à Internet nomade par les opérateurs téléphoniques, on est arrivé à une
moyenne de 5 périphériques connectés par personne en 2010 et il est prévu en 2013 d’atteindre 140
périphériques connectés par personne (source Forrester Research, Cisco IBSG), ce qui nous donnera
à raison de 7 milliards d’individus un besoin d’environ 980 milliards d’adresses pour les périphériques
connectés. Les limites du nombre d’adresse IPv4 ont déjà été atteintes et le développement d’une
nouvelle version d’IP (version 6) a été initiée en 1992 ; la version 5 a été attribuée à un protocole
expérimental. En attendant des palliatifs ont été mis en place notamment les masques à longueur
variable (VLSM) en 1993 pour arrêter le gaspillage d’adresses dû aux masques à longueur fixe, l’autre
palliatif utilisé massivement aujourd’hui est le système de translation d’adresses dont le RFC a été
publié en 1994 ; la translation permet de n’allouer qu’une adresse publique valide sur internet au
routeur d’une organisation, les terminaux internes étant « cachés » avec une adresse privée derrière
le routeur. Le protocole « Dynamic Host Configuration Protocol », DHCP, dont le RFC a été publié en
1993 permet d’allouer dynamiquement une adresse à un hôte, cette technique permet aux FAI2
d’avoir moins d’adresses IP que de clients en sachant que statistiquement tous leurs clients ne sont
pas connectés en même temps.
L’IANA, Internet Assigned Numbers Authority est responsable de la répartition de tous les blocs
d’adresses du protocole Internet, et notamment des blocs d’adresses utilisables sur l’Internet. L’IANA
n’assigne pas des adresses directement aux utilisateurs mais elle assigne des blocs à des registres
régionaux (RIR, Regional Internet Registry) qui eux, assignent des sous blocs d’adresses aux
opérateurs de télécommunication. Ce système de distribution est le même pour IPv6 ; ci-dessous une
carte géographique représentant les RIR et leurs zones géographiques.
1 RFC : cela signifie Request For Comments, ce sont des documents qui servent à standardiser les protocoles de
l’Internet, ils sont accessibles à l’adresse suivante : http://www.ietf.org/rfc.html 2 Fournisseurs d’Accès à Internet
IPv6 – étude et mise en œuvre Benoît de Mianville
4
Figure 2 : Reginal Internet Registries, ripe.net
Le 1er février 2011, l’IANA a assigné son dernier bloc d’adresse aux RIR, cela ne signifie pas qu’il n’est
plus possible de réserver une adresse IP puisque les registres régionaux ont encore des blocs
disponibles pour les assigner aux FAI mais cependant le compte à rebours est visible pour la pénurie
d’adresses IPv4. Le graphique ci-dessous montre l’évolution de la distribution des adresses IPv4.
Figure 3 : Epuisement des adresses IPv4 - http://fr.wikipedia.org/wiki/Fichier:Ipv4-exhaust.svg
IPv6 – étude et mise en œuvre Benoît de Mianville
5
La pénurie totale d’adresse IPv4 est prévue courant 2012 suivant le graphique ci-dessus cependant
elle risque d’être quelque peu allongée. En effet, la plupart des entreprises ne sont pas encore prêtes
à effectuer la transition vers IPv6 et des techniques sont prêtes à être mises en place pour que les
opérateurs aient besoin de moins d’adresses IPv4 publiques grâce au CGN – Carrier Grade NAT. Ce
dernier permet de distribuer des adresses privées v4 aux clients et d’effectuer une translation chez
l’opérateur pour que les clients puissent communiquer avec l’internet ; cependant cette technique
reste complexe à grande échelle et non pérenne.
On peut voir ci-dessous un graphique représentant la répartition des blocs d’adresses IPv4 de l’IANA ;
on voit que l’IANA a distribué toutes ses adresses ; à noter que la partie Central Registry représente
les adresses gérées historiquement directement par l’IANA et la partie « not available » représente
principalement les adresses privées, les multicast et les expérimentales.
Figure 4 : répartition des blocs d’adresses IPv4 de l’IANA - http://www.nro.net/statistics
Ci-dessous on voit le nombre d’assignation d’adresses IPv6 par les registres régionaux aux utilisateurs
finaux.
IPv6 – étude et mise en œuvre Benoît de Mianville
6
Figure 5 : IPV6 ASSIGNMENTS RIRS TO END-USERS - http://www.nro.net/statistics
On peut constater que les 5 dernières années ont été celles qui ont connu le plus grand nombre
d’assignations et que cela croit de manière très importante car de 2009 à 2010 on a multiplié par 3,3
le nombre d’assignations et de 2010 à 2011 on a multiplié par 1,9 le nombre d’assignations en
passant respectivement de 180 à 600 et de 600 à 1120 assignation d’adresses IPv6 par les registres.
L’Internet Society (ISOC) a organisé le lancement d’IPv6 le 6 juin 2012
(http://www.worldipv6launch.org/), à partir de cette date, les FAI, les équipementiers et fabricants
de matériel réseau voulant bien participer ainsi que les autres fournisseurs auront activé IPv6 de
manière permanente et définitive sur leurs équipements3 ; des grand acteurs de l’Internet tels que
Google et Facebook participent à cette journée ainsi que la majorité des FAI aux Etats Unis mais aussi
Free en France, entre autres.
3 http://linuxfr.org/news/activation-mondiale-de-l-ipv6-world-ipv6-launch
IPv6 – étude et mise en œuvre Benoît de Mianville
7
4 Qui va avoir besoin d’IPv6 Comme décrit précédemment, le nombre d’adresses IPv4 disponible devient faible, après
l’épuisement du stock d’adresse IPv4 de l’IANA, le premier registre ressentant directement cet
épuisement est l’APNIC, qui gère les adresses en Asie. En effet à ce jour en France il est déjà plus
difficile qu’il y’a quelques années d’obtenir des adresses IPv4, il est nécessaire de fournir des
informations précises sur la raison de l’utilisation des adresses et sur notre identité ; tandis que de
l’autre côté de la terre, en Asie, des sites, n’ayant pas le choix, ou étant contraints d’avoir très peu
d’adresses IPv4, commencent déjà à utiliser IPv6 comme seul protocole pour se relier à Internet. La
demande de connectivité IPv6 va donc provenir des utilisateurs finaux, principalement des
fournisseurs de contenu ayant besoin d’être présent sur l’Internet, cela se traduit par l’acquisition
d’adresses IP.
Etant donné le contexte, il y’a deux cas ou on va être obligé de déployer IPv6, le premier est celui où
on veut accéder à des ressources disponibles uniquement via IPv6. Ainsi une entreprise
multinationale ayant une entité en Asie a été obligée d’utiliser IPv6 car cette dernière avait une
vision à long terme et misait sur ce nouveau protocole. L’autre cas est celui ou on veut présenter du
contenu à des utilisateurs qui n’ont qu’IPv6, on devra rendre ce contenu accessible par IPv6.
Nous nous intéressons maintenant aux entités qui vont être concernées par IPv6, les premiers
acteurs, ceux sans qui le déploiement ne pourra être réalisé, ce sont les FAI et les opérateurs, c’est le
cœur de l’internet par lequel transitent toutes les communications locales, interrégionales et
internationales. Un autre acteur à mettre au même niveau dans l’ordre de priorité pour permettre le
déploiement d’IPv6 regroupe les gestionnaires des plus hauts niveaux des domaines DNS, ceux-ci
sont systématiquement utilisés et font partie intégrante de l’Internet.
Dans un second temps, les professionnels qui ont un lien avec l’hébergement des services : ceux qui
déploient des services comme des sites web, ceux qui proposent des hébergements de services ou
d’infrastructure devront déployer petit à petit IPv6.
Enfin, les particuliers et les professionnels qui veulent accéder aux services disponibles sur l’internet,
utiliseront naturellement IPv6 car il sera utilisé par défaut par tous les FAI.
Peu importe la situation dans laquelle on est parmi les cas décrits, on n’est pas obligé de déployer
IPv6 ni même de s’intéresser à ce protocole, seulement, petit à petit on risque de s’isoler de
l’internet.
IPv6 – étude et mise en œuvre Benoît de Mianville
8
5 Quelles différences par rapport à IPv4
5.1 Adressage et notation Une adresse IPv6 est composée de 128 bits, (une adresse IPv4 est composée de 32 bits). On peut
faire une estimation du nombre d’adresse à 60 000 milliards de milliards d’adresses par habitant en
2012. Pour la notation, les 128 bits sont séparé en huit mots par « : » et notés en hexadécimal.
Par exemple (1) :
2000:0000:0000:0000:0000:0000:0000:0001
Ou encore (2) :
fedc:0000:0000:0000:0400:a987:6543:210f
Il n’est pas nécessaire d’écrire les zéros en tête, et plusieurs champs de zéros consécutifs peuvent
être abrégés par « :: » ; cette abréviation n’est possible qu’une fois. Le tableau ci-dessous présente
les différentes notations :
Notation brute 2000 :0000:0000:0000:0000:0000:0000:0001
Pas de zéros en tête 2000:0:0:0:0:0:0:1
Abréviation des zéros consécutifs
2000::1
Tableau 1 : notations de l'exemple 1
Notation brute fedc:0000:0000:0000:0400:a987:6543:210f
Pas de zéros en tête fedc:0:0:0:400:a987:6543:210f
Abréviation des zéros consécutifs
fedc::0400:a987:6543:210f
Tableau 2 : notations de l'exemple 2
Dans le cas de plusieurs suites de zéros non consécutives, le RFC 4038 prévoit d’abréger la suite la
plus longue et, dans le cas de longueurs égales, d’abréger la première suite de zéros, voyons cela
dans un exemple :
Notation simple 2000:0:2:0:0:0:0:1
Abréviation des zéros consécutifs
2000:0:2::1
Notation simple 2000:0:0:5:0:0:2001:1
Abréviation des zéros consécutifs
2000::5:0:0:2001:1
Une adresse est décomposée principalement en deux parties : la partie réseau et la partie hôte,
comme sur le schéma ci-dessous :
Adresse réseau Adresse hôte Figure 6 : Décomposition d'une adresse
IPv6 – étude et mise en œuvre Benoît de Mianville
9
On attribue la moitié de l’adresse pour le réseau et l’autre moitié pour les hôtes, ce qui fait 64 bits
pour chaque moitié.
Il est aussi utile de désigner des blocs d’adresses, dans ce cas-là on donne la partie adresse réseau et
un préfixe pour dire à quel endroit s’arrête la partie réseau.
Notation du préfixe : on peut noter les préfixes des adresses IPv6 comme la notation CIDR utilisée
pour IPv4, cela se note de la façon suivante : adresse-ipv6/longueur-du-préfixe-en-bits. Par exemple
on peut noter 2000::5:0:0:2001:1/64.
5.2 Types d’adresses On distingue trois types d’adresses : unicast, anycast et multicast. Une adresse unicast désigne une
interface unique et un paquet envoyé à une adresse unicast sera remis à une seule interface. Ci-
dessous sont présentées les portées des adresses unicast.
Type d’adresse Scope/portée Routable sur internet
Unicast Globale Oui
Locale Lien Non
Site Non Tableau 3 : portée des adresses unicast
Les adresses multicast désignent plusieurs interfaces qui peuvent être situées n’importe où sur
l’Internet. C’est le réseau qui se charge d’acheminer les paquets destinés aux membres du groupe de
l’adresse multicast.
Les adresses anycast, comme les multicast, désignent plusieurs interfaces, la différence est que
lorsque un paquet est destiné à une adresse anycast, il est acheminé à une seule des interfaces du
groupe, le choix peut se baser sur la métrique du protocole de routage.
Il n’y a plus d’adresses de broadcast comme en IPv4, ceci allégeant du trafic inutile au sein d’un
segment, on se servira des adresses multicast.
5.3 Répartition des adresses par l’IANA L’IANA, Internet Assigned Numbers Authority a assigné un bloc d’adresses IPv6 routables sur
l’internet, c’est le bloc Global unicast : 2000::/3. Le tableau ci-dessous montre la répartition des
adresses par l’IANA :
IPv6 – étude et mise en œuvre Benoît de Mianville
10
Tableau 4 : répartition des adresses IPv6 par l'IANA, http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
Ces adresses vont donc de 2000:: à 200f:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
Ce bloc d’adresses Global Unicast est ensuite réparti aux différents RIR, Regional Internet Registries.
Nous voyons donc dans le tableau ci-dessous la répartition des adresses Global Unicast pour les
registres régionaux :
IPv6 – étude et mise en œuvre Benoît de Mianville
11
Tableau 5 : répartition des adresses Global Unicast pour les registres régionaux, http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml
5.4 Unicast : notion de scope/portée Les adresses unicast sont organisées en plusieurs niveaux hiérarchiques selon le rfc 3587.
Ces trois niveaux sont les suivants [CIZ, 2005] :
IPv6 – étude et mise en œuvre Benoît de Mianville
12
une topologie publique allouée par le fournisseur d’accès;
une topologie de site. Ce champ permet de coder les numéros de sous réseau du site;
un identifiant d'interface distinguant les différentes machines sur le lien.
On parle alors de scope global, scope site et scope local. Une adresse unicast est ainsi composée de
ces scopes, voir la représentation ci-dessous.
Figure 7 : address format, [rfc3587]
L’IANA, Internet Assigned Numbers Authority assigne des blocs d’adresses aux registres régionaux et
ceux-ci répartissent des sous-blocs d’adresses aux FAI, ce sont les FAI qui déterminent le scope global
(global routing prefix).
Le scope site (subnet ID) est l’identifiant du sous réseau du site et le scope local (interface ID)
identifie les machines au sein d’un segment ; ces 64 derniers bits d’une adresse peuvent être
attribués de différentes manières : par le système d’exploitation en utilisant l’adresse MAC de la
carte réseau ou de manière aléatoire, en DHCP ou manuellement.
Attribution avec la méthode EUI-64 :
Une adresse MAC est composée de 4 mots de 12 bits notés en hexadécimal, elle est composée au
total de 48 bits :
« Mot 1 : mot 2 : mot 3 : mot 4 »
Remarque : sous Windows les adresses MAC sont affichées sous la forme de 6 mots de 8 bits.
On aura également besoin de s’intéresser au bit U/L de l’adresse MAC, c’est le 7ème bit du premier
octet qui indique, s’il est à 1 que l’adresse est administrée localement et s’il est à 0 que l’adresse est
gérée universellement (par le biais de l’IEEE qui a assigné un numéro unique à une organisation)4.
Pour construire la dernière partie de l’adresse IP avec la méthode EUI-64, on rajoute au milieu de
l’adresse MAC 16 bits qui ont la valeur fffe :
Mot 1 : mot 2 : 0xfffe : mot 3 : mot 4
Puis, on effectue le complément à un du bit U/L (si c’est un 1 on met 0, si c’est un 0 on met 1).
La structure résultante d’une adresse unicast est donc la suivante :
Figure 8 : structure d'une adresse Unicast
4
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true
IPv6 – étude et mise en œuvre Benoît de Mianville
13
Comme expliqué dans la partie précédente, les adresses global unicast attribuées pour l’instant par
l’IANA sont dans le bloc 2000 ::/3, on va s’intéresser aux trois premiers bits de l’adresse car le
masque est /3, on met 0x2 en binaire, cela donne 0010 et on retient les 3 premiers bits : 001 ;
maintenant on sait que les adresses unicast commencent par 001 en binaire.
5.5 Autres types d’adresse Explications tirées de [CIZ, 2005]
Adresse indéterminée
L’adresse indéterminée (unspecified address) est utilisée comme adresse source par un nœud du
réseau pendant son initialisation, avant d’acquérir une adresse. Sa valeur est 0:0:0:0:0:0:0:0 (en
abrégé ::).
Cette adresse est utilisée uniquement par des protocoles d’initialisation, elle ne doit jamais être
attribuée à un nœud et ne doit jamais apparaître comme adresse destination d’un paquetIPv6.
Adresse de bouclage
L’adresse de bouclage (loopback address) vaut 0:0:0:0:0:0:0:1 (en abrégé ::1). C’est l’équivalent de
l’adresse 127.0.0.1 d’IPv4. Elle est utilisée par un nœud pour s’envoyer à lui-même des paquets
IPv6.
Un paquet IPv6 transitant sur le réseau ne peut avoir l’adresse de bouclage comme adresse source ni
comme adresse destination.
Adresse ipv6 mappant adresse ipv4
Ce type d’adresse est utilisé pour que les applications puissent utiliser les adresses IPv6 comme des
adresses IPv6 et les adresses IPv4 comme des adresses IPv6, cela simplifie les applications qui
fonctionnent avec deux piles IP (v4 et v6).
Le format de ces adresses implique que les premiers 80 bits soient fixés à zéro, les 16 suivants à un,
alors que les 32 bits restants représentent une adresse IPv45.
Exemple :
L’adresse IPv6 « ::ffff:c000:280 » représente l’adresse IPv4 « 192.0.2.128 » et peut aussi être écrit
sous la forme « ::ffff:192.0.2.128 » où la partie représentant l’adresse IPv4 est en décimal tandis que
le reste est en hexadécimal.
5.6 Entête Voici ci-dessous le format de l’entête des paquets IPv6.
5 http://fr.wikipedia.org/wiki/Adresse_IPv6_mappant_IPv4
IPv6 – étude et mise en œuvre Benoît de Mianville
14
Figure 9 : entête IPv6 [CIZ, 2005]
La taille de l’entête atteint 40 octets, le double de celui d’IPv4 cependant des mécanismes ont été
mis en place afin de simplifier le traitement des entêtes par les routeurs :
La fragmentation n’est plus assurée par les routeurs, dans le cas d’une MTU6 trop grande, le
paquet n’est pas routé (transmis par le routeur) et le routeur indique à l’émetteur la MTU à
appliquer par le biais d’ICMP.
Les options sont mises dans le champ données.
L’identificateur de flux permet de ne regarder que ce champ pour router dès le deuxième
paquet, c’est très efficace, c’était utilisé de manière « artisanale» avec IPv4. Cependant la
façon dont les constructeurs vont l’utiliser n’a pas encore convergé.
La taille des entêtes est fixe.
5.7 ICMP v6 Tout comme dans IPv4, le protocole de contrôle ICMPv6 permet la détection d’erreurs, les tests et la
configuration automatique des équipements ; la différence avec ICMPv4 réside dans la meilleure
structuration du protocole, l’intégration d’ARP pour IPv4 et l’ajout de la détection d’inaccessibilité
des voisins, de la découverte des préfixes et de la découverte des paramètres. Des nouveautés ont
été également apportées au niveau de la gestion de la mobilité et de la sécurisation de l’échange de
certains messages d’auto configuration (appelé SEND).
Parmi les fonctions de détection d’erreurs et de configuration automatique, un groupe de
fonctionnalités est appelé « découverte des voisins », il permet les sous fonctions suivantes :
La résolution d’adresses,
la détection d’inaccessibilité des voisins,
la découverte des routeurs,
6 MTU – Maximum Transmission Unit est la taille maximale d’un paquet IP c’est-à-dire de l’entête IP et de ses
données, il peut varier sur chaque équipement qui traite les paquets IP.
IPv6 – étude et mise en œuvre Benoît de Mianville
15
la découverte des préfixes,
la détection des adresses dupliquées,
la découverte des paramètres,
les indications de redirection
5.7.1 Auto configuration
Il est possible avec IPv6 que le routeur annonce aux terminaux le préfixe réseau utilisé pour que
ceux-ci s’auto-configurent. Dans ce cas un serveur (qui peut être le routeur mais pas exclusivement)
va émettre régulièrement le préfixe du réseau via le message ICMP « annonce du routeur », type
134 ; ce message va indiquer si les adresses doivent être obtenues via DHCP, si ce n’est pas le cas les
machines vont concaténer le préfixe annoncé avec leur identifiant de machine (64 derniers bits de
leur adresse locale). Le message d’annonce du routeur va également indiquer la durée de vie et la
durée préférée de l’adresse car une interface peut avoir plusieurs adresses et le paramètre « durée
préférée » est utile dans le cas de la transition d’une adresse vers une autre, le schéma ci-dessous
décrit les états successifs d’une adresse sur une interface [CIZ, 2005] :
Figure 10 : états successifs d’une adresse sur une interface
Par défaut, Valid Lifetime (VT) = 30 jours et Prefered Lifetime (PT) = 7 jours [RFC2461].
En annexe sont présentés des exemples de configuration d’auto configuration sur un routeur Cisco,
une machine Linux et une machine Windows.
5.8 Problème de sécurité de l’auto configuration Avec IPv4, on maitrise le processus de distribution des adresses via DHCP et si on veut on peut filtrer
les messages DHCP dans les équipements de niveau 2 et également les messages BOOTP. Avec IPv6
et la configuration sans état, c’est plus délicat car un hôte mal intentionné peut diffuser des
annonces de préfixe (RA – Router Advertisement) et ainsi fausser le routage. La solution à ce
problème peut être d’utiliser IPv6 de la même manière qu’IPv4 en utilisant DHCPv6 mais cela n’est
pas optimal dans les très grands réseaux et dans les réseaux très dynamiques. En outre pour pouvoir
bénéficier de la configuration sans état sans sacrifier la sécurité, une autre solution est de filtrer dans
les équipements de niveau 2 les annonces de préfixe RA, cela implique d’investir dans des switchs
ayant des fonctions de filtrage propres à ICMPv6 comme spécifié dans le brouillon de l’IETF intitulé
« IPv6 Autoconfig Filtering on Ethernet Switches7 ». Cela ajoute un facteur négatif au déploiement
d’IPv6 dans les entreprises mais il faut seulement réfléchir aux architectures actuelles et à leurs
niveaux de sécurité : filtre-t-on actuellement de manière systématique le protocole DHCP sur les
ports d’accès des switchs ? En l’occurrence (en général) ce n’est pas le cas donc il faut évaluer les
exigences de sécurité du réseau avant d’introduire ce filtrage.
7 http://tools.ietf.org/html/draft-nward-ipv6-autoconfig-filtering-ethernet-00
IPv6 – étude et mise en œuvre Benoît de Mianville
16
5.9 DHCP DHCPv6 est un protocole client serveur qui permet de centraliser la distribution d’informations de
configuration réseau des clients. Il faut retenir que ce n’est pas DHCP, le protocole de configuration
avec état ou l’auto configuration sans état qui distribue les informations de routage, c’est la
procédure de découverte des routeurs d’ICMPv6 qui en a la charge.
Dans les échanges qui seront effectués, afin que le serveur DHCP puisse identifier le client, un
identifiant nommé DUID propre au client sera utilisé, il est généré par le client, cet identifiant est
propre au client et non pas à une de ses interfaces.
Voici ci-dessous un exemple d’échange d’informations entre un client et un serveur :
Machine cliente DHCPv6 Serveur DHCPv6
Sollicitation DHCP
Annonce DHCP
Requête
Réponse
Figure 11 : exemple d’échange DHCPv6 classique
Le client envoie les requêtes vers le port 547 et recevra les réponses par le port 546, les échanges
reposent sur UDP et la fiabilité est assurée par le fait que le client répète ses messages jusqu’à
obtenir une réponse en attendant un timeout.
Le client envoie en premier lieu une sollicitation vers l’adresse FF02::1:2 qui est l’adresse multicast de
tous les agents DHCP, en effet dans le cas ou le serveur n’est pas sur le même segment que le client,
on peut utiliser des relais, l’adresse multicast FF02::1:2 concerne les serveurs et les relais. Le serveur
répond et le client peut faire une requête en spécifiant les options souhaitées et enfin, le serveur
répond avec les options.
Nous pouvons réfléchir à l’utilité de DHCPv6 en nous basant sur le principe que IPv6 dispose de
beaucoup d’adresses, de tellement d’adresses qu’il est nécessaire de changer complètement les
habitudes prises avec IPv4 d’économiser des adresses, d’optimiser au mieux le plan d’adressage.
DHCP pour IPv4 a été une des techniques utilisée pour pallier à la pénurie d’IPv4 ; avec IPv6 l’objectif
n’est pas le même, on a au sein d’un plus petit sous réseau, /64 pas moins de 2^64 combinaisons
d’adresses possibles donc on peut envisager que les adresses distribuées peuvent être gardées de
manière pérenne par les clients. Si on n’a pas besoin de gérer finement les baux d’adresses, on a
alors la possibilité de se délester d’un protocole avec état comme DHCP au profit de l’auto
configuration sans état ; celle-ci était insuffisante jusqu’à 2010 car on ne pouvait distribuer les
adresses IP des serveurs de nom de domaine, ce n’est plus le cas avec le RFC 6106 qui le permet.
IPv6 – étude et mise en œuvre Benoît de Mianville
17
Cependant et malgré l’enthousiasme des chercheurs et des professionnels rédigeant les RFC, le plus
important dans la vie d’une norme n’est pas sa création mais son adoption, concernant le RFC 6106
qui permet de se passer d’un serveur DHCP pour diffuser les adresses IP des serveurs DNS, il n’est
actuellement pas supporté par Microsoft Windows et n’est malheureusement pas à l’ordre du jour8,
selon Christopher Palmer, un professionnel de Microsoft.
En ce qui concerne les implémentations de DHCP, sur Linux on a isc-dhcp, pour Windows à partir de
Server 2008 un serveur DHCPv6 est intégré 9 , Une solution open source Linux/Windows est
disponible : dibbler10.
5.10 Sécurité Etant donné que les communications en IPv6 se (re)font de pair à pair, cela signifie que tous les
terminaux sont directement exposés à Internet, on peut alors adapter les règles NAT des pare feu qui
sont implicitement des règles de filtrage à des règles pour IPv6 mais c’est un travail de longue
haleine, on peut alors s’adapter à IPv6 en adoptant des FW ayant un comportement nativement
adapté à IPv6.
En terme de sécurité les implémentations actuelles d’IPv6 ne sont pas suffisamment utilisées pour
pouvoir y détecter des failles de sécurité et les modifier rapidement, en outre le groupe « The
Hacker’s Choice » propose des outils11 très aboutis pour tester la sécurité d’un réseau IPv6, voici un
extrait de ces outils :
- parasite6: icmp neighbor solitication/advertisement spoofer, puts you as man-in-the-middle, same as ARP mitm (and parasite) - alive6: an effective alive scanng, which will detect all systems listening to this address - dnsdict6: parallized dns ipv6 dictionary bruteforcer fake_router6: announce yourself as a router on the network, with the highest priority - redir6: redirect traffic to you intelligently (man-in-the-middle) with a clever icmp6 redirect spoofer - toobig6: mtu decreaser with the same intelligence as redir6 - detect-new-ip6: detect new ip6 devices which join the network, you can run a script to automatically scan these systems etc. - dos-new-ip6: detect new ip6 devices and tell them that their chosen IP collides on the network (DOS). - trace6: very fast traceroute6 with supports ICMP6 echo request and TCP-SYN
Tableau 6 : extrait des outils thc ipv6
Les attaques qui seront ou sont probablement effectuées sont dans un premier temps les même que
pour IPv4, transposées, dans le cas où l’attaquant à accès au LAN, il est possible à une machine de se
faire passer pour un routeur en répondant aux sollicitations de routeurs ou en envoyant des
annonces de routeur.
La solution à ce dernier type d’attaque est d’utiliser la version sécurisée du protocole de découverte
des voisins appelée SEND – Secure Neighbor Discovery, celui-ci utilise des principes de cryptographie
dans les adresses IP pour que deux nœuds puissent s’authentifier et avoir des échanges chiffrés et
8 http://social.technet.microsoft.com/Forums/en-US/ipv6/thread/5757980a-5983-4efc-a5f3-27687b90fe41
9 http://www.labo-microsoft.org/articles/IPv6_WindowsServer/3/Default.asp
10 http://klub.com.pl/dhcpv6/
11 http://thc.org/thc-ipv6/
IPv6 – étude et mise en œuvre Benoît de Mianville
18
intègres entre eux ; malheureusement à l’heure actuelle ce protocole n’est pas adopté largement par
les constructeurs et les éditeurs logiciels.
Une autre solution consiste à filtrer les messages indésirables sur les équipements de niveau 2, les
switches, on peut par exemple ne pas autoriser les annonces de routeurs sur les ports d’accès.
IPv6 – étude et mise en œuvre Benoît de Mianville
19
6 2SI et IPv6 2SI gère les réseaux, les systèmes et les systèmes d’informations de ses clients, dans ce rôle, il est
concerné par les évolutions nécessaires au bon fonctionnement de ces installations et notamment
par la manière dont IPv6 va devoir être déployé.
Avant le démarrage du projet IPv6 il n’y avait pas d’étude spécifique déjà réalisée, la valeur ajoutée
préexistant de 2SI dans ce domaine est la forte expérience des installations en IPv4 de tailles
diverses, de domaine et de criticité divers, ce qui permet de préparer au mieux les cas de figures du
déploiement d’IPv6.
Les différentes structures des clients vont des cabinets de taille humaine, aux industries, et aux
organisations multi sites sur toute la France, les services utilisés sont en majeur partie les accès au
web, la téléphonie IP et l’accès à des applications en mode hébergé ; les services chez les clients sont
des serveurs web, des serveurs d’applications, de base de données. Les organisations multi sites sont
reliées par des tunnels sécurisés. Ces différentes structures nécessitent une attention particulière
afin d’étudier l’impact du déploiement d’IPv6 au sein des réseaux locaux, des services hébergés et
d’élaborer des méthodes de déploiement.
Afin de conseiller au mieux ses clients dans le déploiement d’IPv6, 2SI doit étudier cette nouvelle
technologie, la mettre en œuvre au sein de son propre réseau dans un cas simple d’accès aux
services d’Internet et dans des cas plus complexes d’hébergement de services au sein
d’infrastructures complexes faisant appel à la redondance et à la virtualisation.
IPv6 – étude et mise en œuvre Benoît de Mianville
20
7 Planning du projet IPv6 est une technologie nouvelle que ni moi ni 2SI n’avions déjà mise en œuvre dans un
environnement de production, une première phase d’analyse à été nécessaire pour pouvoir
envisager le futur de ce projet, l’objectif à court terme a donc été de me former moi-même puis de
former l’équipe technique composée de 13 personnes et enfin sensibiliser l’équipe commerciale.
La phase d’analyse ayant été concluante, nous avons pu voir à plus long terme les impacts du
déploiement d’IPv6 et nous avons décidé de déployer un site pilote reflétant les techniques
nécessaires à maitriser pour le déploiement dans les infrastructures des clients, ceci a conduit à
choisir de déployer dans une première phase la partie réseau interne du réseau de 2SI à Soissons
c’est-à-dire les postes qui ont accès à Internet puis dans une seconde phase à rendre accessible les
services hébergés à Soissons via IPv6 en commençant par un service simple comme DNS ou un site
web.
Le troisième temps sera consacré à l’utilisation des résultats du site pilote pour mettre au point des
outils de vente pour les commerciaux, des offres puis former les commerciaux.
Le planning est représenté au format Gant ci-dessous.
IPv6 – étude et mise en œuvre Benoît de Mianville
21
Figure 12 : planning février à mai 2012
Figure 13 : planning juin juillet 2012
IPv6 – étude et mise en œuvre Benoît de Mianville
22
8 Comment mettre en œuvre IPv6 Nous allons ici aborder les manières possibles de déployer IPv6 dans les réseaux d’entreprises,
l’objectif est que les machines utilisateurs aient accès à l’internet IPv6 et que les serveurs soient
accessibles via l’internet IPv6. Il est possible de mettre directement IPv6 sur les machines utilisateurs
et serveurs et de prendre un FAI fournissant IPv6. Cependant IPv4 est toujours d’actualité et la
meilleure méthode est de garder IPv4, et de rajouter sur les machines en même temps un accès IPv6.
Cela peut se faire de manière naturelle en donnant une adresse IPv6 à chaque machine terminale ou
bien en laissant les machines en IPv4 et en rajoutant dans le réseau un élément de translation d’IPv4
vers IPv6 et d’IPv6 vers IPv4 ; dans cette partie ces deux méthodes sont expliquées techniquement
puis un état actuel de ce que proposent certains FAI en terme d’IPv6 est détaillé. Enfin des méthodes
adaptées sont étayées pour comprendre comment déployer IPv6 et pour compléter, une partie
détaille les attentions à avoir en ce qui concerne le matériel puis une autre partie détaille les autres
techniques de cohabitation d’IPv6 avec IPv4.
8.1 Techniques les plus utilisées
8.1.1 La double pile
Les équipements ont la pile IPv4, comme ils l’avaient auparavant mais ils ont aussi la pile IPv6, c’est
une solution souvent disponible pour les postes de travail et les équipements réseau.
Exemple sur Windows :
Figure 14 : sortie de la commande IPconfig sur un poste Windows
La copie d’écran ci-dessus nous montre la configuration IP d’une machine Windows, celle-ci a une
couche IPv4 avec 2 adresses et une passerelle, et une adresse IPv6, elle peut tout a fait sur la même
interface, communiquer en même temps avec un équipement en IPv4 et un autre en IPv6.
Ce type de technique est assez fréquent sur les équipements terminaux comme les ordinateurs, les
tablettes et les smartphones mais aussi les imprimantes ; les équipements réseaux comme les
routeurs et les pare feux ont aussi une pile IPv6 en plus de la couche IPv4 qui est en moyenne moins
aboutie que la couche IPv4 à ce jour.
L’avantage de cette technique est la possibilité d’avoir les deux « Internet » en parallèle et de ne pas
présenter de complexité à mettre en œuvre, en effet on laisse la couche IPv4 telle quelle et on
déploie la couche IPv6 qui n’a pas de changement fondamental dans sa mise en œuvre par rapport à
IPv4.
L’inconvénient de cette technique réside dans le fait qu’une adresse IPv4 publique est toujours
nécessaire dès lors qu’un hôte effectue une communication qui passe par Internet, cela ne résout
IPv6 – étude et mise en œuvre Benoît de Mianville
23
donc pas le problème de pénurie d’adresses ; l’autre inconvénient est la double charge de la
configuration des routeurs à la fois pour IPv4 et IPv6.
8.1.2 La traduction d’adresses – NAT-PT, NAT-64 et DNS-64
NAT-PT est un mécanisme qui permet à un réseau uniquement IPv6 d’interagir avec des équipements
IPv4 et vice versa. On utilise un boitier qui peut être un routeur ou un ordinateur avec un logiciel
spécifique, celui-ci fait correspondre des adresses IPv6 à des adresses IPv4 lorsqu’un équipement v6
veut communiquer avec un v4. Les équipements raccordés en v4 ou en v6 n’ont besoin d’aucun
paramétrage particulier.
Il devient donc possible de rendre accessible via IPv6 toute une infrastructure hébergeant des
services bien que les services soient à l’origine en IPv4 et le restent. Les communications depuis
l’extérieur vers l’infrastructure peuvent se faire en IPv4 comme auparavant ou en IPv6 via la
traduction d’adresses.
Il est à noter que le protocole NAT-PT a été classé comme déprécié par le RFC 4966, dont voici les
raisons :
NAT-PT est considéré comme un mécanisme de transition vers IPv6 et en aucun cas il ne doit limiter
les possibilités de communications qu’offre IPv6 ; les applications qui utilisent les adresses IP ne
peuvent pas fonctionner ; dans le cas du NAT dynamique, on a moins d’adresses IPv4 que d’adresses
IPv6 et sans une gestion fine des timeout on pourrait avoir un manque d’adresses IPv4 ; il peut y
avoir des pertes d’informations étant donné que des nouveaux champs sont apparus avec IPv6
comme flow label ou encore des extensions que l’on ne peut pas translater comme les entêtes de
routage ou de mobilité ; concernant ICMPv6, il y a des nouvelles fonctionnalités, celles-ci ne sont pas
rétro compatibles ; au niveau de la sécurité il est possible de surcharger les mémoires qui font la
correspondance avec les translations avec des attaques de déni de service ; enfin, des
incompatibilités sont présentes avec le mécanisme de DNS.
C’est pour ces raisons que l’IETF a choisi de classer comme déprécié NAT-PT, pour éviter de le
déployer à grande échelle en causant beaucoup d’incompatibilité ; seulement il est dit que si NAT-PT
est utilisé dans des cas particuliers où les problèmes cités ont été considérés et ne sont pas présents,
alors NAT-PT est une solution envisageable.
Plus récemment, en Avril 2011, a été publiée la norme décrivant ledit successeur de NAT-PT : NAT 64,
RFC 6146. Pour mémoire, l’IETF conseillait de ne pas utiliser la translation comme mécanisme de
transition à IPv6, la solution conseillée était d’activer IPv6 en laissant IPv4 et, petit à petit, de
désactiver IPv4 ; seulement le déploiement d’IPv6 a été repoussé et il est maintenant trop tard pour
faire une transition « douce »12, la translation redevient une nécessité et NAT 64 apporte son lot de
nouveautés pour corriger les défauts de NAT-PT évoqués précédemment avec notamment DNS 64
qui apporte des nouvelles fonctionnalités et corrige des défauts concernant le mécanisme DNS,
cependant la translation reste toujours contraire à l’un des principes fondamentaux d’IP : la
communication directe de pair à pair.
Pour synthétiser nous avons une solution de translation qui permet à des hôtes uniquement IPv6 de
joindre des hôtes uniquement IPv4 et vice versa : NAT-PT. Nous avons une solution plus orientée, 12
http://www.bortzmeyer.org/6144.html
IPv6 – étude et mise en œuvre Benoît de Mianville
24
NAT 64 couplée à DNS 64 qui permet à des hôtes uniquement IPv6 sur un site donné de joindre des
hôtes IPv4 à l’extérieur de ce site, ce mécanisme est expliqué dans la partie suivante. Il faut noter
que NAT-PT a été classé comme déprécié pour le cas précis où on veut rendre accessibles des
serveurs IPv4 via IPv6 ; on note cependant que c’est tout à fait utilisable à moyen terme, le temps
que les méthodes, les solutions et les implémentations d’IPv6 se peaufinent.
DNS64 permet à un hôte uniquement en IPv6 de communiquer avec un serveur uniquement IPv4 ; le
client IPv6 interroge un serveur DNS qui lui renvoie soit :
Une adresse IPv6 si la requête DNS retourne un enregistrement IPv6
Une adresse IPv6 mappant IPv4 si la requête DNS retourne seulement un enregistrement
IPv4 (c’est ce qui est illustré par le point « a » dans la figure ci-dessous)
Dans le cas où l’adresse IPv6 retournée est classique, le mécanisme de translation n’est pas
nécessaire et les paquets peuvent être routés classiquement.
Dans le cas où une adresse IPv6 mappant IPv4 est retournée, le routeur effectuant du NAT-64 qui a
été paramétré en accord avec le serveur DNS 64 réalise une translation de l’adresse IPv6 vers
l’adresse IPv4 contenue dans l’adresse IPv6 mappant IPv4 ; cette adresse est à un format reconnu
avec le préfixe 64:ff9b::/96 définit dans le RFC 6052. Au retour l’équipement de translation fait
l’opération inverse, un exemple simple de cette communication entre un client IPv6 et un serveur
IPv4 est illustré ci-dessous.
IPv6
IPv4
Client
www.orange.fr193.252.122.103
Internet IPv6
Internet IPv4
3
4
6
5
Serveur DNS avec DNS64
NAT64
1
2
www.orange.fr IN AAAA 64:ff9b::193.252.122.103a
Figure 15 : illustration du mécanisme DNS64 et NAT-64
Nous avons donc deux solutions concrètes pour déployer IPv6 de manière rapide sans engendrer de
problème à grande échelle. L’avantage de ces solutions vient du fait qu’on n’a aucun paramétrage à
faire sur les postes clients ou sur les serveurs.
IPv6 – étude et mise en œuvre Benoît de Mianville
25
Voici la liste des systèmes dans lesquels a été introduite la fonctionnalité NAT-PT pour le
constructeur Cisco :
Figure 16 : liste des systèmes dans lesquels NAT-PT a été introduit pour le constructeur Cisco13
On peut voir qu’on a en premier lieu une translation simple de 1 vers 1 (une adresse IPv4 vers une
adresse IPv6) au niveau de la couche IP avec le NAT-PT et que l’on a également une translation de 1
vers n (une adresse IPv6 vers n adresses IPv4) avec la version Overload où l’on fait également de la
translation de ports. On a également un serveur DNS intégré avec la version DNS ALG puis un support
pour le protocole de transfert de fichier FTP et un support pour les problèmes de taille de données
utiles et de fragmentation.
En ce qui concerne la norme plus récente NAT-64 et DNS-64, Cisco ne le propose que dans des
solutions de hautes performances dédiées aux opérateurs, les plateformes Cisco ASR 1000 et 1001, le
tableau ci-dessous détaille les deux fonctionnalités Stateless NAT-64 et stateful NAT-64.
13
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1057128
IPv6 – étude et mise en œuvre Benoît de Mianville
26
Fonctionnalité Logiciel dans lequel la fonctionnalité a été introduite
Détails
Stateless Network Address Translation 64
Cisco IOS XE Release 3.2S Détails14
Stateful Network Address Translation 64
Cisco IOS XE Release 3.4S Voir Cisco feature navigator15
Figure 17 : Disponibilité de NAT-64 sur les équipements Cisco
Des solutions open source existent, deux exemples sont cités ci-dessous.
Solution Fonctionnalité Plateforme Lien vers le site
TAYGA NAT-64 sans DNS, sans translation de ports
Linux http://www.litech.org/tayga/
Ecdysis NAT-64 avec DNS-64 Linux http://ecdysis.viagenie.ca/ Figure 18 : exemples de solutions open source NAT-64
Nous pouvons donc maintenant dresser un tableau comparatif des différentes solutions, j’ai rajouté
des autres solutions commerciales concurrentes à Cisco.
Solution Tarif indicatif Fonctions de translation
Cisco ASR 100 et 1001 A partir de 10 000€ NAT-64 stateless et stateful
Cisco avec IOS 12.2(13)T et plus
A partir de 800€ NAT-PT
Equilibreur de charge A10 Networks
De 20 000 à 200 000€ NAT-64 stateless et stateful
Equilibreur de charge Big IP F5
A partir de 1 500€ NAT-64 stateless et stateful
TAYGA Open source NAT-64 stateless
Ecdysis Open source NAT-64 stateless et stateful Figure 19 : comparatif de plusieurs solutions de translation
8.2 Offre des FAI A l’heure actuelle la disponibilité du protocole IPv6 chez un FAI - Fournisseurs d’Accès à Internet
n’est pas un critère de premier plan, ce n’est pas important pour les particuliers car le passage à IPv6
sera transparent pour eux et ça peut être un critère de second plan pour des grandes organisations
soucieuses de préparer progressivement le déploiement. Cependant il est crucial pour les FAI d’être
prêt à fournir de la connectivité IPv6 à leurs clients pour ne pas être en retard lors du début de
l’adoption massive, c’est pour cela qu’un FAI comme NERIM s’est intéressé depuis 2002 à cette
technologie et fourni une connectivité IPv4 et IPv6 native avec un masque /48 permettant 216
combinaisons de sous réseaux possible : (65536), cela est inclus dans toutes ses offres DSL et fibre
optique . Orange fournit également la connectivité IPv6 pour les professionnels depuis fin 2011, le
tarif est à la demande et free fournit également de la connectivité IPv6 mais n’offre pas de services
dédiés aux professionnels comme des garanties de temps de rétablissement ou un support technique
dédié. Le tableau ci-dessous présente les offres de FAI sélectionnés pour leurs tarifs et leurs
caractéristiques différentes.
14
http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html 15
http://tools.cisco.com/ITDIT/CFN/jsp/by-feature.jsp
IPv6 – étude et mise en œuvre Benoît de Mianville
27
FAI Nerim Orange Free
Offre IPv4/IPv6 dans toutes
ses offres IPv4/IPv6 mais pas en
collecte ADSL IPv4/IPv6 en ADSL
Surcoût pour IPv6 Pas de surcoût
Surcoût de 13€ mensuel + 2000€ à
l’installation pour une offre particulière avec
un lien de secours16
Pas de surcoût
Services aux professionnels
Oui Oui Non
Tableau 7 : offre IPv6 de trois FAI
8.3 Méthodes adaptées Il n’y a pas de méthode unique pour réussir le déploiement d’IPv6, il y a des méthodes adaptées aux
spécificités des infrastructures, par exemple, pour rendre disponible via IPv6 des services comme un
serveur DNS, un serveur Web etc. on pourrait mettre en route la pile IPv6 de chaque serveur et
tester le service mais cela demande un investissement proportionnel à la taille de l’infrastructure,
multiplié par le nombre de systèmes d’exploitations différents qui sont parfois virtuels et qui
reposent sur des hyperviseurs17, on doit aussi tester chaque application et cela a un coût. Au lieu de
ça et sauf si on a une petite infrastructure, on peut faire appel à la traduction d’adresses (NAT 64)
pour laisser l’infrastructure en IPv4 et laisser le boitier de traduction se charger des requêtes IPv6,
cette solution peut être mutualisée et alors une société de service fera fonctionner son boitier de
traduction pour rendre disponible via IPv6 les services de ses clients.
Outre la traduction d’adresses pour les services, il faut, si possible louer ses adresses IPv6
directement au registre pour ne pas dépendre du FAI, on donnera alors nos adresses IPv6 au FAI qui
se chargera de rediriger le trafic vers notre routeur, cela n’est utile que dans le cas ou on a des
serveurs.
Pour un client n’ayant pas de services hébergés qui a juste besoin d’un accès à internet comme le
web, on peut mettre en place un accès ADSL classique en IPv6/IPv4, l’opérateur attribuera un préfixe
et si on change d’opérateur, on changera de préfixe mais ce n’est pas important, il suffira de
configurer le service router-advertisement ou DHCP pour distribuer les adresses. On pensera à des
FAI pour lesquels IPv6 est en place depuis quelque temps comme free ou encore Nerim si on a besoin
de SDSL18 ou de garanties comme la garantie de temps de rétablissement.
Pour un client ayant des petits services hébergés comme un serveur web, un serveur de mail et
d’autres services, le temps d’analyse et de déploiement d’IPv6 peut être important et il est
intéressant dans ce cas d’opter pour une solution de traduction d’adresses mutualisée. Le client
ayant généralement une partie du réseau pour l’accès des utilisateurs à Internet, ce réseau
reprendra le schéma décrit dans le paragraphe précédent.
16
Ce tarif fait référence à une étude de faisabilité et de coût réalisée à notre demande par Orange. 17
La tendance il y a quelques années était à la virtualisation des serveurs, les machines sont alors virtuelles et sont exécutées sur un système d’exploitation que l’on appelle hyperviseur ; c’est aujourd’hui une réalité et très répandu jusqu’aux petites infrastructures qui contiennent 4 à 6 serveurs. 18
SDSL : ce type de liaison assure le même débit dans les deux sens contrairement à une ligne ADSL qui a généralement un faible débit montant pour privilégier le fort débit descendant ; lorsqu’on dit montant, cela signifie vers le FAI.
IPv6 – étude et mise en œuvre Benoît de Mianville
28
Pour un client ayant des moyens à gros services hébergés, on peut toujours faire appel au service de
traduction d’adresses mutualisé ou bien si on n’a pas envie de dépendre d’un intermédiaire, on peut
mettre en place une solution interne de translation NAT 64 grâce à un équipement dédié (routeur
Cisco,…), avec la translation en interne, on publiera des adresses IPv6 désignant nos services et la
situation la plus agréable de fonctionner est d’obtenir des adresses IPv6 indépendantes d’un FAI, cela
est possible auprès du RIPE NCC comme expliqué précédemment. La dernière variante serait de
déployer intégralement IPv6 sur tous les services sans translation mais cette solution peut être
complexe et n’a pas été choisie par exemple par Facebook pour ses serveurs19.
8.4 Quel matériel Dans cette partie sont décrites selon les différents cas de déploiement d’IPv6 les questions à se poser
sur le matériel informatique à utiliser que ce soit les terminaux des utilisateurs, les serveurs ou les
équipements réseaux.
8.4.1 Les terminaux des utilisateurs
On pourra regarder la liste des équipements terminaux pour vérifier leur compatibilité à IPv6, à
savoir :
Les PC
Les clients légers
Les tablettes
Les Smartphones s’ils se connectent en Wifi
En ce qui concerne les PC il faut savoir que les systèmes d’exploitation suivants sont compatibles
IPv6 :
Windows
o compatible avec manipulation à partir de Windows 2000/XP
o compatible nativement à partir de Windows Vista/7
Mac OS
o A partir de Mac OS X 10.5
Linux
o noyau 2.4 compatible
o noyau 2.6 conseillé en production
En ce qui concerne les Smartphone, les systèmes suivants sont compatibles :
iPhone
o à partir de l’iOS 4
BlackBerry et android
o Suivant les modèles
8.4.2 Les serveurs
Si on suit la méthode de déploiement avec un boitier de translation, on s’épargne la nécessité de
gérer IPv6 nativement sur les serveurs, cependant si on a besoin de serveur DHCP ou de solutions
19
Propos recueilli lors du séminaire « Préparation au World IPv6 launch ».
IPv6 – étude et mise en œuvre Benoît de Mianville
29
spécifiques, la liste ci-dessous présente les compatibilités IPv6 des systèmes d’exploitation
rencontrés sur les serveurs.
Windows
o compatible avec manipulation à partir de Windows 2000/2003
o compatible nativement à partir de Windows Server 2008
Linux
o Compatible nativement à partir du noyau 2.4, noyau 2.6 recommandé en production
VMWare
o ESX3.5 supporte les hôtes en IPv6
o ESX 4.0 est compatible IPv6 avec des restrictions20 :
Stockage iSCSI et NFS expérimental
Pas de support de TCP Segmentation Offload (TSO)
Pas de support de la fonction haute disponibilité et tolérance aux pannes
o vSphere 521
o D’autres informations concrètes22
8.4.3 Equipements réseau de niveau 2 (commutation)
Il n’y a pas de changement pour les Switch, ceux-ci véhiculent des trames Ethernet et ils restent
compatibles. La seule raison d’une incompatibilité serait dans le cas où la sécurité exigerait un
filtrage des annonces de routeurs par les ports d’accès.
Le changement nécessaire peut aussi être présent si les Switch sont administrables par le réseau
(c’est souvent le cas) mais étant donné que le but est la double pile dans un premier temps, il sera
toujours possible d’administrer les Switch via IPv4 (pendant longtemps).
Pour les bornes Wifi, il faudra vérifier la compatibilité au cas par cas.
8.4.4 Pare feu et routeur
La plupart des grands constructeurs proposent des pare feu et des routeurs compatible IPv6, il n’est
cependant pas évident de dire aujourd’hui quels sont les meilleurs modèles et ceux à éviter étant
donné qu’ils n’ont pas encore été utilisés à grande échelle. Il faudra donc vérifier que les fonctions de
routage requises sont bien implémentées en IPv6, les fonctionnalités de qualité de service et les
possibilités de filtrage, tous les produits ne sont pas à égalité et seul des lectures attentives et des
tests permettront d’évaluer ceux-ci.
8.4.5 Translation NAT 64
Dans le cas où une translation est nécessaire, on pourra utiliser un boitier routeur / pare feu déjà
existant pour réaliser cette fonction ou bien utiliser un équipement dédié dans le cas de grosses
infrastructures, voici des exemples de constructeurs :
Cisco, avec ses routeurs propose la translation NAT-PT expliquée précédemment ;
20
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010812 21
https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html 22
http://vsphere-land.com/news/ipv6-support-in-vsphere.html
IPv6 – étude et mise en œuvre Benoît de Mianville
30
A10 Networks propose des boitiers d’équilibrage de charge pour des serveurs et également
une translation NAT-64 ;
Juniper et d’autres constructeurs proposent également des routeurs avec des fonctions de
translation NAT 64
8.5 Autres techniques
8.5.1 Tunnels
On parle de tunnel lorsqu’on réalise une encapsulation anormale. Par exemple, en temps normal, les
données utiles d’un paquet IPv4 doivent être de l’UDP ou du TCP, dans le cas d’un tunnel v6-in-v4 on
met un protocole de niveau 3 dans un protocole de niveau 3 et on peut parler de tunnel car c’est une
encapsulation anormale. Dans notre cas les tunnels sont un moyen de relier deux machines avec un
protocole IP version x alors qu’elles sont reliées par un réseau IP version y. On aura donc des tunnels
v6-in-v4 et v4-in-v6, ces derniers sont plus rares pour le moment, ils sont prévus dans le cas où un
réseau entièrement IPv6 aurait besoin d’accéder à des ressources IPv4.
Il existe des tunnels statiques et automatiques, les statiques sont configurés statiquement entre un
nœud et un autre tandis que les dynamiques utilisent des algorithmes qui après une configuration
permettent d’établir un tunnel dont le nœud de sortie pourra changer.
Les parties suivantes détaillent des techniques de tunnel qui peuvent être utiles dans certains cas,
cependant, les techniques de tunnel ne doivent être envisagées que lorsqu’une autre solution n’est
pas possible car ils introduisent une couche de complexité dans les couches protocolaires utilisées
ainsi que dans l’architecture réseau nécessaire.
8.5.1.1 Le Tunnel 6to4
Techniquement, 6to4 permet d’interconnecter des réseaux IPv6 isolés en créant des tunnels
automatiques qui encapsulent IPv6 dans IPv4. Grâce à cela, 6to4 permet deux cas de figure, il ajoute
la possibilité à une organisation d’accéder à l’Internet IPv6 même si son FAI ne fournit qu’une
connectivité IPv4 et il permet à un ISP de fournir un service minimum IPv6 à ses clients.
6to4 définit 3 types d’équipements :
La machine terminale 6to4, c’est l’utilisateur du service, celui qui a besoin d’Internet v6.
Le routeur de bordure, qui est connecté au réseau v6 des machines terminales et au réseau
v4 « Internet » ; c’est lui qui va encapsuler les paquets v4 dans des v6.
Le relais 6to4 qui permet d’atteindre l’internet v6, son adresse doit être connue des autres
équipements (il a une adresse anycast).
Le schéma ci-dessous représente une architecture faisant intervenir un tunnel 6to4 pour permettre à
un site relié par son FAI en IPv4 d’accéder aux ressources internet IPv6 :
IPv6 – étude et mise en œuvre Benoît de Mianville
31
Internet
IPv66to4
IPv6
Internet v6FAI en v4Relais IPv6
B (google.fr) C (ipv6.google.com)
DNS
Routeur de bordureA
Internet
IPv4
Figure 20 : tunnel 6to4
Un réseau configuré en 6to4 n’est pas directement relié à l’internet v6, en cela, en partie pour ne pas
complexifier les tables de routage de l’internet v6, un réseau en 6to4 doit avoir un plan d’adressage
en 2002 ::/16. Dans un réseau 6to4 on place l’adresse IPv4 du routeur de bordure dans le préfixe de
l’adressage IPv6 du site, ainsi on peut donner comme exemple l’adressage ci-dessous :
Internet
IPv66to4
IPv6
Internet v6FAI en v4Relais IPv6
B (google.fr) C (ipv6.google.com)
DNS
Routeur de bordureA
Internet
IPv4
15.0.0.0/29
.1 .2
2002:0f00:0001::/64
2002:0f00:0001::1
Figure 21 : adressage 6to4
A peut maintenant communiquer avec des machines IPv6 ou IPv4, pour envoyer un paquet à une
machine IPv6, il lui suffit de mettre l’adresse IPv6 de destination finale et le routeur de bordure
IPv6 – étude et mise en œuvre Benoît de Mianville
32
encapsulera en IPv4 le paquet IPv6 et l’enverra au relais IPv6. Pour envoyer un paquet à une machine
IPv4, A mettra l’adresse IPv4 du destinataire dans l’adresse IPv6 de la manière suivante :
Figure 22 : adresse 6to4
Lorsque A envoie un paquet avec une adresse de destination commençant par 2002 ::/16, le routeur
de bordure prend les données et les met dans un paquet IPv4 en prenant l’adresse IPv4 contenue
dans l’adresse 6to4 du paquet de A.
L’inconvénient de tunnel est l’introduction de délais supérieurs car dans le cas d’une communication
entre la machine dans le réseau 6to4 et une machine dans l’internet v6, la communication doit
passer par le relais, il est possible d’optimiser la distance entre la machine dans le réseau 6to4 et le
relais mais seulement la distance entre le relais et la machine dans l’internet v6 n’est pas contrôlable.
C’est pour cette raison qu’on peut utiliser plusieurs relais et que ceux-ci ont une adresse anycast.
Toutefois cette technique n’est pas la plus optimisée dans le cas ou on veut avoir des machines
uniquement en IPv6 qui communique avec l’Internet IPv6 et IPv4, on préférera la solution
précédemment expliquée NAT-64 et DNS-64 qui est plus « native » pour IPv6 et optimisée car
l’équipement de translation est toujours sur le même site que les machines.
8.5.1.2 Tunnel Broker
Le système tunnel broker permet à un réseau ou un hôte isolé d’avoir un accès IPv6 à travers un
réseau IPv4, le protocole TSP – Tunnel Setup Protocol permet de donner des méthodes de gestion
des tunnels et il définit plusieurs composants :
Internet IPv4Internet IPv6
Tunnel broker
1
2
3
4
Tunnel server
Figure 23 : composants de TSP - Tunnel Setup Protocol
Dans un premier temps le client se connecte au serveur de tunnel (1), celui-ci configure le tunnel (2)
puis envoie les paramètres au client (3), le client a alors ces paramètres :
IPv6 – étude et mise en œuvre Benoît de Mianville
33
Adresse IPv6 du client : c’est le « tunnel server » qui fait vivre cette adresse puisque le client
n’a pas d’interface avec une adresse IPv6.
L’adresse IPv4 du « tunnel server » : c’est l’adresse à laquelle le client doit envoyer ses
paquets IPv6, elle correspond à la sortie du tunnel ; cette adresse est souvent de type
anycast pour que le client puisse joindre le serveur le plus proche.
8.5.2 Fournisseurs de tunnel
Des sociétés proposent des solutions commerciales de tunnel pour des particuliers ou des
opérateurs, il existe également des organismes qui proposent des solutions gratuites de tunnel pour
que des sites isolés en IPv4 puissent avoir accès à IPv6, ces solutions existent pour la plupart car elles
permettent à des sociétés de télécommunications de se faire connaitre, voici les solutions gratuites
les plus connues :
Solution Type Site Détails
Hurricane Electric, opérateur télécom, Etats-Unis
Tunnel IPv6 dans IPv4 http://tunnelbroker.net/ Fournit un réseau /48
Sixxs, organisme privé, Suisse
Tunnel IPv6 dans IPv4 http://www.sixxs.net Fournit un réseau /48
Gogo6, société de services en réseaux, Canada
Tunnel IPv6 dans IPv4 http://www.gogo6.com/ Fournit un logiciel simple et un réseau /56
Figure 24 : Fournisseurs de tunnels IPv6 non commerciaux
8.5.3 Autres tunnels
D’autres tunnels existent notamment :
ISATAP – Intra-Site Automatic Tunneling Adressing Protocol qui permet de faire
communiquer des machines double piles en IPv6 à travers un réseau local IPv4.
TEREDO - Tunneling IPv6 over UDP through NAT qui permet de fournir une connectivité IPv6
à une machine isolée dans un réseau IPv4 derrière un NAT et qui a un mécanisme qui permet
que les flux du client TEREDO atteignent le relais TEREDO le plus proche au sens du routage.
DSTM – Dual Stack Transition Mechanism qui permet à un réseau IPv6 d’accéder à un réseau
IPv4 suivant le modèle vu pour les tunnels broker.
8.5.4 6PE (MPLS)
6PE s’appuie sur MPLS – Multi Protocol Label Switching pour permettre à un cœur de réseau MPLS
d’acheminer des paquets IPv6 sans en changer ses équipements. Le principe de MPLS est de
commuter sur un label, si les routeurs de périphérie supportant IPv6 font correspondre à une
adresse IPv6 un label, le paquet avec ledit label pourra transiter via les routeurs internes qui ne
regarderont que le label.
Figure 25 : exemple d’architecture MPLS
IPv6 – étude et mise en œuvre Benoît de Mianville
34
9 Ce qui a été mis en œuvre Après une phase d’étude et d’analyse d’IPv6, la partie pratique a consisté à former l’équipe
technique, à sensibiliser l’équipe commerciale et l’équipe dirigeante puis à déployer IPv6 sur un site
pilote ; puis une expérimentation avec un fournisseur de tunnel IPv6 et une solution de translation
open source NAT-64 accessible depuis l’Internet IPv6 a été mise en œuvre, en outre des études de
matériel, de configuration et d’offres des fournisseurs d’accès à Internet mettent à disposition un
panel de solutions concrètes de déploiement d’IPv6.
9.1 Formation L’équipe technique de 2SI est composée de 13 personnes, un des objectifs du projet était de les
former à IPv6, concrètement chaque personne devait avoir une connaissance globale de cette
technologie, savoir pourquoi elle était importante, quelles étaient les différences par rapport à
l’ancienne version, connaitre le matériel et les systèmes compatibles et enfin utiliser le protocole
dans divers cas pratiques qu’ils pourraient être amenés à rencontrer. Une formation d’une journée
durant laquelle l’équipe technique s’est séparée en 2 groupes pour assister à une partie théorique
puis une partie pratique avec au programme :
Présentation théorique
Démonstration des mécanismes IPv6 avec capture de trames
Manipulation des outils de configuration IPv6 de Windows
Mise en place du service d’auto configuration avec un pare feu Cisco
Mise en place de DHCPv6 avec un pare feu Cisco
Utilisation d’un service de tunneling IPv6 dans IPv4 et tests de connectivité avec l’internet
IPv6
En ce qui concerne l’équipe commerciale et l’équipe dirigeante, une sensibilisation sur IPv6 de 30
minutes a été menée et a permis de présenter les points suivants :
Qu’est-ce-qu’IPv6, pourquoi on en a besoin
Quelles sont les solutions de déploiement d’IPv6 adaptées
En quoi 2SI est concerné par IPv6
9.2 Site pilote Afin de pouvoir accompagner au mieux les clients dans le déploiement d’IPv6, il était indispensable
de maitriser cette technologie, la meilleure manière de la maitriser à été de mettre en place un site
pilote mettant en évidence la procédure et les conditions de déploiement. Le site qui a été choisi est
celui du siège social de la société qui comporte un réseau d’utilisateurs qui accèdent au réseau
internet, aux ressources internes et à un réseau comportant des serveurs accessibles depuis
Internet. Dans un premier temps une étude a été réalisée pour établir dans quelles conditions et à
quel coût IPv6 pouvait être déployé, cette étude ayant démontré que le coût du matériel était nul car
englobé dans le renouvellement prévu d’un équipement réseau et que le coût du raccordement à un
FAI proposant IPv6 ne dépassait pas les 50€ par mois pour un site pilote, une seconde étude
décrivant les étapes de déploiement d’IPv6 a été réalisée.
9.2.1 Etude de FAI proposant IPv6
IPv6 – étude et mise en œuvre Benoît de Mianville
35
Les FAI de 2SI ont été consultés, en premier lieu Orange qui propose une offre SDSL avec un lien de
secours ADSL, l’offre propose un accès à Internet via la double pile IPv4/IPv6 sur le lien principal SDSL
avec un nouveau routeur, ils indiquent que le lien de secours est sur une collecte ADSL et non
compatible avec IPv6 de leur côté ; un surcoût de 13€ mensuel est facturé pour IPv6 et un forfait de
2000€ pour l’installation et le paramétrage du routeur pouvant utiliser soit IPv4/IPv6 sur le lien
principal SDSL soit utiliser IPv4 sur le lien de secours est facturé. L’autre FAI de 2SI, All Telecom qui
propose une connexion ADSL ne propose actuellement pas de raccordement via IPv6. Comme
présenté dans la partie précédente, Nerim et Free sont deux candidats proposant IPv6 avec pour
Nerim l’avantage des services dédiés aux professionnels et pour Free l’avantage du faible coût.
9.2.2 Etude du matériel nécessaire
Afin de déployer IPv6 sur le réseau des utilisateurs et le réseau des serveurs, le pare feu actuel
nécessite d’être changé par un autre modèle présentant les caractéristiques suivantes :
5 interfaces
Gestion des VPN site à site IPSec23
Gestion de 50 VPN IPSec pour utilisateurs nomades
Filtrage simple sur les couches réseau et transport
Gestion de l’authentification avec Microsoft Active Directory24
Règle de routage de qualité de service : router les flux sur une interface en se basant sur la
couche transport
Support d’IPv6 pour le routage et le filtrage et la translation NAT 64
Etant donné que le pare feu actuel était vieillissant son remplacement devait être effectué
indépendamment du site pilote IPv6 ; pour des questions d’homogénéité du parc d’équipement
réseau, le constructeur Cisco était privilégié, un modèle de routeur avec une licence sécurité
répondant aux critères ci-dessus a été choisi.
9.2.3 Etapes de déploiement
L’objectif du déploiement est de mettre en place IPv6 dans différents cas de figure pour capitaliser ce
savoir-faire.
La première étape du déploiement consiste à remplacer le pare feu actuel et à vérifier qu’il ait le
même comportement que l’ancien ; la seconde étape consiste à choisir un FAI proposant un accès
IPv6 ADSL et à donner une adresse IPv6 aux postes du LAN interne pour qu’ils puissent aller sur
Internet ; la troisième étape consiste à rendre accessible via IPv6 les services basés à Soissons (on
pourra commencer par le service DNS par exemple).
Le pare feu qui a été choisi est un Cisco 1941 il aura un système Cisco IOS 15 M&T se basant sur l’IOS
12.4 et 12.4T, dans cette partie nous allons décrire l’architecture existante avec le pare feu du
constructeur Clavister puis nous allons décrire les étapes techniques de configuration du pare feu
Cisco qui ont, dans un premier temps, été réalisées dans un environnement de simulation avec l’outil
23
VPN : Virtual Private Network, technique permettant d’étendre deux sous réseaux via Internet de manière sécurisée 24
Microsoft Active Directory : système d’annuaire inclus dans les systèmes d’exploitation serveurs de Windows
IPv6 – étude et mise en œuvre Benoît de Mianville
36
Cisco Packet Tracer sur un routeur Cisco 1841 avec un système IOS 12.4(15)T1, les commandes sont
compatibles.
Le schéma ci-dessous décrit la topologie future, les plages d’adresses IP sont arbitraires.
Figure 26 : topologie du réseau de Soissons
L’accès ADSL All Telecom est utilisé pour la navigation web depuis le LAN interne ; l’accès SDSL
Orange est utilisé pour des VPN IPSec site à site et l’hébergement de services réseaux.
Avant déploiement, les fonctionnalités utilisées par le pare feu Clavister sont les suivantes:
● La translation statique des serveurs des DMZ ● La translation dynamique des clients du LAN interne
● Les tunnels VPN IPSec site à site
● Le “policy based routing” qui permet de router sur le WAN All Telecom le trafic Web du LAN
interne
● Les règles de filtrage
Afin que le pare feu Cisco ait le même comportement que le pare feu Clavister, les fonctions décrites
sont à configurer, la configuration est décrite étape par étape en annexe.
IPv6 – étude et mise en œuvre Benoît de Mianville
37
Une fois la configuration du pare feu effectuée, il faut tester les fonctions préalablement décrites et
valider au bout de quelques jours que le comportement est celui escompté.
On peut alors louer les services d’un FAI proposant IPv6 et commencer l’étape suivante : donner aux
postes des utilisateurs internes un accès IPv6.
Pour cela il est nécessaire de configurer les fonctions suivantes du pare feu :
Configurer les adresses IP des interfaces WAN et LAN interne,
Configurer une route par défaut,
Il faudra aussi configurer un serveur DHCPv6 en lui donnant la plage d’adresses IP utilisable, on
choisira Windows Server 2008 pour assurer cette fonction. On testera alors la connectivité à des
services accessibles en IPv6 comme par exemple la version IPv6 de Google accessible à l’adresse
ipv6.google.com.
L’étape la plus intéressante et la plus complexe est celle du déploiement d’IPv6 pour la partie
hébergement de services, on choisira la translation NAT-64 qui permet de laisser les serveurs
uniquement en IPv4 et de laisser le boitier de translation se charger de répondre aux requêtes IPv6
en faisant l’intermédiaire en IPv4 auprès du serveur ; la fonction de translation dans notre cas sera
assurée par le pare feu Cisco, on choisira de translater directement un serveur grâce au NAT-64
décrit précédemment et les étapes techniques propres au matériel Cisco sont décrites en annexe.
Une fois la translation du serveur configurée, on peut tester depuis des sites extérieurs l’accès au
service en IPv6 pour valider la configuration ; il ne faudra pas oublier de mettre en place des
méthodes de surveillance pour garantir une qualité de service en IPv6 au moins égale à la qualité de
service en IPv4.
9.2.4 Mise en œuvre avec un tunnel IPv6
Pour accélérer la mise en œuvre d’IPv6, une solution expérimentale a été mise en œuvre pour utiliser
de manière réelle les fonctionnalités IPv6, à savoir donner accès aux utilisateurs à IPv6 et mettre un
service IPv4 disponible en IPv6, je décris ci-dessous cette expérimentation.
L’architecture a pour but de donner accès à l’Internet IPv6 aux postes utilisateurs et de translater un
service IPv4 pour qu’il soit accessible en IPv6, j’ai choisi d’utiliser un service de tunnel pour pouvoir
être raccordé réellement à l’Internet IPv6 plutôt que d’utiliser des réseaux isolés, en cela nous
pouvons voir plus précisément les comportements des machines et effectuer des tests grandeur
nature.
L’architecture comprend donc un routeur qui est raccordé au réseau utilisateurs et qui a accès à
l’Internet IPv4, sur ce routeur, une carte tunnel IPv6 dans IPv4 via UDP est connectée à l’Internet
IPv6. Une adresse IPv6 fixe est attribuée au routeur et un bloc d’adresse /56 est attribué également,
on diffusera un de ces sous réseaux sur le réseau utilisateurs grâce au service d’auto configuration
sans états. En ce qui concerne l’accessibilité d’un serveur IPv4 translaté en IPv6, nous utiliserons un
service de translation NAT-64 et un serveur pilote, un serveur Web a été choisi car il est simple à
mettre en œuvre et très présent parmi la plupart des services actuellement déployés sur Internet. Le
dessin ci-dessous présente l’architecture logique qui est utilisée.
IPv6 – étude et mise en œuvre Benoît de Mianville
38
Internet IPv6
Internet IPv4
Serveur Web
Routeur NAT-64
Routeur donnant
accès à IPv6
Réseau utilisateurs
DMZ IPv4 pilote
IPv6
IPv4
IPv4IPv6
IPv6
Protocole IP utilisé
Légende
IPv4IPv6
Figure 27 : architecture logique globale
Voici les caractéristiques des équipements utilisés :
Equipement Description
routeur donnant accès à IPv6 -Ordinateur avec système d’exploitation Windows 7 -Logiciel de tunnel gogo625
Routeur NAT-64 -Ordinateur avec système d’exploitation Linux Debian 6 -Logiciel de translation TAYGA26
Serveur Web -Ordinateur avec système d’exploitation Linux Debian 6 -Serveur Web Apache
Figure 28 : caractéristiques des équipements utilisés
Configuration du tunnel
Pour le tunnel, nous utiliserons les services de la société gogo6, c’est une société Canadienne
pionnière qui fournit des services de conseils, de connectivité et du matériel afin de se raccorder au
réseau IPv6. Ils fournissent un logiciel permettant de créer une carte réseau tunnel et offrent une
adresse IPv6 publique et un bloc d’adresses /56 (sachant qu’il y a 64 bits pour la partie réseau et 64
bits pour identifier les machines, il nous reste 8 bits dans la partie réseau ce qui laisse la possibilité de
faire 256 sous réseaux), le logiciel est compatible Windows, Linux et Mac OS. La configuration du
logiciel gogoclient consiste à rentrer le nom d’utilisateur obtenu sur le site du fournisseur, puis à
25
http://www.gogo6.com/ 26
http://www.litech.org/tayga/
IPv6 – étude et mise en œuvre Benoît de Mianville
39
configurer le logiciel pour qu’il se comporte en tant que routeur et qu’il diffuse le préfixe obtenu
(cela se fait dans le fichier de configuration du programme).
Voici une capture d’un paquet ICMPv6 diffusant le préfixe à utiliser :
Figure 29 : capture d'un paquet ICMPv6 Router Advertisement
Au cas où l’ordinateur ne diffuserait pas le préfixe, on peut le configurer manuellement par exemple
avec Windows en tapant les commandes suivantes :
>netsh >interface ipv6 //activer les annonces de routage sur cette interface, par défaut disabled set interface interface="Connexion au réseau local" advertise=enabled //ajout d'un préfixe et publication add route interface="Connexion au réseau local" prefix=2001:05c0:1517:7e00::/64 publish=yes //l’option router discovery doit être activée set interface "Connexion au réseau local" advertise=enabled //Permettre à cette interface de router sur d’autres interfaces set interface 11 forwarding=enabled
Déploiement d’IPv6 sur les postes utilisateurs
Nous voyons dans cette partie la manière dont les postes utilisateurs accèdent à l’Internet IPv6 ; le
schéma ci-dessous présente l’architecture logique utilisée.
IPv6 – étude et mise en œuvre Benoît de Mianville
40
Internet IPv6
Internet IPv4
2001:5c0:1517:7e00::/64
2001:5c0:1400:b::cc55
:1
Routeur donnant
accès à IPv6
Réseau utilisateurs
Diffusion du préfixe par
auto configuration
Légende
Figure 30 : Architecture logique pour l'accès IPv6 des postes utilisateurs
Les ordinateurs qui récupèrent ce préfixe génèrent une valeur aléatoire pour les 64 bits restants
(pour la majorité des systèmes) et construisent leurs adresses IPv6. Ils utilisent le mécanisme
Duplicate Address Detection – DaD qui consiste à envoyer une demande à l’adresse choisie pour
savoir si une autre machine l’a déjà prise. Ensuite la machine envoie un message ICMP pour
connaitre la passerelle ; il manque encore l’adresse du serveur DNS, on rentre donc manuellement
celle d’un des serveurs DNS publics de Google : 2001:4860:4860::8888, on peut également
paramétrer un serveur DHCP dans Windows Server 2008 en complément de l’auto configuration
pour donner l’adresse du serveur DNS et le domaine de résolution de noms ; cependant cela
fonctionne quand même pour les requêtes DNS grâce au serveur DNS actuel qui répond aussi pour
les enregistrements IPv6.
On peut vérifier sur les ordinateurs qu’ils sont bien configurés en regardant leur configuration IP et
en allant sur un site uniquement accessible via IPv6 comme ipv6.google.com.
La conclusion de ce déploiement d’IPv6 pour les postes utilisateurs démontre qu’aucune intervention
n’est nécessaire sur les postes et qu’ils accèdent directement à l’internet IPv6, cependant il n’est pas
possible de se passer d’IPv4 car beaucoup de services sont uniquement accessibles via ce protocole,
à savoir :
Les serveurs de l’Intranet en IPv4 ;
les imprimantes et autres périphériques non compatibles IPv6 ;
tous les serveurs sur l’Internet seulement accessibles en IPv4 (c’est la majorité des cas
actuellement).
IPv6 – étude et mise en œuvre Benoît de Mianville
41
Une solution à moyen terme est possible pour communiquer avec les serveurs de l’Internet IPv4 en
désactivant l’IPv4 sur les postes : on utilise le système de translation NAT-64 couplé au DNS-64, grâce
à cette solution les postes qui font une requête DNS vers un serveur IPv6 se voient répondre
l’adresse IPv6 et les requêtes pointant vers un serveur IPv4 se voient répondre une adresse IPv6
mappant IPv4, l’adresse IPv4 est inclue dans l’adresse IPv6 en utilisant un préfixe particulier /96 qui
se construit de cette manière :
<préfixe de 96 bits> <adresse IPv4 de 32 bits>
Grâce à ce système, lorsqu’un poste voudra communiquer avec une adresse IPv4 inclue dans une
adresse IPv6, l’équipement de translation NAT-64 reconnaitra le préfixe et effectuera une translation
des adresses en changeant les ports de niveau 4 si le même couple adresse IP et ports sont déjà
utilisés. Voici un projet Open Source qui implémente ce système décrit dans le RFC 6146 : ecdysis27.
On peut retrouver une explication28 dudit RFC.
Translation d’un service
Comme expliqué précédemment, nous avons choisi un serveur web comme serveur pilote, l’objectif
ici est de mettre en œuvre une translation d’un service actuellement fonctionnel en IPv4 sans
configurer de couche IPv6 sur ce serveur. C’est le routeur qui va faire le lien entre une adresse IPv6
préalablement configurée et l’adresse IPv4 du serveur, lorsque le routeur va voir arriver un paquet à
destination de l’adresse IPv6 correspondant au serveur dans sa table de translation, il va reconstruire
un nouveau paquet IPv4 et mettre l’adresse destination du serveur et en adresse source une autre
adresse prise dans un réseau à part pour reconnaitre les communications qui sont le fruit d’une
translation ; c’est en réalité non pas une adresse IPv6 qui est paramétrée pour pointer vers un
serveur IPv4 mais un préfixe /96, en effet une adresse IPv6 comportant 128 bits, un /96 laisse 32 bits
de libres pour y écrire une adresse IPv4, ces types d’adresses s’appellent « adresse IPv6 mappant
IPv4 » et ont été décrites dans la première partie de ce rapport. Le dessin ci-dessous présente
l’architecture utilisée.
27
http://ecdysis.viagenie.ca/ 28
http://www.bortzmeyer.org/6146.html
IPv6 – étude et mise en œuvre Benoît de Mianville
42
Internet IPv6
Internet IPv4
Serveur WebCarte tunnel IPv6
DMZ IPv4 pilote
192.168.2.0/24
2001:5c0:1517:7e01::/64
2001:5c0:1400:b::cc55
:2
:1
.1
.2
2001:5c0:1517:7eff::/96
Routeur donnant
accès à IPv6
Routeur NAT-64
Translation NAT-64
Légende
Figure 31 : Translation NAT-64 d’un serveur Web IPv4
2001:5c0:1400:b::cc55 est l’adresse attribuée par le service de tunnel au routeur IPv6;
2001:5c0:1517:7e01::/64 est le premier sous réseau des 255 attribués par le service de
tunnel, il est utilisé pour l’interconnexion entre le routeur IPv6 et le routeur NAT-64;
2001:5c0:1517:7eff::/64 est le dernier sous réseau attribué par le service de tunnel, il est
utilisé comme préfixe pour les adresses IPv6 mappant des adresses IPv4 par le routeur NAT-
64, on réduit ce préfixe à /96 car on n’a seulement besoin des 32 derniers bits restants pour
écrire les adresses IPv4
Ci-dessous sont décrites les tables de routages des routeurs et du serveur ainsi que la table de
translation du routeur NAT-64.
Destination Via Description
Adresse réseau IPv4 interne Passerelle IPv4 interne Réseau IPv4 interne Figure 32 : Table de routage du routeur IPv6 (IPv4)
IPv6 – étude et mise en œuvre Benoît de Mianville
43
Destination Via Description
2001:5c0:1400:b::/64 Directement connecté Interconnexion vers Internet IPv6
2001:5c0:1517:7e01::/64 Directement connecté Interconnexion avec routeur NAT-64
::/0 2001:5c0:1400:b::cc54 Passerelle par défaut IPv6
2001:5c0:1517:7eff::/96 2001:5c0:1517:7e01:2 Préfixe NAT-64 Figure 33 : Table de routage du routeur IPv6 (IPv6)
Destination Via Description
192.168.2.0/24 Directement connecté Réseau DMZ
192.168.255.0/24 Vers carte nat64 Récupération des réponses à l’origine d’une translation
Figure 34 : Table de routage du routeur NAT-64 (IPv4)
Destination Via Description
2001:5c0:1517:7e01::/64 Directement connecté Interconnexion avec routeur IPv6
::/0 2001:5c0:1517:7e01::1 Passerelle par défaut IPv6
2001:5c0:1517:7eff::/96 Vers carte nat64 Récupération des requêtes à destination d’une translation
Figure 35 : Table de routage du routeur NAT-64 (IPv6)
Destination Via Description
192.168.2.0/24 Directement connecté Réseau DMZ
192.168.255.0/24 192.168.2.1 Envoie des réponses à l’origine d’une translation
Figure 36 : Table de routage du serveur (IPv4)
Préfixe IPv6 Adresse IPv4
2001:5c0:1517:7eff::/96 192.168.255.0/24 Tableau 8 : Table de translation du routeur NAT-64
Sur le dernier tableau ce n’est pas vraiment une table de translation mais plutôt les préfixes utilisés
pour la translation, la table de translation se construira au fur et à mesure des flux.
Le logiciel open source TAYGA a été utilisé pour la translation, il effectue une translation 1 vers 1
d’une adresse IPv6 vers une adresse IPv4, il nécessite donc autant d’adresses IPv4 disponibles que de
requêtes pouvant être effectuées dans le même laps de temps, à échelle réelle il faudra combiner ce
système avec de la translation de ports pour pouvoir utiliser 1 adresse IPv4 pour n adresses IPv6, la
IPv6 – étude et mise en œuvre Benoît de Mianville
44
documentation de TAYGA indique qu’on peut utiliser le système de filtre intégré à Linux iptables
combiné avec l’option MASQUERADE, cependant ce n’est pas l’objet de cette expérimentation et
d’autres solutions sont possibles.
A présent nous abordons la configuration des équipements, notamment le routeur NAT-64, et le
routeur IPv6 ; des points d’exclamation en début de ligne indiqueront des commentaires.
!Addresse IP carte vers NAT-64 (fournisseur d'IPv6) 2001:5c0:1517:7e01::1/64 !Route vers NAT-64 lorsque un paquet a été translaté route ADD 192.168.255.0 MASK 255.255.255.0 192.168.2.1 !Route vers NAT-64 pour le préfixe NAT-64 !en invite de commande administrateur netsh interface ipv6 add route 2001:5c0:1517:7eff::/96 22 2001:5c0:1517:7e01::2 !Activer le forwarding sur les cartes réseaux netsh interface ipv6 set interface 11 forwarding=enabled set interface 22 forwarding=enabled set interface 41 forwarding=enabled Figure 37 : Configuration du routeur IPv6
IPv6 – étude et mise en œuvre Benoît de Mianville
45
!Suppression de la configuration IPv4 ifconfig eth0 down ifconfig eth0 up ifconfig eth1 down ifconfig eth1 up !eth0 : vers routeur IPv6 ip addr add 2001:05c0:1517:7e01::2/64 dev eth0 !eth1 : vers DMZ IPv4 ip addr add 192.168.2.1/24 dev eth1 !Télécharger les sources de TAYGA à l’adresse suivante : http://www.litech.org/tayga/ !Décompresser l’archive Tar –xvf <nom de l’archive> !Compiler et installer TAYGA (se placer dans le répertoire décompressé) ./configure && make && make install !Créer le dossier qui va reccueillir les tables de translation mkdir -p /var/db/tayga !Créer le fichier de configuration de TAYGA (un exemple se trouve dans le même répertoire) cat >/usr/local/etc/tayga.conf <<EOD tun-device nat64 ipv4-addr 192.168.255.1 prefix 2001:5c0:1517:7eff::/96 dynamic-pool 192.168.255.0/24 data-dir /var/db/tayga EOD !Créer l’interface nat-64 et la configurer tayga --mktun ip link set nat64 up ip addr add 192.168.2.1 dev nat64 ip addr add 2001:5c0:1517:7e01::2 dev nat64 ip route add 192.168.255.0/24 dev nat64 ip route add 2001:5c0:1517:7eff::/96 dev nat64 !Activer le routage IPv4 et IPv6 sysctl -w net.ipv4.conf.all.forwarding=1 sysctl -w net.ipv6.conf.all.forwarding=1 !Route par défaut vers routeur IPv6 route --inet6 add default gw 2001:5c0:1517:7e01::1 dev eth0 !Lancer TAYGA en mode debug (ou sans en enlevant l’option –d) tayga -d Figure 38 : Configuration du routeur NAT-64
IPv6 – étude et mise en œuvre Benoît de Mianville
46
On peut maintenant faire des tests pour vérifier les communications dans chaque segment (des tests
avec la commande ping), puis on peut regarder ce qu’affiche le serveur Web en IPv4 depuis un
navigateur, sa manière classique de fonctionner, voici une capture d’écran :
Figure 39 : capture d'écran du site visualisé depuis le réseau DMZ IPv4
On peut maintenant tester l’accès au site depuis un pc qui a accès à l’Internet IPv6, voici une capture
d’écran :
Figure 40 : capture d'écran du site visualisé depuis l'Internet IPv6
On voit que l’adresse IPv6 mappant IPv4 a automatiquement été convertie en hexadécimal par le
navigateur Google chrome, elle était à l’origine 2001:5c0:1517:7eff::192.168.2.1 ; on peut noter ici
que la méthode pour utiliser une adresse IPv6 dans un navigateur est de la mettre entre crochet pour
éviter toute confusion dans le cas de la spécification d’un port non standard, par exemple 8080.
Dans l’exemple présent, le site a été testé depuis l’accès IPv6 interne mais pas derrière le routeur du
fournisseur du tunnel, on peut donc vérifier le bon fonctionnement du routage et de la translation
via un test en ligne comme www.subnetonline.com, voici le résultat concluant de ce test :
IPv6 – étude et mise en œuvre Benoît de Mianville
47
Figure 41 : test d'accessibilité d'un port via IPv6
Voici ce qu’affiche la sortie de débogage de TAYGA :
Figure 42 : sortie de débogage de TAYGA
On remarque que la table de translation a été remplie par 4 requêtes, les machines à l’origine de ces
requêtes correspondent au routeur NAT-64 au routeur IPv6, ainsi qu’a un testeur de connectivité
IPv6 fourni par Hurricane Electric et SubnetOnline.com.
Il ne faut pas oublier de sécuriser ce système NAT-64, l’exemple ci-dessous n’autorise que les flux à
destination d’une translation pour les adresses 192.168.2.1 et 192.168.2.2 avec le pare feu
ip6tables ; sinon on pourrait utiliser le routeur NAT-64 pour accéder aux ressources IPv4 qui lui sont
visibles.
# ip6tables -A FORWARD –s ::/0 -d 2001:5c0:1517:7eff::192.168.2.1/128 -j
ACCEPT
# ip6tables -A FORWARD –s ::/0 -d 2001:5c0:1517:7eff::192.168.2.2/128 -j
ACCEPT
# ip6tables -A FORWARD -d 2001:5c0:1517:7eff::/96 -j DROP
IPv6 – étude et mise en œuvre Benoît de Mianville
48
Pour conclure on peut dire qu’une architecture et des mécanismes permettant de rendre accessible
un serveur uniquement IPv4 par des utilisateurs de l’Internet uniquement IPv6 a été mise au point,
on rajoutera pour le service comme le site web une entrée DNS pointant vers l’adresse IPv6 de
translation. L’avantage de cette solution une fois qu’elle est mise en place est la rapidité de mise en
service de nouvelles translations : on peut rajouter une entrée DNS IPv6 pour un site et autoriser la
translation dans le routeur NAT-64, on peut reproduire ce système facilement sur un nouveau site
avec la méthode précédemment décrite. Une méthode judicieuse qui peut être très intéressante
pour une société de service consiste à mutualiser le service de translation pour mettre en service des
serveur IPv4 via IPv6 même s’ils ne se trouvent pas sur le même site géographique : en effet le
routeur NAT-64 s’il a accès à l’Internet IPv4 peut faire l’intermédiaire entre un client IPv6 de
l’Internet et un serveur IPv4 de l’Internet ; il suffit de rentrer dans le serveur DNS l’adresse IPv6 de
translation construite avec le préfixe de translation et l’adresse IPv4 : <préfixe de
translation> ::<adresse IPv4>. Par exemple si on veut rendre accessible le site www.utt.fr avec
l’adresse IP 193.50.230.230 pour les utilisateurs d’Internet en IPv6, il suffira d’indiquer dans le
serveur DNS de l’UTT un enregistrement IPv6 pour www.utt.fr avec comme adresse <prefixe de
translation> :: 193.50.230.230.
Il est possible de construire une solution passable en production à grande échelle se basant sur les
mêmes mécanismes que ceux décrits ci-dessus, on pourra donc prendre un routeur implémentant la
fonctionnalité NAT-64.
IPv6 – étude et mise en œuvre Benoît de Mianville
49
10 Critique de ce qui a été fait Le sujet défini avant mon arrivée au sein de 2SI était IPv6 et mise en œuvre et sécurité renforcée, il
prévoyait une analyse d’IPv6, des enjeux de cette nouvelle technologie :
au sein de l’Internet de manière macroscopique ;
pour les acteurs de l’Internet tels que les opérateurs et les gestionnaires de noms de
domaine de haut niveau ;
pour les entreprises de différentes tailles connectées à Internet ;
puis enfin, pour les concepteurs et intégrateurs de solutions réseaux, systèmes et systèmes
d’informations comme 2SI.
Le sujet de départ prévoyait également de former l’équipe technique à IPv6 et de concevoir des
méthodes de déploiement.
Enfin, le sujet comportait une partie sécurité renforcée dont l’objectif était d’améliorer la sécurité
réseau interne à l’entreprise pour pouvoir capitaliser cette expertise et la déployer chez les clients.
Après 4 mois de stage le projet concernant IPv6 a été un succès,
un document complet décrivant de manière pédagogique IPv6 a été remis à l’équipe
technique à l’issue d’une formation théorique et pratique ;
une formation de l’équipe dirigeante et de l’équipe commerciale a expliqué IPv6, ses enjeux
et des méthodes concrètes de déploiement adaptées ;
une procédure de déploiement décrivant d’une part de manière globale le déploiement du
site pilote IPv6 et d’autre part les étapes précises de configuration d’un pare feu pour
illustrer dans différentes situations le déploiement d’IPv6 a été réalisée.
Etant en soutenance avancée, à la date de rédaction de ce rapport, le pare feu nécessaire au
déroulement de déploiement d’IPv6 au sein du site pilote n’a pas encore été reçu.
Concernant le projet de sécurité renforcée, une formation d’une partie de l’équipe technique a été
réalisée pour renforcer les bases des architectures et de la sécurité des réseaux d’entreprise, les
points suivants ont été abordés :
architectures réseau de niveau 2 : Ethernet et VLAN ;
routage IP ;
backbone de niveaux 2 et 3 ;
attaques réseaux et techniques de filtrage réseau ;
liaisons intersites sécurisées avec des VPN.
Cette formation a pu aborder de manière théorique les points suscités puis leur mise en œuvre.
Pour continuer sur la sécurité réseau, des études concernant des choix de pare feu m’ont été
confiées, j’ai donc étudié et fourni des comparatifs de fonctionnalités et de coût en partenariat avec
les fournisseurs de 2SI ; ces études m’ont permis de mettre en application le savoir faire m’ayant été
transmis lors de mon année en filière intégration de réseau et on été possibles grâce à une grande
communication et beaucoup d’échanges de conseils avec les ingénieurs réseau et système de 2SI ; les
conseils des experts réseau des fournisseurs de 2SI ont aussi été très précieux.
IPv6 – étude et mise en œuvre Benoît de Mianville
50
Le planning a été suivi dans ses grand axes et le grand changement a été dans la partie
communication puisque les présentations ont eu du succès et j’ai donc présenté IPv6 non seulement
à l’équipe technique, l’équipe commerciale et l’équipe dirigeante mais aussi à l’équipe du service
consultant en progiciel et à l’équipe technique de l’agence communication à Soissons, autre entité de
2SI. Le site pilote au quatrième mois en est à son départ dans la mise en œuvre, une démarche
préventive a largement été déployée quant aux nouvelles solutions qui intègrent le support d’IPv6,
autant pour l’architecture interne de 2SI comme le pare feu, les bornes Wifi que pour les solutions
des clients qui intègrent le critère de support d’IPv6 ; cependant l’établissement d’un plan d’action
commerciale et la formation des commerciaux n’est pas entamée car la demande en IPv6 n’est qu’a
son début puisque il est tout à fait possible d’ignorer à court terme cette technologie, les débouchés
commerciaux sont à prévoir de manière significative dans les 5 ans à venir.
Des autre projets qui n’étaient pas forcement prévus au départ sont venus agrémenter le contenu du
stage, étant donné que j’ai été principalement aux côtés d’un ingénieur j’ai donc participé avec lui à
un projet de migration d’architecture système (annuaire, système de fichiers, gestion des droits)
Novell vers Microsoft avec une couche de virtualisation VMWare dans le nouveau système, les
points suivants ont été développés :
participation à la conception d’une architecture système redondante ;
participation à la mise en œuvre de systèmes de sauvegarde des machines virtuelles et des
données ;
mise en place d’un outil de transfert des utilisateurs de Novell vers Active Directory ;
mise au point d’une solution d’automatisation de l’intégration des machines utilisateurs dans
le nouveau système.
D’autres projets m’ont également été confiés, notamment l’analyse et la résolution d’un problème
de liaison VPN non fiable au cours duquel la solution existante de supervision réseau a été mise à
profit pour voir l’évolution de la disponibilité de la liaison, finalement la configuration d’un nouveau
pare feu et le remplacement du matériel a été requise. Un autre projet a consisté à concevoir une
maquette d’une grappe de serveurs applicatifs puis une procédure de mise en œuvre ; j’ai pu
participer aussi à la mise en production de ce système cela m’a permis d’étudier les solutions de
systèmes haute disponibilité de Microsoft et la mise en place d’une solution adaptée à plus de 400
utilisateurs.
IPv6 – étude et mise en œuvre Benoît de Mianville
51
11 Conclusion La pénurie d’adresses IPv4 de l’IANA a été atteinte en 2011, c’est la différence par rapport à l’an 2000
ou on parlait déjà d’IPv6 car à l’époque on avait encore quelques années de répit, en 2012, l’APNIC
(en Asie) est le RIR qui a le moins d’adresses IPv4, ensuite c’est le RIPE NCC (en Europe), donc dans
les 5 ans à venir nous allons avoir une utilisation croissante historique d’IPv6, on a déjà pu le
constater ces trois dernières années. C’est donc naturellement qu’IPv6 s’impose comme nouveau
protocole pour pouvoir faire face à la croissance de l’utilisation d’Internet. Aujourd’hui on ne se pose
plus la question du besoin d’IPv6 mais plutôt de la façon dont on va le déployer. Une étude a donc
été menée pour comprendre précisément le besoin de ce nouveau protocole, ensuite les différentes
méthodes de déploiement d’IPv6 ont été analysées puis une mise en œuvre a été effectuée sur un
site pilote pour donner accès à Internet IPv6 à des postes utilisateurs puis pour rendre disponible sur
l’Internet IPv6 un serveur IPv4. Une étude a mis en évidence de manière concrète comment déployer
IPv6 en concordance avec le matériel, les solutions logicielles et les fournisseurs d’accès à Internet
actuels, et des méthodes adaptées ont été décrites. Concernant la capitalisation de ces travaux,
plusieurs formations ont été effectuées, la formation avancée des 13 personnes constituant l’équipe
technique, une sensibilisation de l’équipe commerciale puis de l’équipe dirigeante et enfin la
formation du service consultant et de l’entité agence de communication de 2SI. Le travail a été
effectué dans les temps, j’ai pu assister à un séminaire « préparation au lancement mondial d’IPv6 »
organisé par l’Afnic, Cisco, Telecom Bretagne et Neo Telecom, ainsi qu’a un séminaire web organisé
Cisco. J’ai également pu participer à des projets de déploiement d’agent pour la supervision de
systèmes, de migration d’une ferme de serveurs applicatifs et de migration d’un système
informatique au service de plus de 400 utilisateurs. Finalement c’est un stage très enrichissant qui
me permet de compléter ma formation d’ingénieur réseau avec des dimensions supplémentaires
dans les relations internes à l’entreprise et avec ses interlocuteurs, avec de la veille technologique
accrue ; je remercie très chaleureusement chaque collaborateur de 2SI et également certains clients
mais aussi les fournisseurs et autres interlocuteurs, sans qui ce stage n’aurait pu se dérouler aussi
bien.
IPv6 – étude et mise en œuvre Benoît de Mianville
52
12 Bibliographie Livres
[ARC, 2012], IPv6 Principes et mise en œuvre, Jean-Paul Archier, eni, 2012, 396 pages
[CIZ, 2005], IPv6 – Théorie et pratique, Gizèle Cizault, O’REILLY, 2005, 467 pages
Documents non publiés
Alain Ploix, IPv6, Cours de l’UTT, UTT, 2012
Samuel Guggenbuhl, Simon Baudas, Cohabitation IPv4 – Ipv6, Travail d’expérimentation, UTT, 2012
Sites Internet
http://c2.touta.in/?p=222, Cours et exercices IPv6 en vidéo, Telecom Bretagne, consulté le
10/06/2012
[CIZ, 2005], http://livre.g6.asso.fr, IPv6 – Théorie et pratique, G6 Association, consulté le 01/06/2012,
version en ligne du livre [CIZ, 2005]
http://technet.microsoft.com, documentation technique des outils Microsoft, consulté le
01/06/2012
http://www.debian.org/doc, documentation technique du système d’exploitation Linux Debian,
consulté le 01/06/2012
http://www.cisco.com/, documentation technique des équipements Cisco, consulté le 01/06/2012
http://www.bortzmeyer.org/, synthèse et commentaire des normes RFC, consulté le 01/06/2012
IPv6 – étude et mise en œuvre Benoît de Mianville
1
13 Annexe
13.1 Configuration du pare feu Cisco 1941 Le pare feu Cisco a un système IOS 15 M&T se basant sur l’IOS 12.4 et 12.4T. Le paramétrage suivant
a été fait sur un routeur Cisco 1841 IOS 12.4(15)T1 dans Packet Tracer dont les commandes sont
compatibles ; ci-dessous est présenté le schéma physique de la simulation :
Figure 43 : Schéma physique de la simulation de configuration du pare feu
Sur le schéma ci-dessus, une interface est utilisée pour plusieurs réseaux, on la divisera en sous interfaces avec des VLAN (car au total on n’aura que 2 interfaces physiques).
On s’intéresse donc à la configuration du pare feu nommé sur le schéma “RT1”.
Protocole IP
On commence par configurer le protocole IP des interfaces :
!
!--On met en route l’interface physique
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!--seule cette ligne est intéressante
no shutdown
!
IPv6 – étude et mise en œuvre Benoît de Mianville
2
!--On crée la sous interface 0/0.20 et on dit qu’on va utiliser le protocole 802.1q et que les trames seront tagguées avec le numéro de VLAN 20
interface FastEthernet0/0.20
description VERS ALL TELECOM
encapsulation dot1Q 20
ip address 200.0.0.1 255.255.255.0
!
interface FastEthernet0/0.30
description VERS LAN INTERNE
encapsulation dot1Q 30
ip address 192.168.30.1 255.255.255.0
!
interface FastEthernet0/0.40
description VERS DMZ MAIL
encapsulation dot1Q 40
ip address 192.168.40.1 255.255.255.0
!
interface FastEthernet0/0.50
description VERS DMZ WEB
encapsulation dot1Q 50
ip address 192.168.50.1 255.255.255.0
!
interface FastEthernet0/1
description VERS ORANGE
ip address 100.0.0.1 255.255.255.0
!
Routage statique
Maintenant on peut configurer le routage statique:
!--Route par défaut vers Orange
ip route 0.0.0.0 0.0.0.0 100.0.0.2
IPv6 – étude et mise en œuvre Benoît de Mianville
3
!
!--Route par défaut vers All Telecom
!--On le configurera plus tard avec le policy based routing
!
Translations
On configure les translations :
Translation statique du serveur WEB de DMZ Web pour que les clients d’Internet puissent y accéder.
!
interface FastEthernet0/0.50
!--côté du serveur web on met inside
ip nat inside
!
interface FastEthernet0/1
!--côté de l’internet (Orange) on met outside
ip nat outside
!
!
!
!--Seul le port 80 du serveur web est translaté
ip nat inside source static tcp 192.168.50.2 80 100.0.0.1 80
On fait pareil pour le serveur de mail
!
interface FastEthernet0/0.40
ip nat inside
!
!-- Par contre on met le port SMTP 25
IPv6 – étude et mise en œuvre Benoît de Mianville
4
ip nat inside source static tcp 192.168.40.2 25 100.0.0.1 25
!
!-- Puis le port POP3 110
ip nat inside source static tcp 192.168.40.2 110 100.0.0.1 110
Maintenant on va configurer la translation dynamique du LAN interne vers All Telecom
Remarque : on pourrait aussi configurer une translation dynamique vers le WAN orange pour les flux autres que le web.
Interface fa0/0.30
!-L'interface LAN interne est "inside"
ip nat inside
!
interface FastEthernet0/0.20
!--côté de l’internet (All telecom) on met outside
ip nat outside
!
!--Les flux du LAN interne seront translatés s’ils passent par l'interface vers All Telecom
!--Overload indique qu'on fait du PAT : si plusieurs flux ont le même identifiant de connexion-
!---alors on change le port source
ip nat inside source list 1 interface fa0/0.20 overload
!
!--On désigne les flux provenant du LAN interne
access-list 1 permit 192.168.30.0 0.0.0.255
Policy based routing
Maintenant on va configurer le policy based routing pour que les flux du LAN interne aillent vers le WAN All Telecom.
Voici la documentation29 pour cette fonctionnalité.
29
http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html
IPv6 – étude et mise en œuvre Benoît de Mianville
5
Policy based routing est une fonctionnalité de qualité de service non présente dans le logiciel de simulation packet tracer, nous allons cependant décrire les étapes à la mise en œuvre sans les tester :
Attention ! Les flux web doivent passer en priorité par le WAN ADSL All Telecom mais si celui est en panne, ils doivent passer par le lien WAN SDSL Orange.
!--On met le routeur en mode de configuration route map
route map flux-web permit 10
!
!-Le routage se basera sur les flux web (décrit plus bas dans l'acl)
match ip address 101
!
!--On met l'interface de sortie, ici vers All Telecom
set interface fa0/0.20
!
Interface fa0/0.30
!--On indique que le routage est à appliquer sur l'interface LAN interne
ip policy route-map flux-web
!
!--Access List qui désigne les flux Web du LAN interne vers n'importe quel serveur web
!--Attention, cela peut poser problème si le LAN interne veut accéder à un serveur web de la DMZ
access-list 101 permit tcp 192.168.30.0 0.0.0.255 any eq www
Pour continuer quand même notre simulation, on va ajouter une route vers un seul serveur web qui est accessible via la ligne All Telecom :
!--Pour atteindre le réseau du serveur Web connecté à All Telecom, on passe par le routeur de All Telecom
ip route 200.10.0.0 255.255.255.0 200.0.0.2
VPN site à site
Cette partie étant plus complexe, je recommande de lire la partie suivante prévue à cet effet. Après avoir suivi les instructions du document précédent, cela ne devrait pas fonctionner, en effet l’access-list utilisée pour la translation dynamique pour aller sur le web étant la suivante :
IPv6 – étude et mise en œuvre Benoît de Mianville
6
access-list 1 permit 192.168.30.0 0.0.0.255 De plus, les flux allant du LAN interne vers Orange (le flux chiffré du VPN); passent d’une interface inside à une interface outside (pour la translation dynamique et statique on a dû faire comme ça); ce qui a pour conséquence que le routeur effectue une translation dynamique des flux devant aller dans le VPN. On va donc modifier l’access-list de la translation dynamique pour qu’elle ne matche pas les
flux du VPN et matche les autres flux : On supprime l’acl 1: no access-list 1 On crée l’acl étendue 102 : access-list 102 deny ip 192.168.30.0 0.0.0.255 192.168.60.0 0.0.0.255 access-list 102 permit ip 192.168.30.0 0.0.0.255 any On modifie la translation dynamique pour lui dire de se baser sur l’acl 102 et non plus la 1 : no ip nat inside source list 1 interface FastEthernet0/0.20 overload ip nat inside source list 102 interface FastEthernet0/0.20 overload A présent les flux devant passer dans le VPN le sont (on peut voir en mode simulation l’établissement des tunnels ISAKMP puis IPSec) et la translation dynamique est effective.
13.2 Cisco VPN IPSec site à site (sur routeur) L’objectif de ce document est de comprendre la configuration de VPN site à site avec clé partagée sur
un routeur Cisco en ligne de commande et d’aborder une mise en œuvre rapide.
1. Définir les paramètres pour la phase 1 IKE (tunnel ISAKMP)
2. Définir les paramètres pour la phase 2 IKE (tunnel IPSec)
3. Créer une ACL pour identifier le trafic “intéressant”
4. Créer une crypto map et l’appliquer à l’interface appropriée
5. En option, créer une ACL pour bloquer le trafic non intéressant
Exemple
Nous utiliserons le logiciel de simulation Packet Tracer avec des routeurs Cisco 2811 IOS 12.4(15)T1; on pourra très bien reprendre cet exemple pour des autres routeurs.
Le schéma réseau est présenté ci-dessous.
IPv6 – étude et mise en œuvre Benoît de Mianville
7
Figure 44 : Réseau exemple pour les VPN site à site
Pré-requis :
Il faut que les routeurs puissent communiquer entre eux, ici c’est directement, ça peut aussi être via Internet.
Sur chaque routeur, tapez les commandes suivantes :
crypto isakmp policy 1
authentication pre-share
hash sha
encryption aes 128
group 2
lifetime 86400
exit
crypto isakmp key cisco address <rt distant>
crypto ipsec transform-set myset esp-aes esp-sha
access-list 101 permit ip SRC MASK DST MASK
crypto map mymap 10 ipsec-isakmp
set peer <rt distant>
IPv6 – étude et mise en œuvre Benoît de Mianville
8
match address 101
set transform-set myset
exit
int faxxx
crypto map mymap
Pour exemple, voici la configuration du routeur0 (à gauche) :
!
crypto isakmp policy 1
encr aes 128
authentication pre-share
group 2
!
crypto isakmp key cisco address 11.0.0.2
!
!
crypto ipsec transform-set myset esp-aes esp-sha-hmac
!
crypto map mymap 10 ipsec-isakmp
set peer 11.0.0.2
set transform-set myset
match address 101
!
!
!
!
!
!
IPv6 – étude et mise en œuvre Benoît de Mianville
9
!
!
!
interface FastEthernet0/0
ip address 10.0.0.1 255.0.0.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 11.0.0.1 255.0.0.0
duplex auto
speed auto
crypto map mymap
!
ip classless
ip route 12.0.0.0 255.0.0.0 11.0.0.2
!
!
access-list 101 permit ip 10.0.0.0 0.255.255.255 12.0.0.0 0.255.255.255
!
!
end
Sources
http://www.youtube.com/watch?v=Ug1yD8Ov_00&feature=related
https://learningnetwork.cisco.com/docs/DOC-10756
13.3 Cisco NAT PT explication et mise en œuvre NAT-PT de Cisco est un mécanisme qui permet à des hôtes exécutant IPv6 uniquement de communiquer avec des hôtes exécutant IPv4 uniquement et vice versa.
Il permet un déploiement vers IPv6 dans une phase de transition où les deux protocoles sont encore nécessaires.
Il existe des variantes de NAT-PT, elles sont expliquées ci-dessous.
IPv6 – étude et mise en œuvre Benoît de Mianville
10
Static NAT-PT
Static NAT-PT est utile lorsqu’un hôte en IPv4 communique avec un autre hôte accessible en IPv6 ou vice versa, c’est statique car il faudra configurer une nouvelle translation pour chaque nouvel hôte qui voudra communiquer.
Dynamic NAT-PT
Avec Dynamic NAT-PT, on peut faire des translations de N machines IPv4 only vers une machine IPv6 only ou l’inverse, les N machines auront alors après translation une adresse translatée choisie dans un pool, ce pool est à configurer et on aura autant de sessions concurrentes possibles qu’il y aura d’adresses dans le pool.
Port Address Translation ou Overload
L’Overlad permet de faire communiquer différents hôtes IPv4 vers un hôte IPv6 et tous utiliseront une seule adresse translatée IPv6, le port TCP ou UDP sera changé si nécessaire pour permettre des sessions concurrentes, on peut aussi utiliser un pool d’adresses. Cette solution peut être utilisée à l’inverse pour faire communiquer plusieurs hôtes IPv6 vers un hôte IPv4 comme le cas d’un serveur IPv4 que l’on rend accessible aux clients IPv6.
Adresses IPv6 mappant IPv4
Ce cas de figure est utile pour donner accès à un réseau uniquement IPv6 à un réseau IPv4; les clients IPv6, pour joindre des hôtes IPv4, utiliseront des adresses IPv6 qui contiendront une adresse IPv4 (c’est un format standard définit par l’IETF).
Lorsque le routeur détectera une adresse IPv6 mappant IPv4, il vérifiera qu’une règle est associée et extraira l’adresse IPv4 destination pour refaire un nouveau paquet IPv4 et l’envoyer.
Cas concret : mise en service IPv6 d’un serveur uniquement IPv4
On a un serveur DNS dans une DMZ qui est en IPv4 et qui va y rester.
Les clients de l’internet aimeraient accéder à ce serveur DNS via IPv6.
On configure le routeur RT1 pour qu’il rende disponible le service DNS via une adresse IPv6, ça peut être une adresse d’un sous réseau attribué par le FAI ou le RIPE NCC.
Dans le cas présenté dans le schéma ci-dessous, On simule un client de l’Internet avec un poste
derrière le routeur RT0.
Les client pourront joindre le serveur DNS en IPv6 avec l’adresse 2001:db8::2.
Le serveur DNS croira qu’on lui fait des requêtes à partir du pool d’adresses 10.21.8.1 à 10.21.8.10.
Ci-dessous on peut voir
● Le schéma de l’architecture
● La configuration du routeur RT1
● La configuration du routeur RT0
IPv6 – étude et mise en œuvre Benoît de Mianville
11
__________________
RT1
!
!------COTE IPv4 (DMZ)------
interface FastEthernet0/0
!
!--adresse ipv4
ip address 192.168.30.9 255.255.255.0
duplex auto
speed auto
!
!--On doit mettre obligatoirement ipv6 nat sur les interfaces inbound et outbound
ipv6 nat
!
IPv6 – étude et mise en œuvre Benoît de Mianville
12
!--Allumer l'interface!
no sh
!------COTE IPv6 (FAI/INTERNET)------
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
!--adresse ipv6
ipv6 address 2001:DB8:BBBB:1::9/64
!--ipv6 enable : juste pour activer ipv6
ipv6 enable
!
!--On doit mettre obligatoirement ipv6 nat sur les interfaces inbound et outbound
ipv6 nat
!
!--Allumer l'interface!
no sh
!
!------TRANSLATIONS------
!--Route par défaut pour renvoyer vers RT0
ipv6 route ::/0 2001:db8:bbbb:1::8
!
!--On rend disponible le serveur DNS avec une adresse ipv6
ipv6 nat v4v6 source 192.168.30.1 2001:DB8::2
!
!--On définit un pool (en lien avec la ligne suivante)
ipv6 nat v6v4 pool v4pool 10.21.8.1 10.21.8.10 prefix-length 24
IPv6 – étude et mise en œuvre Benoît de Mianville
13
!
!--On dit que les connexions entrantes en ipv6 décrites par l'acl ci-dessous seront translatées vers un pool d'adresses ipv4
ipv6 nat v6v4 source list pt-list1 pool v4pool
!
!--On spécifie que si une adresse destination correspond au préfixe ci-dessous, on fait-
!--la translation
ipv6 nat prefix 2001:DB8::/96
!
!--Ca désigne toutes les connexions entrantes de l'internet qui vont vers l'adresse IPv6 du serveur DNS
ipv6 access-list pt-list1
permit ipv6 any host 2001:DB8::2
!
____________
RT0
!
int fa0/0
ipv6 address 2001:db8:bbbb:1::8/64
ipv6 enable
no sh
int fa0/1
ipv6 address 2010:db8:bbbb:1::9/64
ipv6 enable
no sh
!
ipv6 route ::/0 2001:db8:bbbb:1::9