ipv6 analyse et mise en oeuvre - memoire stage ingénieur réseau

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.


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.


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

http://www.ietf.org/rfc.html


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

http://fr.wikipedia.org/wiki/Fichier:Ipv4-exhaust.svg


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.

http://www.nro.net/statistics


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

http://www.nro.net/statistics

http://www.worldipv6launch.org/

http://linuxfr.org/news/activation-mondiale-de-l-ipv6-world-ipv6-launch


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.


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


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


2000:0:2::1

Notation simple 2000:0:0:5:0:0:2001:1


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


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 :


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 :

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml


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] :


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




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

http://fr.wikipedia.org/wiki/Adresse_IPv6_mappant_IPv4


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.


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

http://tools.ietf.org/html/draft-nward-ipv6-autoconfig-filtering-ethernet-00


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.


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/

http://social.technet.microsoft.com/Forums/en-US/ipv6/thread/5757980a-5983-4efc-a5f3-27687b90fe41

http://www.labo-microsoft.org/articles/IPv6_WindowsServer/3/Default.asp

http://klub.com.pl/dhcpv6/

http://thc.org/thc-ipv6/


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.


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.


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.


21

Figure 12 : planning février à mai 2012

Figure 13 : planning juin juillet 2012


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


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



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.


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

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln_ps6350_TSD_Products_Configuration_Guide_Chapter.html%23wp1057128

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln_ps6350_TSD_Products_Configuration_Guide_Chapter.html%23wp1057128


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

http://www.litech.org/tayga/

http://ecdysis.viagenie.ca/

http://www.cisco.com/en/US/docs/ios/ios_xe/ipaddr/configuration/guide/iad_stateless_nat64_xe.html

http://tools.cisco.com/ITDIT/CFN/jsp/by-feature.jsp


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.


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 ».


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

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010812

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010812

https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html

http://vsphere-land.com/news/ipv6-support-in-vsphere.html


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 :


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


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 :


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

http://tunnelbroker.net/

http://www.sixxs.net/

http://www.gogo6.com/


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


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


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.


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.


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.gogo6.com/



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.


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).


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://ecdysis.viagenie.ca/



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)


43


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)


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)


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)


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


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


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



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 :

http://www.subnetonline.com/


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


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.

http://www.utt.fr/

http://www.utt.fr/


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.


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.


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.


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

http://c2.touta.in/?p=222

http://livre.g6.asso.fr/

http://technet.microsoft.com/

http://www.debian.org/doc

http://www.cisco.com/

http://www.bortzmeyer.org/


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

!


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

!


description VERS LAN INTERNE


ip address 192.168.30.1 255.255.255.0

!


description VERS DMZ MAIL


ip address 192.168.40.1 255.255.255.0

!


description VERS DMZ WEB


ip address 192.168.50.1 255.255.255.0

!


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


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.

!


!--côté du serveur web on met inside

ip nat inside

!


!--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

!


ip nat inside

!

!-- Par contre on met le port SMTP 25


4


!

!-- Puis le port POP3 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

!


!--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

http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html


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 :


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.


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>


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

!

!

!

!

!

!


9

!

!

!


ip address 10.0.0.1 255.0.0.0

duplex auto

speed auto

!


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.



































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


11

__________________

RT1

!

!------COTE IPv4 (DMZ)------


!

!--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

!


12

!--Allumer l'interface!

no sh

!------COTE IPv6 (FAI/INTERNET)------


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


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