IPv 6

Le protocole IPv6
(Frédéric Roudaut)
Janvier 2009
Depuis les années 80, l’Internet connaît un succès incroyable. La majeure partie des entreprises y est maintenant
directement connectée, le nombre de particuliers détenteur d’un abonnement Internet auprès d’un FAI (Fournisseur
d’Accès Internet) est en constante croissance. La demande est telle que le nombre d’adresses attribuées actuellement
est proche des limites du protocole IPv4 utilisé pour la communication Internet. Les études réalisées par les autorités
responsables de l’allocation d’adresses ainsi que la commission européenne convergent : on assistera à une pénurie
d’adresses à l’horizon 2011. Il était donc nécessaire d’étendre le plan d’adressage. Le protocole IPv6 est la solution
standardisée pour palier à ce manque d’adresses.
1. Sommaire
1. SOMMAIRE.......................................................................................................................................................................................2
2. PRÉAMBULE....................................................................................................................................................................................4
2.1 CET ARTICLE EXPLIQUE........................................................................................................................................................................4
2.2 CE QU'IL FAUT SAVOIR.........................................................................................................................................................................4
2.3 A PROPOS DE L'AUTEUR.......................................................................................................................................................................4
2.4 INTRODUCTION...................................................................................................................................................................................4
3. ADRESSAGE IPV6 ET NOMMAGE..............................................................................................................................................4
3.1 FORMAT DES ADRESSES........................................................................................................................................................................4
3.2 LES DIFFÉRENTS TYPES D’ADRESSES.......................................................................................................................................................5
3.3 ADRESSAGE UNICAST..........................................................................................................................................................................5
3.3.1 Identifiant EUI-64 ..................................................................................................................................................................6
3.3.2 Adresses Lien-local.................................................................................................................................................................7
3.3.3 Adresses Globales ..................................................................................................................................................................7
3.3.4 Adresses de loopback..............................................................................................................................................................7
3.3.5 Adresses Indéterminées...........................................................................................................................................................7
3.4 ADRESSAGE MULTICAST......................................................................................................................................................................7
3.5 ADRESSAGE ANYCAST.........................................................................................................................................................................8
3.6 DNSV6............................................................................................................................................................................................8
4. ENTÊTE IPV6....................................................................................................................................................................................9
4.1 CHAÎNAGE DES ENTÊTES ET EXTENSIONS D’ENTÊTE.................................................................................................................................10
4.1.1 Hop-By-Hop Option Header.................................................................................................................................................12
4.1.2 Fragment Header..................................................................................................................................................................12
4.1.3 Destination Option Header...................................................................................................................................................12
4.1.4 Authentication Header & Encapsulating Security Payload.................................................................................................13
5. PROTOCOLES DE NIVEAU TRANSPORT POUR IPV6 : TCP & UDP................................................................................13
6. ICMPV6 ...........................................................................................................................................................................................14
6.1 ENTÊTE ICMPV6............................................................................................................................................................................14
6.2 MESSAGES D’ERREURS.......................................................................................................................................................................15
6.2.1 Destination Unreachable......................................................................................................................................................15
6.2.2 Packet Too Big .....................................................................................................................................................................16
6.2.3 Time Exceeded......................................................................................................................................................................16
6.2.4 Parameter Problem...............................................................................................................................................................17
6.3 MESSAGES INFORMATIONNELS.............................................................................................................................................................17
6.3.1 Echo Request / Echo Reply...................................................................................................................................................17
7. FRAGMENTATION & PATH MTU DISCOVERY....................................................................................................................18
8. NEIGHBOR DISCOVERY PROTOCOL (DÉCOUVERTE DES VOISINS)...........................................................................19
8.1 ENTÊTES DE MESSAGES DU PROTOCOLE NEIGHBOR DISCOVERY...............................................................................................................19
8.1.1 Sollicitation et annonces des routeurs..................................................................................................................................19
8.1.2 Sollicitation et annonces des voisins.....................................................................................................................................21
8.2 DÉTECTION D’ADRESSE DUPLIQUÉE (DAD) & AUTOCONFIGURATION SANS ÉTAT ....................................................................................23
8.3 RÉSOLUTION D’ADRESSE....................................................................................................................................................................24
9. MÉCANISMES DE TRANSITION & INTÉROPÉRABILITÉ IPV4/IPV6 ?...........................................................................25
9.1 DOUBLE PILE IPV4/IPV6..................................................................................................................................................................25
9.2 PASSERELLE APPLICATIVE (ALG : APPLICATION LEVEL GATEWAY).......................................................................................................26
9.3 TRADUCTION D’ENTÊTE : SIIT/NAT-PT............................................................................................................................................26
9.4 TUNNELING......................................................................................................................................................................................27
9.4.1 Tunnel brokers......................................................................................................................................................................27
9.4.2 6to4.......................................................................................................................................................................................27
9.4.3 Quelques autres protocoles …..............................................................................................................................................28
9.5 CONCLUSION....................................................................................................................................................................................28
10. IPSEC..............................................................................................................................................................................................29
10.1 MÉCANISMES IPSEC........................................................................................................................................................................29
10.1.1 Associations de sécurité......................................................................................................................................................29
2
10.1.2 Mode Transport et Tunnel..................................................................................................................................................29
10.2 AH (AUTHENTICATION HEADER).....................................................................................................................................................29
10.2.1 Protection AH et Algorithmes.............................................................................................................................................30
10.2.2 Mode Transport..................................................................................................................................................................30
10.2.3 Mode Tunnel.......................................................................................................................................................................31
10.3 ESP (ENCRYPTION SECURITY PAYLOAD)...........................................................................................................................................32
10.3.1 Protection ESP et Algorithmes..........................................................................................................................................33
10.3.2 Mode Transport..................................................................................................................................................................34
10.3.3 Mode Tunnel.......................................................................................................................................................................34
10.3.4 Topologies de mises en œuvre ............................................................................................................................................35
10.4 IKE (INTERNET KEY EXCHANGE)....................................................................................................................................................35
11. MOBILITÉ DE MACHINES : MIPV6........................................................................................................................................36
11.1 CONCEPTS ....................................................................................................................................................................................36
11.2 MOBILITÉ DE MACHINES : MIP6.....................................................................................................................................................37
11.3 OPTIMISATIONS DE ROUTES ..............................................................................................................................................................37
11.4 RETURN ROUTABILITY PROCÉDURE....................................................................................................................................................38
12. MOBILITÉ DE RÉSEAUX : NEMO...........................................................................................................................................39
13. PRATIQUE & MISE EN ŒUVRE .............................................................................................................................................39
13.1 AVEC WINDOWS ...........................................................................................................................................................................40
13.1.1 Activation de la pile IPv6 & Configuration des Adresses..................................................................................................40
13.1.2 Commandes principales .....................................................................................................................................................41
13.1.2.1 Connectivité, chemin........................................................................................................................................................41
13.1.2.2 Cache des voisins (NDP Cache)......................................................................................................................................41
13.1.2.3 Diverses Commandes ......................................................................................................................................................41
13.1.3 Accès Web en IPv6..............................................................................................................................................................42
13.2 AVEC LINUX..................................................................................................................................................................................42
13.2.1 Activation de la pile IPv6 & Configuration des Adresses..................................................................................................42
13.2.2 Mise en œuvre mode routeur...............................................................................................................................................43
13.2.3 Commandes et outils principaux.........................................................................................................................................43
13.2.4 Mise en œuvre d’IPsec........................................................................................................................................................43
14. CONCLUSION...............................................................................................................................................................................45
15. RÉFÉRENCES...............................................................................................................................................................................46
3
2. Préambule
2.1 Cet article explique...

Cet article a pour ambition de vous faire appréhender les techniques fondamentales d’IPv6 : le nouveau mode
d’adressage, les mécanismes de communication sous-jacents, la configuration automatique … bref l’ensemble des
protocoles basiques qui composent l’architecture d’IPv6. Nous ferons constamment référence à IPv4 afin de bien
appréhender les différences entre ces 2 protocoles. Il peut sembler verbeux au premier abord, mais il est indispensable
de maîtriser les paquets constituant la base d’IPv6 pour une bonne compréhension de ce protocole.
Mais IPv6 est plus qu'une simple extension de l'espace d'adressage, il introduit ou améliore des mécanismes qui
devraient changer nos modes d'utilisation d'Internet. La sécurisation des échanges, la mobilité des machines, des
réseaux font maintenant partie intégrante de la couche réseau laissant ainsi place à de futurs services innovants. Une
deuxième partie complète ainsi cette introduction par l'explicitation de mécanismes avancés pour la mobilité de
machine, de réseaux, la sécurité au niveau IP.
Cet article sera aussi l'occasion de vous initier à la mise en œuvre de ce "nouveau" protocole.
2.2 Ce qu'il faut savoir...

Afin d’appréhender au mieux cet article, il est préférable d’avoir des connaissances relativement solides d’IPv4 et en
particulier du modèle en couche TCP/IP.
2.3 A propos de l'auteur

Frédéric Roudaut travaille actuellement chez Orange Labs (anciennement France Telecom R&D) à Sophia Antipolis
pour le compte d’Orange Business Services IT&Labs depuis 1 an et demi. Ses activités concernent principalement les
mécanismes d’accélération TCP et applicatives pour palier aux latences dans les communications internationales
résultants principalement des RTTs (Round Trip Time) importants.
2.4 Introduction
Depuis les années 80, l’Internet connaît un succès incroyable. La majeure partie des entreprises y est maintenant
directement connectée, le nombre de particuliers détenteur d’un abonnement Internet auprès d’un FAI (Fournisseur
d’Accès Internet) est en constante croissance. La demande est telle que le nombre d’adresses attribuées actuellement
est proche des limites du protocole IPv4 utilisé pour la communication Internet. Les études réalisées par les autorités
responsables de l’allocation d’adresses ainsi que la commission européenne convergent : on assistera à une pénurie
d’adresses à l’horizon 2011. Il était donc nécessaire d’étendre le plan d’adressage. Le protocole IPv6 est la solution
standardisée pour palier à ce manque d’adresses.
La définition de ce nouveau protocole IPv6 a été également une opportunité de corriger certains problèmes inhérents
au protocole IPv4. Ces problèmes avaient été mis en exergue par la communauté Réseau au cours des dernières
années. De nouveaux besoins tels que la sécurité, la mobilité, une facilitation des mécanismes de configuration sont
également apparus et ont pu être pris en compte lors de la standardisation d’IPv6.
Ces différentes modifications font d’IPv6 un protocole à part entière et non une simple extension d’IPv4. Il s’agissait
donc d’adapter ces corrections sur l’ensemble des protocoles du modèle en couche TCP/IP expliquant ainsi le travail
relativement complexe et colossal effectué par l’organisme de standardisation de l’Internet, IETF (Internet Engineering
Task Force) ces dix dernières années principalement (même si les spécifications initiales d’IPv6 datent de 1988).
3. Adressage IPv6 et nommage

L’évolution la plus visible d’IPv6 concerne l’extension de son espace d’adressage pour palier à la pénurie d’adresse du
protocole actuel IPv4. Ce paragraphe vous expliquera le format de ces nouvelles adresses ainsi que le nouveau
découpage en classes usité par IPv6.
3.1 Format des adresses
4
Les adresses IPv6 sont constituées de 16 octets (128 bits). On dispose ainsi d'environ 3,4 × 1038 adresses, soit plus de
667 millions de milliards d'adresses par millimètre carré de surface terrestre. Elles sont découpées en 8 mots de 16 bits
(4 chiffres hexadécimaux) séparés par des « : ». En comparaison les adresses IPv4 sont constituées de 4 octets,
chaque octet étant noté par sa forme décimale; les différents octets étant séparés par des « . »
Exemple : fe80:0000:0000:0000:0240:96ff:fea7:00d3 est une adresse IPv6
Cette notation pouvant être fastidieuse, les méthodes de simplification suivantes ont été définies :
1. La notation « :: » permet de représenter plusieurs 0 consécutifs au sein de plusieurs mots de 16 bits. Le

nombre de 0 peut être retrouvé en examinant le nombre de mots présents dans l’adresse. Cet élément ne peut
être présent qu’une fois au sein de l’adresse,
2. Au sein d’un mot de 16 bits les chiffres hexadécimaux de poids fort positionnés à 0 peuvent être omis.
La méthode de simplification 1 sur l’exemple précédent nous donne fe80::0240:96ff:fea7:00d3 .

En appliquant la méthode 2 on obtient l’adresse fe80::240:96ff:fea7::d3, qui est beaucoup plus lisible.
En IPv6 on abandonne le format classique de masque usité en IPv4 pour décrire un réseau ou un sous-réseau par le
nombre de bits pertinents après le symbole « / ».
Exemple :
• 2a01:e35:2EC0:B6A0::/64 décrit un réseau IPv6 composé des 64 premiers bits.
• FE80::/64 décrit également en format simplifié un réseau IPv6 de 64 bits. Il s’agit en fait de FE80:0000::/64 .
Généralement, les 64 premiers bits de l'adresse IPv6 servent à l'adresse de sous-réseau, tandis que les 64 bits
suivants identifient l'hôte à l'intérieur du sous-réseau.
3.2 Les différents types d’adresses

IPv6 définit 3 types d’adresses :
• Les adresses Unicast : destinées à la communication avec une interface unique,

• Les adresses Multicast : destinées à la communication avec un groupe d’interfaces. La notion de broadcast
utilisée en IPv4 pour joindre l’ensemble des interfaces d’un lien n’existe plus en IPv6 mais est remplacée par ce
type d’adresse beaucoup plus fin,
• Les adresses Anycast : destinées à la communication avec une seule interface d’un groupe donné.
Ces notions seront explicitées par la suite.
3.3 Adressage Unicast

Les adresses Unicast sont destinées à la communication avec une interface unique. Ces adresses sont de deux types
selon leur portée.
• Les adresses Lien-local : destinées à la communication au sein d’un lien,

• Les adresses globales : ayant une portée mondiale et destinées aux échanges de l’Internet IPv6.
Similairement à IPv4, on retrouve en plus une adresse de loopback ainsi qu’une adresse indéterminée.
La notion d’adressage public/privé utilisé en IPv4 est revisitée en IPv6. Chaque interface possède une adresse Lien-
local ainsi que potentiellement une ou plusieurs adresses globales. L’adresse utilisée sera l’une ou l’autre selon la
portée de la communication. Le concept principal d’IPv6 est la communication de bout en bout. Le NAT/PAT (Network
Address Translation/Protocol Address Translation) n’a plus sa place en IPv6. En effet, le NAT bien que considéré
comme un moyen de protection et masquage des réseaux posait de sérieux problèmes sur cette communication de
bout en bout. Un certain nombre d’artifices sont ainsi généralement utilisés pour pallier à la modification des adresses
IPv4 et des ports TCP/UDP (et identifiants ICMP) au niveau des routeurs de bordures. Il est ainsi parfois nécessaire de
disposer en sus d’ALGs (Application Level Gateway) ou passerelles applicatives pour modifier le contenu des charges
utiles des paquets lorsque celles-ci contiennent des informations relatives aux adresses privées. C’est le cas du
protocole FTP (File Transfert Protocol) par exemple, dans lequel les échanges initiaux de contrôle indiquent au niveau
de la charge utile l’adresse ainsi que le port de la session de donnée.
La limitation majeure concerne la sécurisation des échanges de bout en bout. Un chiffrement ou une authentification
utilisant l’adresse de l’émetteur devient ainsi invalide dès lors que l’adresse de celui-ci est modifiée par le routeur de
bordure. Contrairement aux idées reçues le NAT/PAT n’est pas une sécurité fiable et peut donc facilement être
5
abandonné au profit de mécanisme de sécurisation de bout en bout. LE NAT/PAT est simplement un artifice pour palier
à la pénurie d’adresses IPv4.
3.3.1 Identifiant EUI-64

Les adresses MAC (Media Access Control) sont des identifiants physiques stockés dans les cartes ou les interfaces
réseaux afin de permettre un adressage mondial pratiquement unique.
Cette assertion n’est cependant pas garantie, la plupart des drivers permettent maintenant de la modifier manuellement.
Les espaces de nommage suivants, gérés par l’IEEE (Institute of Electrical and Electronics Engineers) sont
couramment utilisés afin d’adresser ces différentes interfaces :
• EUI-64 sur 64 bits,

• MAC-48 sur 48 bits.
Les adresses unicast IPv6 utilisent intensivement une version modifiée de l’EUI-64 (Extended Unique Identifier sur 64
bits) afin de permettre l’identification d’une interface sur un lien. Il est donc requis que ces identifiants d’interface soient
uniques au sein d’un préfixe réseau.
Celles-ci sont formées depuis un identifiant EUI-64 (cf. Figure 1) par inversion d’un bit particulier noté u (universal/local
bit).
Figure 1 : Format d'adressage EUI-64
Les cartes Ethernet, elles, possèdent un identifiant de la forme MAC-48 (cf. Figure 2) et sont exprimées sous la forme
de 12 chiffres hexadécimaux :
• Les 3 premiers octets notés OUI (Organizationally Unique Identifiers) sont administrés par l’IEEE et identifient
le constructeur,
• Les 3 suivants sont à la charge du constructeur et forment le numéro de série de la carte.
Figure 2 : Format d'adressage MAC-48
Le Tableau 1 vous présente ainsi quelques numéros OUI attribués par l’IANA. Chaque carte réseau vendue par Cisco
commence donc par le préfixe 00-00-0C.
Code Fabricant (OUI) sur 3 Vendeur/Fabricant

octets en hexadécimal
00 – 00 – 0C Cisco
00 – 03 – 93 Apple
02 – 80 – 8C 3COM
08 – 00 – 20 SUN
08 – 00 – 5A IBM
Tableau 1. Code Fabricant (OUI) sur 3 octets
Un identifiant EUI-64 modifié est formé depuis cette adresse MAC par inversion du bit u (universal/local bit) et insertion
de la valeur hexadécimale sur deux octets FFFE entre le numéro constructeur et le numéro d’interface (cf. Figure 3).
6
Figure 3 : Création d'un Identifiant d'interface IPv6 depuis une adresse MAC
Exemple : L’adresse Mac 00-40-96-A7-C5-D3 donne ainsi l’identifiant d’interface 02-40-96-FF-FE-A7-C5-D3
3.3.2 Adresses Lien-local

Au niveau d’un lien, les adresses IPv6 sont formées par concaténation du préfixe FE80::/64 à l’identifiant d’interface au
format EUI-64 modifié. La Figure 4 présente un tel type d’adresse.
Figure 4 : Format d’adresse Lien-local IPv6
L’unicité au niveau lien de l’identifiant d’interface assure ainsi l’unicité de l’adresse IPv6 Lien-local.
Ce type d’adresse ne traverse jamais les routeurs.
3.3.3 Adresses Globales

Les adresses Globales sont formées de manière similaire aux adresses Lien-local par concaténation du préfixe réseau
à l’identifiant d’interface au format EUI-64 Modifié. L’unicité au niveau du préfixe de l’identifiant d’interface assurera
également l’unicité mondiale de l’adresse IPv6, les préfixes réseaux étant délivrés par des fournisseurs de service ou
directement des autorités de régulation. La nomenclature d’une telle adresse a été clairement définie afin de
permettre des attributions hiérarchiques de préfixes jusqu’aux sites finaux.
Ce type d’adresse est utilisé pour une communication généralement en dehors d’un réseau local ou LAN (Local Area
Network) voir à l’échelle de l’Internet IPv6.
3.3.4 Adresses de loopback

L’adresse de loopback (127.0.0.1 en IPv4) est utilisée pour représenter le nœud lui-même. Elle ne transite jamais sur le
réseau. Elle est notée ::1
3.3.5 Adresses Indéterminées

Cette adresse est utilisée par exemple lorsque l’interface n’a pas encore connaissance de son adresse (0.0.0.0 en
IPv4). Elle est notée ::
3.4 Adressage Multicast

En IPv4, on dispose de la notion de broadcast afin de permettre la diffusion de paquets à l’ensemble des interfaces
présentes sur un lien. IPv6 raffine cette notion et lui oppose le concept de multicast pour représenter un groupe
d’interfaces potentiellement de portée mondiale. Les adresses multicast (cf. Figure 5) utilisent le préfixe FF00::/8
7
Figure 5 : Format d'adresse Multicast IPv6
Le champ Flag est composé de 4 bits. Les 3 premiers sont réservés et généralement positionnés à 0, le dernier
représente la durée de validité de l’adresse et est positionné à 1 si l’adresse est permanente, le cas échéant il est
positionné à 0.
Le champ Scope indique la portée de l’adresse selon le Tableau 2.
Valeur Portée
1 Interface-local
2 Lien-local
4 Admin-local
5 Site-local (actuellement déprécié)
0, 3, F Réservé
6, 7, A, B, C, D Non assigné
Tableau 2. Portée des adresses Multicast.
Les adresses multicast se dérivent encore en 2 groupes :
• Adresses multicast prédéfinies : leur champ Flag vaut 0 et elles sont généralement définies par une autorité
telle que l’IANA (Internet Assigned Numbers Authority) chargée de la gestion de l'espace d'adressage IP ainsi
que d’autres ressources partagées de numérotation requises soit par les protocoles de communication, soit
pour l'interconnexion de réseaux à l’Internet.
Le Tableau 3 donne pour exemple certains groupes importants régis par l’IANA.
Préfixe Groupe
FF01::1 Tous les nœuds de l’interface
FF02::1 Tous les nœuds du lien
FF01::1 Tous les routeurs de l’interface
FF02::2 Tous les routeurs du lien
FF02::9 Tous les routeurs RIPng
Tableau 3. Quelques Groupes Multicast prédéfinis.
• Adresses Multicast sollicitées : ce type d’adresse est une fonction des adresses anycast/unicast. Pour
chaque adresse unicast ou anycast configurée, une interface écoute sur une adresse multicast de ce type.
Ce type d’adresse est formé par combinaison du préfixe FF02 :0 :0 :0 :0 :1 :FF00/104 avec les 24 derniers bits
de l’adresse unicast/anycast. Nous verrons par la suite que ce type d’adresse permet de limiter la diffusion pour
le protocole de Neighbor Discovery (découverte des voisins) et en particulier le DAD (Détection D’adresse
Dupliquée) contrairement au protocole ARP (Address Resolution Protocol) d’IPv4.
Pour exemple l’adresse IPv6 4037::01:800:200E:8C6C donne l’adresse sollicitée FF02::1:FF0E:8C6C.
3.5 Adressage Anycast

Une adresse anycast permet de représenter un service plutôt qu’une interface donnée. On veut ainsi pouvoir joindre
une machine fournissant certains services sans se soucier de la machine contactée. Elle est très peu utilisée pour
l’instant et pose naturellement des problèmes de sécurité.
3.6 DNSv6
On rappelle que le DNS (Domain Name System) permet l’obtention d’un nom plus lisible à partir d’une adresse et
inversement à partir du moment où ce nom a été enregistré dans une hiérarchie de serveur DNS.
Le format des adresses IPv6 étant naturellement plus long, la question d’une mise à jour du DNS était évidente.
8
En IPv4, la transformation nom DNS vers adresse IP est définie par un enregistrement nommé A. En IPv6, la taille des
adresses étant 4 fois plus importante le quadruplé AAAA est utilisé.
La capture présentée en Figure 6 montre ainsi une requête DNSv6 sous Windows XP en utilisant la commande
nslookup. On remarquera en particulier que le serveur DNS est adressé en IPv4 bien que l’on fasse une requête IPv6. Il
en va de même pour un serveur IPv6, celui-ci peut très bien répondre à des requêtes pour des adresses IPv4. Si l’on
avait ici effectué une requête pour obtenir toutes les adresses de www.kame.net, on aurait obtenu l’ensemble de ses
adresses IPv4 et IPv6.
Figure 6 : Exemple de résolution DNSv6 avec nslookup
La transformation inverse depuis l’adresse vers le nom est similaire en IPv4 et IPv6 et utilise un enregistrement PTR
(Seul l’arbre DNS inverse est différent : in.addr.arpa pour ipv4 et ip6.arpa pour IPv6).
Il a précédemment été indiqué qu’une adresse IPv6 était formée par combinaison d’un préfixe et d’un identifiant
d’interface dépendant de son adresse de niveau liaison de donnée. On comprend donc qu’un changement d’interface
impacte potentiellement l’adresse IPv6 de l’interface et de là même les enregistrements DNSv6. Ce souci a amené des
réflexions sur la mise à jour sécurisée de ces différents enregistrements au travers d’un protocole baptisé DNSsec
(Domain Name System Security Extensions). Ce protocole ne sécurise pas uniquement les échanges mais protège
également les données ainsi que les enregistrements DNS de bout en bout par une hiérarchie de clés. Chaque
domaine signant son sous-domaine … Malheureusement à l’heure actuelle ce protocole est très peu usité. Seuls
quelques domaines sont ainsi sécurisés. Le RIPE-NCC (responsable du domaine in-addr.arpa) par exemple signe ainsi
ses enregistrements avec DNSsec.
4. Entête IPv6
L’entête IPv6 a été soigneusement pensé afin de supprimer les incohérences et problèmes rencontrés en IPv4.
En particulier :
• Le checksum ou somme de contrôle calculé sur l’entête n’est plus présent. On considère les réseaux
suffisamment fiables pour ne pas avoir besoin de vérifier ce champ d’autant plus que dans le cas d’IPv4 celui-ci
est vérifié et recalculé par chaque routeur présent le long du chemin. En effet ce checksum inclus le champ
TTL (Time To Live) décrémenté par chaque routeur lors du transfert du paquet. Ce champ TTL est destiné à
éviter qu’un paquet boucle indéfiniment dans le réseau. Ainsi les routeurs rencontrant un paquet avec un
champ TTL à 0 se doivent de le jeter. Les protocoles de niveau supérieur (niveau transport) auront la charge de
vérifier l’intégrité des paquets,
• Les champs relatifs à la fragmentation ont été supprimés de l’entête. En IPv6, les paquets ne sont plus
fragmentés le long du chemin mais sont fragmentés par la source. La source se doit donc de connaître le Path
MTU (Maximum Transmission Unit) ou taille maximum des informations pouvant transiter le long du chemin. Un
protocole dédié baptisé Path MTU Discovery a donc été soigneusement défini dans cette optique. Afin de
faciliter ce protocole un MTU minimum de 1280 octets est exigé sur les différents liens utilisant IPv6,
• Les options et en particulier leur alignement étaient assez mal gérés en IPv4 rendant ainsi difficile une gestion
hardware de celles-ci. Ces problèmes ont été corrigés en IPv6. Elles sont maintenant baptisées extensions
header et sont chaînées entre elles de manière plus cohérente.
Bien entendu les adresses IPv6 étant 4 fois plus grandes, l’entête IPv6 est également plus grand. Il fait 40 octets pour
l’entête minimal alors que l’entête IPv4 n’en fait que 20. On constatera néanmoins que les 2 adresses IPv6 de l’entête
représentent déjà 32 octets alors que les 2 adresses IPv4 n’en font que 8 (i.e. 24 octets de plus).
Les Figures 7 et 8 vous présentent l’entête IPv6 minimal ainsi que l’entête IPv4 pour comparaison. La signification des
différents champs de l’entête IPv6 est précisée dans le Tableau 4.
9
Voici donc l’entête IPv6 minimal ainsi que l’entête IPv4 pour comparaison :
Figure 7 : Entête IPv4
Figure 8 : Entête IPv6
Champs Taille Rôle

Version 4 bits Décrit la version du protocole. Vaut 6 pour IPv6.
Traffic Class 8 bits Destiné pour faire de la QoS par priorisation, shaping de trafic … ayant pour but d’offrir
des fonctions de qualité de service comme Diffserv.
Flow Label 20 bits Incomplètement spécifié actuellement. Numéro unique choisi par la source, ayant pour
but d’offrir des fonctions de qualité de service comme RSVP.
Payload Length 16 bits Longueur en octet de la charge utile du paquet. En présence d’extension d’entête, ceux-
ci sont comptabilisés par ce champ. En IPv4, un champ similaire Total Length
comptabilise en plus l’entête ce qui finalement est inutile et limite la taille totale de la
charge utile du paquet.
Next Header 8 bits Décrit l’entête de la couche immédiatement supérieure ou la prochaine extension
d’entête. Similaire au champ Protocol en IPv4.
Hop Limit 8 bits Décrémenté par chaque routeur présent le long du chemin. Le paquet est jeté si ce
champ devient nul permettant ainsi d’éviter que le paquet boucle indéfiniment dans le
réseau. Similaire au champ TTL en IPv4.
Source Address 128 bits Contient une adresse unicast de l’émetteur du paquet.
Destination 128 bits Contient l’adresse du ou des destinataires du paquet.
Address
Tableau 4. Champs de l’entête IPv6.
4.1 Chaînage des entêtes et extensions d’entête

Les différents entêtes de niveau supérieur ainsi que les options IPv6 sont chaînés entre eux par l’utilisation d’un champ
Next Header.
10
Figure 9 : Chaînage des entêtes et extensions d'entête IPv6
Le Tableau 5 présente quelques-unes des valeurs de ce champ Next Header définies par l’IANA.
Protocoles Valeur du champ Next

Header précédent
TCP 6
UDP 17
IPv6 41
ICMPv6 58
No Next Header 59
Encapsulation IP 94
Tableau 5. Valeurs principales du champ Next Header.
Le nombre d’options minimales et obligatoires implémentées sur les piles IPv6 est moins important qu’en IPv4. On
distingue les extensions d’entêtes suivants :
• Hop-by-Hop Options Header,

• Fragment Header,
• Destination Options Header,
• Authentication Header (AH),
• Encapsulating Security Payload (ESP).
Historiquement IPv6 incluait également un entête baptisé Routing Header de type 0, similaire à l’option Loose Source
Routing en IPv4. Cette option permet de traverser des routeurs prédéfinis lors de l’acheminement du paquet. Cet
entête contenait ainsi une liste d’adresses à traverser et lorsque la première cible indiquée dans l’adresse de
destination du paquet était atteinte, celle-ci échangeait son adresse avec la première adresse de la liste et ainsi de suite
jusqu’au dernier élément de la liste. Le nombre d’adresses présentes pouvant être relativement important au sein de
cette liste, cette option pouvait être plus facilement utilisée en IPv6 pour effectuer des attaques par déni de service en
créant des boucles dans ces listes. Cette extension d’entête a donc été dépréciée.
Le Tableau 6 présente les valeurs utilisées dans les champs Next Header précédent afin de permettre le chaînage de
ces différentes extensions d’entête.
Extension d’entête Valeur du champ Next

Header précédent
Hop-by-Hop Options Header 0
Fragment Header 44
Destination Options Header 60
Authentication Header 51
Encapsulating Security Payload 50
Tableau 6. Valeurs principales du champ Next Header pour les extensions d’entête.
Ces extensions d’entête ont parfois des contraintes d’alignement. Dans ces cas-là des sous-options de bourrage sont
utilisées.
11
4.1.1 Hop-By-Hop Option Header
Cette extension d’entête est analysée par l’ensemble des routeurs présent le long du chemin.
Le rôle des différents champs est précisé dans le Tableau 7. On pourra se reporter à la Figure 10 pour le format de
l’entête.
Figure 10 : Extension d'entête Hop-By-Hop
Champs Taille Rôle

d’entête.
Hdr Ext Len 8 bits Longueur de l’entête en mot de 8 bits sans prendre en compte les 8 premiers bits.
Options Variable Contient une ou plusieurs sous-options adéquates au protocole usité. La taille de ce
champ est telle que l’extension d’entête soit un multiple de 8 octets.
Tableau 7. Champ de l’extension d’entête Hop-By-Hop Option Header.
4.1.2 Fragment Header

Cette extension d’entête est utilisée pour transférer un fragment de paquet, le paquet originel étant supérieur au Path
MTU (MTU minimum entre la source et la destination). En IPv6 la fragmentation est effectuée de bout en bout et non
plus dans le cœur de réseau comme en IPv4. Ceci sera reprécisé par la suite avec la notion de Path MTU Discovery.
Grossièrement l’émetteur fragmente le paquet originel en petits fragments de taille inférieure ou égale au Path MTU.
Ces fragments seront réassemblés par la destination avant transmission à la couche de niveau transport.
l’entête.
Figure 11 : Extension d'entête Fragment Header
Champs Taille Rôle

d’entête.
Reserved 8 bits Réservé pour une utilisation future.
Fragment Offset 13 bits Offset en unité de 8 octets relativement au début de la partie fragmentable du paquet
originel.
Res 2 bits Réservé.
M 1 bit Positionné à 1 s’il y a d’autres fragments ultérieurs, à 0 sinon.
Identification 32 bits Identificateur commun à l’ensemble des fragments.
Tableau 8. Champ de l’extension d’entête Fragment Header.
4.1.3 Destination Option Header

Cette extension d’entête est utilisée pour transférer des informations complémentaires uniquement analysées par la
destination.
l’entête.
12
Figure 12 : Extension d'entête Destination Option Header
Champs Taille Rôle

d’entête.
Hdr Ext Len 8 bits Longueur de l’entête en mot de 8 bits sans prendre en compte les 8 premiers bits.
Options Variable Contient une ou plusieurs sous-options adéquates au protocole usité. La taille de ce
champ est telle que l’extension d’entête soit un multiple de 8 octets.
Tableau 9. Champ de l’extension d’entête Destination Option Header.
4.1.4 Authentication Header & Encapsulating Security Payload

Ces extensions d’entête sont utilisées par le protocole IPsec, chargé de la sécurité du paquet. Ces extensions ainsi que
le protocole IPsec seront décrits ultérieurement.
5. Protocoles de niveau Transport pour IPv6 : TCP & UDP

Les protocoles de niveau transport sont légèrement impactés par cette nouvelle version du protocole. Leurs
comportements ainsi que leur entêtes restent à l’identique mais étant donné que l’entête IPv6 n’inclut pas de checksum
et que les adresses sont plus grandes, quelques modifications sont à prendre en considération.
1. En IPv4, UDP n’a pas pour obligation de remplir son champ checksum. Avec IPv6, ce calcul devient obligatoire
pour UDP étant donné que l’entête IPv6 n’inclut pas de champ checksum,
2. Les calculs de checksum, aussi bien en IPv4 qu’en IPv6 pour UDP et TCP s’effectuent sur l’entête UDP ou
TCP suivi de la charge utile du protocole de niveau transport et précédé d’un pseudo-header incluant entre
autre les adresses source et destination IP. Ce pseudo-Header étant légèrement différent entre les deux
versions, les adresses étant de tailles différentes, le calcul du checksum est lui aussi légèrement modifié. Sans
rentrer dans les détails le calcul est le complément à 1 sur 16 bits de la somme des compléments à 1 de tous
les mots de 16 bits présents dans cette concaténation d’entêtes.
Les Figures 13 et 14 présentent le pseudo-Header utilisé en IPv4 ainsi qu’en IPv6.
Figure 13 : Pseudo-header IPv4
13
Figure 14 : Pseudo-Header IPv6
6. ICMPv6
ICMPv6 (Internet Control Message Protocol) est un protocole de niveau 3 sur le modèle en couche TCP/IP, qui permet
le contrôle des erreurs de transmission. En effet, comme le protocole IPv6 ne gère que le transport des paquets et ne
permet pas l'envoi de messages d'erreur, c'est grâce à ce protocole qu'une machine émettrice peut savoir qu'il y a eu
un incident de réseau.
ICMPv6 est plus que le pendant d’ICMP pour IPv4, dans la mesure où il reprend ses spécificités et y ajoute d’autres
autrefois subdivisées dans divers protocoles indépendants. On distingue en particulier :
• la résolution d’adresse, la détection d’adresse double … intégrés auparavant dans ARP (Address Resolution
Protocol) pour IPv4. Ces nouveautés seront par la suite décrites au sein du protocole baptisé Neighbor
Discovery,
• la gestion de groupes multicast définie auparavant dans IGMP (Internet Group Management Protocol) pour
IPv4. Ce mécanisme est à présent nommé MLD (Multicast Listener Discovery),
• La découverte du Path MTU, par le mécanisme Path MTU Discovery.
Ces différents messages se classifient en 2 catégories :
• Messages d’erreur : notés de 0 à 127 inclus,

• Messages informationnels : notés de 128 à 255 inclus.
6.1 Entête ICMPv6

L’entête commun à l’ensemble des messages ICMPv6 est présenté en Figure 15. Le rôle des champs génériques
principaux est indiqué dans le Tableau 10.
Figure 15 : Entête ICMPv6 générique
Champs Taille Rôle

Type 8 bits Indique le type de message ICMPv6.
Code 8 bits Positionné à 0.
Checksum 16 bits Somme de contrôle afin de détecter des erreurs éventuelles de transmission.
14
Content Variable Spécifique au type de message ICMPv6 usité.
Tableau 10. Champ de l’entête ICMPv6.
6.2 Messages d’erreurs

Les messages d’erreurs ICMPv6 sont similaires à ceux utilisés en ICMPv4. Ceux-ci sont indiqués dans le Tableau 11.
Messages d’erreurs Valeur du champ Type

Destination Unreachable 1
Packet too Big 2
Time Exceeded 3
Parameter Problem 4
Tableau 11. Champ Type des messages d’erreur ICMPv6.
Les entêtes de ces différents messages d’erreurs sont relativement proches.
6.2.1 Destination Unreachable

Un routeur ne pouvant transférer un paquet pour une quelconque raison telle que par exemple par manque de
connaissance sur la route à emprunter, par cause d’outrepassement de la politique de sécurité devrait générer un tel
message à l’entité émettrice avant de rejeter le paquet. La charge utile de ce message contient une partie du paquet
responsable de telle manière que la taille totale du paquet ICMPv6 ne dépasse pas le MTU minimum IPv6 (i.e. 1280
octets). En cas de rejet par cause de congestion un routeur ne doit jamais générer un tel paquet, il ne ferait
qu’accentuer la congestion.
De la même manière une entité destinatrice peut générer un tel paquet si le protocole de niveau transport ne dispose
pas par exemple de serveur en écoute sur le port que l’émetteur cherche à joindre.
l’entête.
Figure 16 : Entête ICMPv6 Destination Unreachable
Champs Taille Rôle

Type 8 bits Vaut 1.
Code 8 bits Précise la cause de rejet du paquet :
0 : Pas de route pour la destination,
1 : Interdiction administrative,
2 : Portée de la destination en inadéquation avec la source,
3 : Adresse non joignable,
4 : Port non joignable,
5 : Rejet suite à la politique ingress/egress de l’adresse source,
6 : Rejet suite à une politique de route vers la destination.
Unused 32 bits Positionné à 0.
Content Variable Contient une partie du paquet responsable de telle manière que la taille totale du paquet
ICMPv6 ne dépasse pas le MTU minimum IPv6.
Tableau 12. Champs de l’entête ICMPv6 Destination Unreachable.
15
6.2.2 Packet Too Big
Ce type de message est particulièrement intéressant pour la détection du MTU minimum présent le long du chemin (Cf.
Path MTU Discovery). Un routeur devant transférer un message sur un lien ne pouvant le contenir utilise ce type de
message en précisant la taille du MTU limitatif pour en informer l’émetteur. La charge utile de ce message contient une
partie du paquet responsable de telle manière que la taille totale du paquet ICMPv6 ne dépasse pas le MTU minimum
IPv6 (i.e. 1280 octets).
l’entête.
Figure 17 : Entête ICMPv6 Packet Too Big
Champs Taille Rôle

Type 8 bits Vaut 2.
MTU 32 bits Indique le MTU limitatif.
ICMPv6 ne dépasse pas le MTU minimum IPv6
Tableau 13. Champs de l’entête ICMPv6 Packet Too Big.
6.2.3 Time Exceeded

Ce type de message est généré par un routeur lorsque le champ Hop Limit du paquet IPv6 à transmettre atteint ou est
égal à 0. Les paquets IPv6 présentant une telle spécificité sont jetés.
C’est en particulier ce type de message qui permet de connaître la route utilisée entre 2 points de communication par la
commande classique traceroute6. Dans un cadre d’utilisation classique de cette commande, l’émetteur transmet des
paquets IPv6 vers la destination en incrémentant le champ Hop Limit à partir de la valeur 1. Le premier routeur recevra
donc un tel paquet avec un champ Hop Limit à 1, décrémentera ce champ à 0 et générera un paquet Time Exceeded
vers la source ; le second routeur recevra également un paquet avec un champ Hop Limit à 1, décrémentera ce champ
à 0 et générera un paquet Time Exceeded vers la source … et ainsi de suite jusqu’à la destination finale.
l’entête.
Figure 18 : Entête ICMPv6 Time Exceeded
Champs Taille Rôle

Type 8 bits Vaut 3.
Unused 32 bits Positionné à 0.
16
Content Variable contient une partie du paquet responsable de telle manière que la taille totale du paquet
Tableau 14. Champs de l’entête ICMPv6 Time Exceeded.
6.2.4 Parameter Problem

Ce type de message est généré par un routeur ne pouvant parser un paquet IPv6 suite à une erreur rencontrée dans
l’entête ou dans les entêtes d’extension.
l’entête.
Figure 19 : Entête ICMPv6 Parameter Problem
Champs Taille Rôle

Type 8 bits Vaut 4.
Code 8 bits Précise la cause du problème rencontré :
0 : Erreur dans un champ de l’entête,
1 : Erreur dans le champ Next Header,
2 : Erreur dans une extension d’entête.
Pointer 32 bits Pointeur sur l’octet responsable de l’erreur.
Tableau 15. Champs de l’entête ICMPv6 Parameter Problem.
6.3 Messages informationnels

Les messages d’information ICMPv6 principaux sont indiqués dans le Tableau 16 :
Messages Informationnels Valeur du champ Caractère du message

Type
Echo Request 128
Echo Reply 129 Informatif
Group Membership Query 130 Gestion des groupes
Group Membership Report 131 Multicast (MLD)
Group Membership Reduction 132
Router Solicitation 133 Neighbor Discovery
Router Advertisement 134
Neighbor Solicitation 135
Neighbor Advertisement 136
Redirect 137
Tableau 16. Champ Type des messages informationnels ICMPv6.
Dans ce paragraphe, seuls seront précisés les messages à caractère informatif. Ceux relatifs au Neighbor Discovery
seront explicités dans le paragraphe associé.
6.3.1 Echo Request / Echo Reply

Ces paquets sont utilisés comme sonde pour détecter si une machine est joignable ou non.
17
Lorsque un paquet ICMPv6 Echo Request est transmis à une interface celle-ci doit répondre à la machine émettrice par
un paquet ICMPv6 Echo Reply en utilisant un adressage source de même portée. Ce type de message est
principalement utilisé par la commande classique ping6.
Le rôle des différents champs est précisé dans le Tableau 17, le format de l’entête est indiqué dans la Figure 20.
Figure 20 : Entête ICMPv6 Echo Request/Reply
Champs Taille Rôle

Type 8 bits Vaut 128 pour Echo Request, 129 pour Echo Reply.
Code 8 bits Vaut 0.
Identifier 16 bits Permet d’identifier le couple Echo Request/Echo Reply.
Sequence 16 bits Permet d’identifier le couple Echo Request/Echo Reply.
Number
Data Variable Données éventuelles à l’identique dans l’Echo Request et l’Echo Reply.
Tableau 17. Champs de l’entête ICMPv6 Echo Request/Echo Reply.
7. Fragmentation & Path MTU Discovery

On rappelle auparavant que le MTU (Maximum Transmission Unit) est la quantité d’information maximum pouvant
traverser un lien. Le Path MTU est ainsi le MTU minimum du chemin entre la source et la destination.
Il a auparavant été précisé qu’en IPv6 le concept de fragmentation est complètement différent étant donné que le cœur
de réseau n’a plus cette tâche. Si besoin est de transmettre des paquets de taille supérieure au Path MTU, la
fragmentation est réalisée par l’initiateur des paquets. Afin de limiter les problèmes de transmission de paquets, IPv6
impose un MTU minimum de 1280 octets.
Toutefois cette définition du minimum n’impose en aucune façon que les paquets transmis fassent au plus 1280 octets.
La découverte du Path MTU peut s’effectuer à l’aide d’un protocole très simple baptisé Path MTU Discovery. Celui-ci
repose principalement sur les paquets ICMPv6 Packet Too Big. Un routeur devant transmettre un paquet d’une taille
supérieure au lien doit rejeter ce paquet et envoyer un paquet ICMPv6 Packet Too Big à l’émetteur en lui indiquant le
MTU du lien concerné. L’émetteur aura alors à charge de fragmenter le paquet en utilisant les extensions d’entête
Fragment Header et de réexpédier ces fragments qui pourront par la suite éventuellement poser problème pour un
autre routeur.
Exemple : dans l’exemple de la Figure 21, H1 souhaite transférer 1460 octets de données vers R2. Avec les 40 octets
d’entête IPv6, H1 génère un paquet de 1500 octets et le transmet à R1. Or le MTU entre R1 et R2 est de 1280 octets
(MTU minimum pour IPv6) ; R1 transmet donc un paquet ICMPv6 Packet Too Big à H1 en lui indiquant ce MTU de
1280 octets ; charge sera alors à H1 de fragmenter ce paquet et d’émettre à nouveau ces fragments. La composition
des fragments peut donc être de 1232 octets de données (+40 octets d’entête IPv6 +8 octets d’entête de fragmentation)
pour le 1er fragment et 128 octets de données (+40 octets d’entête IPv6 +8 octets d’entête de fragmentation) pour le
2ème fragment.
18
Figure 21 : Exemple de Fragmentation à la source
Au cours du temps ce Path MTU peut bien entendu augmenter à nouveau, parce que la route est modifiée, un tunnel
est supprimé, une interface changée … Dans un souci d’un meilleur remplissage des paquets, la source enverra de
temps en temps des paquets d’une taille supérieure au Path MTU détecté afin de tester une éventuelle augmentation
de celui-ci.
8. Neighbor Discovery Protocol (Découverte des voisins)

Le protocole de Neighbor Discovery est un protocole indissociable d’IPv6. Il a été conçu pour faire d’IPv6 un protocole
plug-and-play. L’idée sous-jacente du Neighbor Discovery est de supprimer toute configuration réseau manuelle des
interfaces. Il suffit de connecter l’interface sur un réseau, pour qu’automatiquement, les adresses, la route par défaut, le
MTU … soient initialisés. Bien évidemment, il ne s’agit ici que des machines n’ayant pas le rôle de routeur.
Ce protocole regroupe les fonctionnalités suivantes :
• découverte des routeurs présents sur le lien,

• découverte des préfixes du lien,
• découvertes de certains paramètres du lien : MTU …,
• configuration automatique sans état des adresses Lien-local et globale,
• résolution d’adresse,
• découverte des routes par défaut ainsi que des prochains routeurs pour une destination donnée,
• Neighbor Unreachability Detection (NUD) : permet de déterminer qu’une entité du lien n’est plus joignable,
• Duplicate Address Detection (DAD) : détection d’adresse dupliquée,
• mécanisme de redirection.
Ce protocole n’est pas réellement sécurisé (même si les spécifications initiales laissent supposer une utilisation
potentielle conjointe d’IPsec) dans sa version usuelle étant donné qu’il prend place sur un réseau local principalement.
Des extensions telles que SEND (SEcure Neighbor Discovery) utilisant des signatures RSA sont possibles afin
d’améliorer la sécurité de celui-ci.
Ce protocole a cependant l’inconvénient de nécessiter un sous-réseau à diffusion. Les réseaux NBMA (Non Broadcast
Multiple Access) tel qu'ATM ou X25 nécessitent l’utilisation d’un protocole spécifique comprenant par exemple un
routeur disposant d’une connexion point à point avec toutes les interfaces présentes.
8.1 Entêtes de messages du Protocole Neighbor Discovery

Le Neighbor Discovery s’appuie essentiellement sur la couche ICMPv6 et définit pour cette couche 5 messages : 2 pour
la communication entre une interface et un routeur, 2 pour le dialogue entre voisins et 1 pour la redirection (celle-ci
souvent non autorisée sera laissée de côté).
8.1.1 Sollicitation et annonces des routeurs

Ces types de messages sont utilisés en particulier pour obtenir :
19
• L’adresse des routeurs disponibles,
• Les préfixes réseaux à utiliser,
• Le routeur par défaut,
• Le mécanisme de configuration des adresses : avec Etat (DHCPv6), sans Etat,
• La valeur des champs génériques à utiliser dans les paquets IPv6 générés : Hop Limit, MTU du lien,
• Les valeurs de certains timers spécifiques : durée de vie d’un routeur, temps de conservation des adresses des
voisins …
Dans cet optique 2 messages ont été définis :
• Router Solicitation : une machine placée sur un lien envoie spontanément à l’adresse FFO2 ::1 (tous les
routeurs sur le lien) une telle requête afin de disposer des informations nécessaires à sa configuration. Lorsque
l’équipement ne dispose pas encore de son adresse, ce type de requête est émis en utilisant l’adresse
indéterminée (::) en tant que source,
• Router Advertisement : spontanément un routeur positionné sur un lien envoie à intervalles réguliers ce type
d’annonce afin de permettre aux machines présentes sur le lien de s’autoconfigurer. Ce type de message est
également transmis en réponse à une requête Router Solicitation. Dans tous les cas l’adresse source utilisée
est l’adresse lien-local du routeur. Selon les cas l’adresse destination est l’adresse de tous les nœuds ou
l’adresse de la machine ayant effectué la requête.
Comme plusieurs routeurs peuvent émettre ce type d’annonce, les machines présentent sur le lien pourront ainsi
disposer de plusieurs routeurs en cas de panne. Ceci permet également de faire du Multihoming si le site concerné a
établit des accords avec plusieurs ISP (Internet Service Provider) ou FAI (Fournisseur d'Accès à Internet) en français.
L’entête Router Solicitation est très proche de celle usitée pour les messages d’erreurs ICMPv6. Il est décrit par la
Figure 22. Le Tableau 18 présente les différents champs de l’entête Router Solicitation.
Figure 22 : Entête ICMPv6 Router Solicitation
Champs Taille Rôle

Type 8 bits Vaut 133.
Reserved 32 bits Positionné à 0.
Options Variable Peut contenir par exemple une sous-option Source Link Layer Address indiquant
l’adresse MAC de l’expéditeur.
Tableau 18. Champs de l’entête ICMPv6 Router Solicitation.
Le Tableau 19 présente les différents champs de l’entête Router Advertisement, l’entête quant-à lui, est précisé dans la
Figure 23.
20
Figure 23 : Entête ICMPv6 Router Advertisement
Champs Taille Rôle

Cur Hop Limit 8 bits Valeur par défaut que les Machines doivent utiliser pour le champ Hop Limit des
paquets générés. La valeur 0 indique que ce champ n’est pas spécifié par le routeur.
M 1 bit Positionné à 1 pour indiquer que la configuration d’adresse se fait par DHCPv6.
O 1 bit Positionné à 1 pour indiquer que certains paramètres de configuration supplémentaires
sont disponibles via DHCPv6. Ce champ est redondant lorsque le champ M est
positionné à 1.
Router Lifetime 16 bits Indique la durée de vie (en secondes) de ce routeur en tant que routeur par défaut.
Lorsque ce champ est positionné à 0, le routeur ne doit pas être considéré comme le
routeur par défaut.
Reachable Time 32 bits Durée (en millisecondes) pendant laquelle une machine doit considérer qu’une machine
est toujours joignable depuis sa dernière détection.
Retrans Timer 32 bits Temps (en millisecondes) entre 2 retransmissions de messages Neighbor Solicitation.
Options Variable Peut contenir par exemple une sous-option :
• Source Link Layer Address indiquant l’adresse MAC de l’expéditeur,
• MTU indiquant l’adresse la taille de MTU usitée,
• Prefix Information indiquant les préfixes réseaux à utiliser.
Tableau 19. Champs de l’entête ICMPv6 Router Advertisement.
8.1.2 Sollicitation et annonces des voisins

Ces types de message sont principalement utilisés pour :
• Obtenir l’adresse MAC d’une machine à partir de son IP ou inversement,

• Vérifier l’unicité d’une adresse IPv6 avant son utilisation,
• Forcer une mise à jour des caches associant adresses MAC et adresses IP (caches NDP).
En IPv4, ces fonctionnalités sont effectuées par le protocole ARP (Address Resolution Protocol) ou RARP (Reverse
Address Resolution Protocol). Une machine voulant envoyer un paquet à une autre (elles peuvent être toutes deux des
routeurs) doit obtenir dans un premier temps son adresse MAC. Elle effectue alors une requête ARP. La réponse
associée permet de remplir un cache ARP associant adresses MAC et adresses IP. Chaque entrée à une durée de vie.
En IPv6, un tel cache existe également, le cache NDP (Neighbor Discovery Protocol). Il contient des adresses Lien-
local ou globale mais présentes sur le lien. Deux messages permettent ces différentes fonctionnalités :
• Neighbor Solicitation : une machine voulant effectuer une résolution d’adresse envoie sur le lien ce type de
requête en unicast. De la même manière, une machine s’initialisant vérifie l’unicité d’une adresse au niveau du
lien avant de pouvoir l’utiliser en envoyant ce type de requête à l’adresse multicast sollicitée associée,
• Neighbor Advertisement : une interface recevant un Neighbor Sollicitation doit répondre avec un Neighbor
Advertisement soit pour renseigner son adresse MAC, soit pour invalider l’adresse IP qu’une autre interface
21
tenterait d’utiliser. Les Neighbor Advertisements peuvent également être émis spontanément pour mettre à jour
les entrées des caches NDP.
Le Tableau 20 présente les différents champs de l’entête Neighbor Solicitation, l’entête quant-à lui, est précisé dans la
Figure 24.
Figure 24 : Entête ICMPv6 Neighbor Solicitation
Champs Taille Rôle

Target Address Variable Adresse de la cible sollicitée. Ne doit pas être une adresse Multicast.
Options Variable Peut contenir par exemple une sous-option Source Link Layer Address indiquant
l’adresse MAC de l’expéditeur.
Tableau 20. Champs de l’entête ICMPv6 Neighbor Solicitation.
Le Tableau 21 présente les différents champs de l’entête Neighbor Advertisement, l’entête quant-à lui, est précisé dans
la Figure 25.
Figure 25 : Entête ICMPv6 Neighbor Advertisement
Champs Taille Rôle

R 1 bit Positionné à 1 pour indiquer que l‘expéditeur est un routeur.
S 1 bit Positionné à 1 pour indiquer que la réponse l’est suite à une requête d’un message
Neighbor Solicitation.
O 1 bit Positionné à 1 pour indiquer que cette réponse doit mettre à jour l’entrée du cache
NDP.
Target Address 32 bits En réponse à des Neighbor Solicitation, contient l’adresse de l’entité ayant effectuée
cette requête, sinon contient l’adresse dont l’identifiant d’interface a changé.
Options Variable Peut contenir par exemple une sous-option Target Link Layer Address indiquant
l’adresse MAC de l’expéditeur de ce message.
22
Tableau 21. Champs de l’entête ICMPv6 Neighbor Advertisement.
8.2 Détection d’Adresse Dupliquée (DAD) & Autoconfiguration sans état

Par simple combinaison des messages du Neighbor Discovery, une interface peut s’autoconfigurer automatiquement.
1. Une machine s’initialisant sur un lien, construit dans un premier temps son identifiant d’interface EUI-64 modifié
à l’aide de l’adresse de sa couche de niveau liaison de données. Puis elle construit son adresse Lien-local
temporaire par concaténation du préfixe FE80::/64 avec cet identifiant,
2. Elle a ensuite pour charge de vérifier l’unicité de cette adresse lien-local ainsi que de son identifiant d’interface.
Pour cela elle utilise un algorithme de détection d’adresse dupliquée (DAD : Duplicate Address Detection). Elle
envoie à l’adresse solicited multicast un paquet Neighbor Solicitation avec pour champ adresse de la cible
l'adresse provisoire. Ne disposant pas encore d’une adresse validée, elle utilise comme adresse source
l’adresse indéterminée. Si elle ne reçoit pas de réponse en retour, cette adresse est considérée comme étant
unique, et est donc associée à l’interface. Dans le cas où une réponse, lui parvient, elle ne pourra donc pas
utiliser cette adresse, une intervention humaine sera alors indispensable. Il est clair que dans le cas d’une
panne de lien, au moment de la réparation de ce dernier un conflit d’adresse pourra être détecté.
3. La machine disposant à présent d’une adresse Lien-local, il s’agit donc pour elle d’obtenir une adresse globale
routable sur l’internet IPv6. Pour cela, elle dispose de deux possibilités :
a. Soit par l’intermédiaire d’un serveur DHCPv6 (autoconfiguration avec état), procédure standard en
IPv4,
b. Soit par autoconfiguration sans état éventuellement complétée par un serveur DHCPv6.
4. Dans le cas de l’autoconfiguration sans état, l’interface cherche à acquérir un Router Advertisement
(spontanément ou par un Router Solicitation). Ce Routeur Advertisement lui donnera les préfixes réseaux, les
routes par défaut, éventuellement le MTU du lien, les durées de validités de certains timers … Elle peut donc
ainsi construire à l’aide de son identifiant d’interface, déterminé comme unique, ses différentes adresses
globales,
5. Dans le cas où le bit O du Router Advertisement est positionné à 1, l’interface cherchera à obtenir des
informations complémentaires par DHCPv6 (tel que le DNS par exemple).
Le diagramme d’états de la Figure 26 résume ces différentes étapes :
23
Figure 26 : Configuration Automatique
8.3 Résolution d’adresse

La résolution d’adresse en IPv6 est comme précisée auparavant identique à celle d’IPv4. Une machine désireuse
d’envoyer un paquet à une autre (routeur ou non) doit auparavant résoudre son adresse de niveau liaison de donnée.
Elle effectue ainsi les étapes suivantes :
1. Vérification de la présence de l’adresse IP dans le cache NDP. Si celle-ci est déjà présente et qu’elle n’a pas
expirée, le processus est achevé, elle peut transmettre le paquet à l’interface en question. Dans le cas
contraire, elle émet un Neighbor Solicitation pour l’interface concernée,
2. L’interface ainsi atteinte répond par un Neighbor Advertisement afin de renseigner son adresse de niveau
liaison de données,
3. L’émetteur remplit alors son cache NDP avec le couple (adresse IPv6, adresse MAC) en y ajoutant une durée
de validité. L’émetteur peut alors transmettre le paquet en utilisant l’adresse MAC correspondante.
Ces étapes sont graphiquement présentées dans la Figure 27.
24
Figure 27 : Résolution d’adresse
9. Mécanismes de transition & Intéropérabilité IPv4/IPv6 ?

L'ensemble des protocoles de niveau réseau ayant été modifié avec IPv6, vient naturellement la question de
l'intéropérabilité avec IPv4; d'autant plus que même les protocoles de niveau transport (UDP, TCP) et applicatif (DNS,
FTP …) se sont adaptés pour cette prise en compte de l'augmentation de l'espace d'adressage.
Par défaut les mondes sont ainsi totalement distincts, l'Internet IPv6 étant disjoint de l'Internet IPv4. Cette séparation
ayant été évaluée comme l'un des principaux freins au déploiement d'IPv6, l'IETF a originellement mis l'accent sur un
certain nombre de mécanismes de transition pour assurer des passerelles entre ces deux mondes. Néanmoins devant
le surnombre de propositions, le Working Group de l'IETF ngstrans chargé de la standardisation des mécanismes de
transition a finalement considéré qu'il fallait conserver uniquement quelques mécanismes et promouvoir plutôt une
migration progressive mais totale des sites en IPv6. Le risque évalué étant que les différents sites restent en IPv4 et
utilisent l'un ou l'autre des mécanismes de transition pour accéder aux backbones IPv6.
Dans ce paragraphe nous présenterons succinctement certains des mécanismes de transition les plus usités.
9.1 Double Pile IPv4/IPv6

Ce mécanisme est le plus usité actuellement. La majeure partie des systèmes d’exploitation propose maintenant une
pile IPv6 en plus de la pile IPv4. Ce mécanisme permet ainsi, selon les besoins, de se connecter à l’Internet IPv6 ou
l’Internet IPv4, à la condition bien entendu d’être connecté au monde IPv6. Auparavant seules les entreprises publiques
ou les universités avaient accès à ces réseaux. On constate que certains FAI proposent actuellement des accès IPv6.
Peu à peu on assiste ainsi à la création de bulles IPv6/IPv4 dans les universités et chez les particuliers. Le problème
restant étant de faire migrer également les entreprises pour l’instant réticentes, peut-être par manque de confiance, de
compétence, ou tout simplement ne souhaitant pas investir, considérant l’inutilité de faire évoluer leur système bancal
mais qui marche encore ...
Les topologies ainsi crées avec les doubles piles n’ont pas besoin d’être superposées, les plans d’adressage peuvent
être totalement disjoints, les équipements hardwares intégrant également de plus en plus ce mécanisme de double pile,
il suffirait dans un premier temps de définir un plan d’adressage et une topologie IPv6 cohabitant avec l’IPv4 et qui
évoluerait avec les changements hardware et software.
25
Avec l’augmentation de la taille des adresses, bien évidemment les interfaces de communication réseaux ont été
également adaptées. Des points d’accès par sockets aux services de la couche transport ont été spécialement définis
pour IPv6. Dans un contexte de double pile on pourrait donc imaginer qu’il faille un client/serveur spécifique IPv6 et de
même un client/serveur spécifique IPv4 (i.e. un serveur telnet utilisant les sockets IPv4 et un serveur utilisant les
sockets IPv6). Ce contexte de double-pile offre cependant une particularité intéressante avec la définition d’un type
d’adresse particulier : les adresses IPv4 Mappées. Ces adresses ont le format IPv6 mais incluent l’adresse IPv4.
Seules les sockets IPv6 sont ainsi nécessaires, selon l’adressage utilisé le paquet est redirigé ou non vers la pile IPv4.
Figure 28 : Communication des piles pour les sockets dans un contexte double pile
9.2 Passerelle Applicative (ALG : Application Level Gateway)

Le principe des ALGs est assez similaire pour l’ensemble des passerelles applicatives : un proxy équipé d’une double
pile permet la cohabitation entre les 2 mondes. Si l’on prend l’exemple d’HTTP (présenté en Figure 29), on peut
considérer une machine M sur un site entièrement équipé en IPv6 réalisant une requête en IPv6 pour une URL en IPv4.
Le proxy HTTP est lui connecté en IPv6 sur le site et en IPv4 sur l’Internet. Il réalise alors la requête en IPv4 pour l’URL
IPv4, récupère la page et la transmet en IPv6 à M. La symétrie est identique, dans le cas où le site est entièrement en
IPv4 et la requête pour une URL IPv6.
Ce type de mécanisme permet ainsi de faire cohabiter les 2 mondes et fonctionne dès lors que le protocole concerné
de niveau applicatif permet l’utilisation d’un proxy équipé d’une double pile ou nécessite la connexion distante sur un
serveur équipé d’une double pile. C’est par exemple le cas des relais DNS, des serveurs POP3, IMAP4, SMTP …
Figure 29 : Exemple d'ALG HTTP
9.3 Traduction d’entête : SIIT/NAT-PT

Les mécanismes de traduction d’entête permettent tout simplement comme leur nom l’indique la traduction d’un entête
IPv4 vers un entête IPv6 ou inversement (avec éventuellement les entêtes de niveau transport). Le mécanisme le plus
complet est SIIT/NAT-PT (Stateless IP, ICMP Translation Algorithm/Network Address Translation - Protocol
Translation). Même si en théorie SIIT peut fonctionner seul, son utilisation sans état et la clarté de sa spécification en
font un protocole difficilement utilisable seul. Conjointement avec NAT-PT (ou l’extension NAPT-PT : Network Address
Port Translation-Protocol Translation), ce protocole permet donc de faire cohabiter les 2 mondes. Il fonctionne à la
26
manière du NAT, garde des informations d’états, alloue des adresses IPv4 au besoin depuis un pool, fait
éventuellement de la translation de port et connaît les mêmes difficultés liées à cette allocation dynamique.
Si l’on prend pour exemple la Figure 30, une machine M dans un réseau IPv6 désireuse de contacter une machine N
dans un réseau IPv4, celle-ci transmet un paquet IPv6 vers un boîtier NAT-PT avec pour destination une adresse
spéciale IPv6 composée d’un préfixe NAT-PT suivi de l’adresse IPv4 transformée en hexadécimal. Ce boîtier a alors la
charge de traduire l’entête en IPv4, d’allouer une adresse IPv4 pour l’émetteur, de remplir une table d’association entre
adresse IPv4 allouée et adresse IPv6 de l’expéditeur, de récupérer l’adresse IPv4 du destinataire, pour finalement
transmettre ce nouveau paquet sur le réseau IPv4 vers la destination. La réponse potentielle suivra le chemin inverse.
La table d’association permettra de retrouver le destinataire effectif de cette réponse.
Figure 30 : Exemple de traduction SIIT/NAT-PT
On comprend donc qu’il est très difficile de maintenir des serveurs sur le réseau IPv6. Cette table d’association doit en
effet être statique pour les serveurs potentiels. De plus les informations liées aux adresses et contenues dans les
charges utiles devront être également modifiées par ce type de traducteur. D’autres protocoles doivent par conséquent
se greffer en plus pour le FTP, le DNS … Ce type de protocole a également du mal à conserver la sémantique des
paquets lors de la traduction, se marie très mal avec les mécanismes de sécurité IPsec, la mobilité de machines
(MIPv6), la mobilité de réseaux (NEMO), le multicast … Devant les nombreux problèmes rencontrés, l’IETF a donc
décidé de ne pas encourager la mise en œuvre de ce protocole et l’a déprécié.
9.4 Tunneling
Ce type de mécanisme repose principalement sur des besoins de communication de sites ou d’îlots isolés IPv6
(respectivement IPv4) sur une infrastructure IPv4 (respectivement IPv6). Le nombre de mécanismes imaginés dans ce
contexte foisonne, aucun n’étant réellement satisfaisant. 2 techniques différentes s’opposent ici :
• Les tunnels configurés manuellement ou par un fournisseur public (Tunnel Broker)

• Les tunnels automatiques : 6to4, Teredo, Isatap …
L’idée n’est pas ici de les présenter tous en détail, on pourra se reporter aux spécifications au besoin.
9.4.1 Tunnel brokers

Plusieurs fournisseurs proposent ainsi des interfaces WEB permettant après inscription la configuration d’un tunnel IPv6
sur IPv4 vers le site de l’intéressé. Il suffit donc de configurer manuellement ou par des scripts fournis l’autre partie du
tunnel jusqu’au routeur du fournisseur pour accéder à l’Internet IPv6. C’est finalement la méthode la plus appropriée
pour joindre l’Internet IPv6 pour un particulier dont le FAI ne propose pas d’IPv6.
9.4.2 6to4
Ce type de mécanisme est principalement usité pour permettre la communication entre îlots IPv6 sur une infrastructure
IPv4 tout en permettant un accès à l’Internet IPv6. Le principe est relativement simple : chaque îlot isolé, qualifié de
réseau 6to4 dispose en bordure d’une passerelle 6to4 équipée d’une double pile. Chaque îlot utilise un préfixe
particulier qualifié de préfixe 6to4 formé de la manière suivante : 2002:: Adresse IPv4 du Relais ::/48
Dans la Figure 31, une machine M désireuse de communiquer avec une machine N d’un autre réseau 6to4, transmettra
donc les paquets IPv6 à sa passerelle par routage. Le champ destination indiquera une adresse formée d’un préfixe
6to4 incluant l’adresse IPv4 de la passerelle de destination. Ce paquet sera ainsi automatiquement encapsulé dans un
27
paquet IPv4 avec comme adresse source l’adresse de la passerelle émettrice et comme adresse destination celle de
réception. La passerelle réceptrice désencapsulera ce paquet avant de le transmettre sur son îlot. Chaque passerelle
pointe également vers un relais par défaut connecté à l’Internet IPv6.
Figure 31 : Exemple du mécanisme 6to4
Ce mécanisme simple à mettre en œuvre a de nombreuses failles de sécurité : en particulier il est sensible au déni de
service et n’offre pas de contrôle sur le trafic reçu. Une passerelle 6to4 a en effet la possibilité de vérifier la cohérence
d’adressage entre l’entête IPv6 encapsulée et l’entête IPv4 dans le cas où l’émetteur est une passerelle 6to4 mais cette
vérification est presque impossible si la source est une adresse native. Dans ce cas-là le paquet sera transmis sur le
réseau IPv6 protégé par la passerelle, sans certitude qu’il ne s’agit pas d’un paquet forgé. Le risque est d’autant plus
important que l’adresse IPv4 de l’émetteur sera probablement perdue après le transfert.
9.4.3 Quelques autres protocoles …

Teredo (Tunneling IPv6 over UDP through NAT) est assez similaire à 6to4. Il définit une méthode permettant d'accéder
à l'Internet IPv6 derrière un équipement réalisant du NAT en encapsulant les paquets IPv6 dans de l'UDP sur IPv4
entre le client et le relais Teredo à l'aide d'un serveur Teredo.
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) permet la connectivité IPv6 au dessus d’une infrastructure
IPv4.Il supporte un réseau NBMA (Non Broadcast Multicast Access), génère des adresses Lien-local depuis les
adresses IPv4 et permet l’utilisation du protocole Neighbor Discovery au-dessus de cette infrastructure IPv4.
9.5 Conclusion
De nombreux mécanismes de transition ont été définis pour permettre :
• La cohabitation des 2 mondes,

• la communication entre les 2 mondes,
• la communication entre îlots isolés IPv6 (respectivement IPv4) dans une infrastructure IPv4 (respectivement
IPv6),
• la communication entre un îlot isolé IPv6 (respectivement IPv4) et l’Internet IPv6 (respectivement IPv4).
Aucun de ces mécanismes n’est pleinement satisfaisant, mais ils n’ont pas pour vocation d'exister durablement. Ils
devraient décroître dans le temps en fonction du nombre d'équipements IPv6 présents sur le réseau.
Afin d’anticiper le passage à IPv6, les applications réseaux futures devraient déjà prendre en compte ce nouveau mode
d’adressage et en particulier utiliser les sockets IPv6 qui dans tous les cas permettent la communication avec les 2
mondes. Les anciennes applications doivent également être adaptées dans cet esprit. Bien entendu, il sera difficile de
faire migrer celles dont on ne dispose plus des sources.
28
10. IPsec
IPsec est le protocole spécifiquement conçu pour sécuriser IPv6. Il permet de réaliser des réseaux privés Virtuels ou
VPNs (Virtual Private Networks) au niveau IP et offre les services :
• d’authentification des données,

• de chiffrement de données,
• d’intégrité des données pour garantir que les paquets n’ont pas été modifiés durant leur acheminement,
• d’anti-rejeu afin de détecter les éventuels paquets rejoués par un attaquant.
Toute implémentation IPv6 se doit de l’intégrer dans sa pile. Ce protocole est également utilisable avec IPv4 mais
l’utilisation du NAT/PAT (Network Address Translation/Protocole Address Translation) en limite la mise en œuvre.
10.1 Mécanismes IPsec

IPsec définit 2 protocoles de sécurisation :
• AH (Authentication Header)
• ESP (Encryption Security Payload)
Les services de sécurisation offerts par ces 2 protocoles sont distincts :
• AH permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Il sert aussi au contrôle
d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son
acheminement et peut optionnellement être utilisé pour la détection des rejeux.
• ESP offre les mêmes services qu’AH et permet en plus de chiffrer l'ensemble des paquets ou uniquement la
charge utile. ESP garantit également de façon limitée l'intégrité du flux.
10.1.1 Associations de sécurité

Afin de sécuriser les échanges, les entités en présence doivent bien évidemment partager un ensemble commun
d’informations telles que le protocole IPsec usité (AH ou ESP), les clés, les algorithmes … Ces différentes informations
constituent des associations de sécurité ou SA (Security Association).
Chaque association de sécurité est identifiée de manière unique par un triplet comprenant un indexe de paramètres de
sécurité SPI (Security Parameters Index), l'adresse du destinataire IP et le protocole de sécurité AH ou ESP.
Une association de sécurité est unidirectionnelle. Une communication bidirectionnelle entre 2 entités nécessite donc
l'utilisation de 2 associations de sécurité.
10.1.2 Mode Transport et Tunnel

Les normes IPsec définissent deux modes distincts d'opération IPsec : le mode Transport et le mode Tunnel. Le mode
Tunnel ne fonctionne que pour les datagrammes IP-in-IP. En mode Tunnel, le paquet IP interne détermine la stratégie
IPsec qui protège son contenu tandis qu’en mode Transport, l'en-tête extérieur détermine la stratégie IPsec qui protège
le paquet IP interne. Contrairement au mode Transport, le mode Tunnel ne permet pas à l'en-tête IP extérieur de dicter
la stratégie de son datagramme IP interne. Enfin dans les 2 modes, l’entête extérieur est partiellement protégé mais le
mode Tunnel à l’avantage de protéger intégralement son entête extérieur pouvant ainsi s'avérer fortement utile pour la
création de VPN.
10.2 AH (Authentication Header)

La mise en œuvre d’AH repose sur une extension d’entête spécifique. Celle-ci est définie dans la Figure 32.
29
Figure 32 : Extension d’entête AH.
Le rôle des différents champs de l’extension d’entête AH est précisé dans le Tableau 22.
Champs Taille Rôle

Payload Len 8 bits Spécifie la longueur -2 en mots de 32 bits de l’extension d’entête AH.
RESERVED 16 bits Positionné à 0.
SPI 32 bits Security Parameters Index utilisé par le récepteur pour trouver l’association de
sécurité à utiliser.
Sequence 32 bits Compteur incrémenté à chaque paquet. Permet en particulier de détecter le rejeu.
Number
ICV Variable Integrity Check Value. Destiné à la validation de l’intégrité du paquet. Doit être un
Selon multiple de 32 bits.
l’algorithme
usité
Padding Variable Utilisé pour des besoins d’alignement d’entête. Sa taille est telle que l’extension
d’entête AH est un multiple de 64 bits (32 bits pour IPv4).
Tableau 22. Rôle des différents champs de l’extension d’entête AH.
10.2.1 Protection AH et Algorithmes

AH suppose généralement une implémentation des algorithmes suivants :
• HMAC-MD5-96 (Peut être implémenté) : Cet algorithme produit une empreinte sur 128 bits tronquée à 96 bits
pour le champ ICV de AH.
• HMAC-SHA1-96 (Doit être implémenté) : Cet algorithme produit une empreinte sur 160 bits tronquée à 96 bits
pour le champ ICV de AH.
• AES-XCBC-MAC-96 (Devrait être implémenté) : Ce protocole utilise le chiffrement par bloc AES dans un mode
d'opération de type "compteur" couplé à code d'authentification MAC (CBC-MAC). Le compteur sert à assurer
un chiffrement sûr en évitant d'avoir un vecteur d'initialisation identique pour chaque message alors que le code
d'authentification permet de vérifier que le message n'a pas été altéré. Cet algorithme produit également une
empreinte sur 96 bits pour le champ ICV de AH.
D’autres algorithmes sont bien entendu utilisables, mais ceux précisés ci-dessus représentent l’ensemble commun
minimum des implémentations d’AH.
Lors de la réception d’un paquet AH, la pile IPsec détecte l’association de sécurité concernée, en déduit les algorithmes
et les clés associées, calcule la valeur du champ ICV et la compare avec la valeur fournie. Dans le cas où ces 2 valeurs
coïncident l’intégrité ainsi que l’authentification des champs concernés est assurée. Ces champs diffèrent selon le mode
usité transport ou tunnel.
Le rejeu des paquets est quant à lui détecté par le champ Sequence Number incrémenté à chaque paquet et également
protégé par le champ ICV.
10.2.2 Mode Transport

En mode Transport l’extension AH est insérée après l’entête IPv6 et avant les entêtes de niveau transport (TCP, UDP).
De plus, AH étant vue comme une extension d’entête traitée de bout en bout de la communication, celle-ci apparait
30
après les extensions d’entête Hop-By-Hop Option Header, Routing Header et Fragment Header. L’extension d’entête
Destination Options Header est quant-à elle placée indifféremment avant ou après.
L’authentification et l’intégrité portent donc sur :
• les octets situés au dessus de l’extension d’entête AH,

• certains champs de l’entête IPv6 invariants lors de l’acheminement du paquet,
• certains champs invariants des extensions d’entête positionnées avant AH.
Les extensions d’entête positionnées après AH ne sont pas modifiées durant l’acheminement des paquets; à ce titre
celles-ci sont protégées par le champ ICV. Cette protection diffère pour les extensions d’entêtes positionnés avant AH,
certains champs pouvant être altérés par les routeurs présents le long du chemin.
Les sous-options présentes dans les extensions headers Hop-By-Hop et Destination Options Header disposent d’un bit
positionné à 1 si l’option peut être modifiée le long du trajet. Dans le cas où ce bit n’est pas positionné la sous-option
est protégée, dans le cas contraire les octets de la sous-option sont positionnés à 0 lors du calcul de l’ICV.
Cette protection ne s’applique pas non plus sur l’extension Fragment Headers qui apparaît uniquement après la phase
d’authentification.
La Figure 33 montre ainsi le positionnement de l’extension d’entête AH en mode transport ainsi que la portée de
l’authentification/intégrité.
Figure 33 : AH en mode transport.
10.2.3 Mode Tunnel

En mode Tunnel l’extension AH est insérée avant l’entête IPv6. Un nouvel entête IPv6 est alors inséré en tête. La
Figure 34 et le Tableau 23 présentent le mode de construction de ce ne nouvel entête ainsi que le positionnement des
champs de l’entête Intérieur.
Champs de l’entête Entête Extérieur Entête Intérieur

IPv6
Version Positionné à la valeur 6. Aucune modification.
DS Copié depuis l’entête intérieur. Aucune modification.
ECN Copié depuis l’entête intérieur. Positionné à 0.
Flow Label Copié depuis l’entête intérieur ou Aucune modification.
configuré.
Payload Length Construit. Aucune modification.
Next Header Positionné à la valeur de AH (51) Aucune modification.
Hop Limit Construit. Décrémenté d’une unité

Source Address Construit. Aucune modification.
Destination Address Construit. Aucune modification.
Extensions Headers Jamais copié mais peut Aucune modification.
apparaître en postambule.
31
Tableau 23. Construction de l’entête IPv6 extérieure pour AH en mode tunnel.
Figure 34 : AH en mode tunnel.
10.3 ESP (Encryption Security Payload)

La mise en œuvre d’ESP repose sur une extension d’entête spécifique. Celle-ci se décompose en 2 parties. La
première partie précède les données à protéger, la deuxième termine le paquet et contient un éventuel ICV pour
protéger le paquet en authentification.
Ces 2 parties sont définies dans la Figure 35.
Figure 35 : Extension d’entête ESP.
Le rôle des différents champs de l’extension d’entête ESP est précisé dans le Tableau 24.
Champs Taille Rôle

SPI 32 bits Security Parameters Index utilisé par le récepteur pour trouver l’association de
sécurité à utiliser.
Sequence 32 bits Compteur incrémenté à chaque paquet. Permet en particulier de détecter le rejeu.
Number
IV Variable Vecteur d’initialisation éventuel pour les algorithmes de chiffrement.
Selon
l’algorithme
usité
TFC Padding Variable Traffic Flow Confidentiality. Utilisé pour une protection contre les attaques statistiques.
Padding Variable Utilisé pour des besoins d’alignement d’entête. Sa taille est telle que l’extension
d’entête ESP est un multiple de 64 bits (32 bits pour IPv4).
Pad Length 8 bits Indique la taille du champ Padding en octets.
32
ICV Variable Integrity Check Value. Destiné à la validation de l’intégrité du paquet. Doit être un
Selon multiple de 32 bits.
l’algorithme
usité
Tableau 24. Rôle des différents champs de l’extension d’entête ESP
10.3.1 Protection ESP et Algorithmes

La protection d’ESP repose sur le choix des algorithmes d’authentification et de chiffrements. Ceux-ci peuvent être
distincts ou combinés, c'est-à-dire qu‘authentification et chiffrement sont réalisés par le même algorithme.
Dans le cas d’une protection combinée, ESP suggère l’utilisation d’AES-CCM ou AES-GCM déjà utilisé pour
respectivement le 802.11i et le 802.1ae.
Dans le cas d’une protection séparée, ESP suppose généralement une implémentation des algorithmes
d’authentification suivants :
• NULL Authentication (Peut être implémenté) ;

• HMAC-MD5-96 (Peut être implémenté) : Cet algorithme produit une empreinte sur 128 bits tronquée à 96 bits
pour le champ ICV de AH ;
• HMAC-SHA1-96 (Doit être implémenté) : Cet algorithme produit une empreinte sur 160 bits tronquée à 96 bits
pour le champ ICV de AH ;
• AES-XCBC-MAC-96 (Devrait être implémenté) : Ce protocole utilise le chiffrement par bloc AES dans un mode
d'opération de type "compteur" couplé à code d'authentification MAC (CBC-MAC). Le compteur sert à assurer
un chiffrement sûr en évitant d'avoir un vecteur d'initialisation identique pour chaque message alors que le code
d'authentification permet de vérifier que le message n'a pas été altéré. Cet algorithme produit également une
empreinte sur 96 bits pour le champ ICV de AH.
Les algorithmes de chiffrements définis sont alors les suivants :
• NULL Encryption (Doit être implémenté) ;

• AES-CBC (Doit être implémenté) : AES supporte 3 tailles de clé : 128, 192 et 256 bits. La taille de clé par
défaut est de 128 bits. AES-CBC nécessite un IV de 16 octets ;
• 3DES-CBC (Doit être implémenté) : Cet algorithme utilise une clé effective de 192 bits. Il est réalisé par
application de 3 DES-CBC, chacun utilisant une clé de 64 bits (dont 8 bits de parité). 3DES-CBC nécessite un
IV de 8 octets ;
• AES-CTR (Devrait être implémenté) : AES en mode compteur supporte 3 tailles de clé : 128, 192 et 256 bits.
La taille de clé par défaut est de 128 bits. AES-CTR nécessite un IV de 16 octets ;
• DES-CBC (Ne devrait pas être implémenté).
D’autres algorithmes sont bien entendu utilisables, mais ceux précisés ci-dessus représentent l’ensemble commun
minimum des implémentations d’ESP. Il est à noter qu’une association de sécurité ESP ne doit à aucun moment utiliser
conjointement un algorithme d’authentification et de chiffrement nul.
En mode tunnel, ESP depuis sa dernière version, propose un mode de confidentialité de flux par l’utilisation du champ
TFC. Ce champ permet d’adjoindre des octets de bourrage de taille aléatoire. La taille ce champ n’étant précisée par
aucun autre champ, celle-ci peut être déduite du champ Payload Length de l’entête IP intérieure au tunnel. Ce champ
TFC pourrait également être utilisé en mode transport à la condition bien entendu que le protocole de niveau transport
comporte une indication sur la taille de sa charge utile (cas de TCP, UDP, ICMP).
Lors de la réception d’un paquet ESP, la pile IPsec détecte l’association de sécurité concernée et en déduit les
algorithmes et les clés associées.
Si la protection en authentification est activée, le récepteur calcule l’ICV sur le paquet ESP sans ce champ ICV. Si le
champ calculé coïncide avec le champ transmis, l’intégrité est assurée sur les champs concernés. Ces champs diffèrent
selon le mode usité, transport ou tunnel. Vient ensuite le déchiffrement du paquet avec l’algorithme et la clé fournie par
l’association de sécurité.
Le rejeu des paquets est quant à lui détecté à la manière d’AH par le champ Sequence Number incrémenté à chaque
paquet et également protégé par le champ ICV.
33
10.3.2 Mode Transport
En mode Transport l’extension ESP est insérée de la même manière que l’extension AH, après l’entête IPv6 et avant
les entêtes de niveau transport (TCP, UDP). ESP étant également vue comme une extension d’entête traitée de bout
en bout de la communication, celle-ci apparaît après les extensions d’entête Hop-By-Hop Option Header, Routing
Header et Fragment Header. L’extension d’entête Destination Options Header est quant à elle placée indifféremment
avant ou après.
Le chiffrement porte donc sur les octets situés au dessus de l’extension d’entête ESP à l’exception des champs SPI,
Sequence Number, ICV.
L’authentification éventuelle réalisée par le champ ICV porte sur l’ensemble des octets situés au dessus de l’extension
d’entête ESP.
La Figure 36 montre ainsi le positionnement de l’extension d’entête ESP en mode transport ainsi que la portée de
l’authentification/intégrité et du chiffrement.
Figure 36 : ESP en mode transport.
10.3.3 Mode Tunnel

En mode Tunnel l’extension ESP est insérée avant l’entête IPv6. Un nouvel entête IPv6 est alors inséré en tête. La
Figure 37 et le Tableau 25 présentent le mode de construction de ce ne nouvel entête ainsi que le positionnement des
champs de l’entête Intérieur.
Champs de l’entête Entête Extérieur Entête Intérieur

IPv6
Version Positionné à la valeur 6. Aucune modification.
DS Copié depuis l’entête intérieur. Aucune modification.
ECN Copié depuis l’entête intérieur. Positionné à 0.
Flow Label Copié depuis l’entête intérieur ou Aucune modification.
configuré.
Payload Length Construit. Aucune modification.
Next Header Positionné à la valeur de ESP Aucune modification.
(50)
Hop Limit Construit. Décrémenté d’une unité
Source Address Construit. Aucune modification.
Destination Address Construit. Aucune modification.
Extensions Headers Jamais copié mais peut Aucune modification.
apparaître en postambule.
Tableau 25. Construction de l’entête IPv6 extérieure pour ESP en mode tunnel.
34
Figure 37 : ESP en mode tunnel.
Dans le cas d’une utilisation en mode tunnel la totalité du paquet initial est donc chiffrée.
10.3.4 Topologies de mises en œuvre

IPsec a un intérêt majeur principalement par son mode ESP dans le cas où l’on souhaite :
• chiffrer et/ou authentifier du trafic de bout en bout ou jusqu’à une passerelle. Dans ce cas les entités en
présence doivent préférentiellement disposer d’un adressage public, le NAT étant assez difficilement
compatible avec IPsec. Une telle topologie a un intérêt majeur pour assurer la confidentialité entre 2 entités ou
pour un utilisateur nomade par exemple.
• créer un VPN entre sites distants. Ce besoin intervient dans le cas où l’on veut par exemple interconnecter des
réseaux privés distants au travers d'un réseau public
Ces 2 modes opérationnels sont résumés dans la Figure 38. On précise que dans cette figure la protection est
symétrique, ce qui n’est pas forcément le cas, les associations de sécurité étant unidirectionnelles.
Figure 38 : Topologies ESP.
10.4 IKE (Internet Key Exchange)

Il a été précédemment indiqué qu’AH et ESP nécessitaient des clés de chiffrements par le biais des associations de
sécurité. Cette gestion des clés peut donc être manuelle; mais dans un environnement conséquent, une telle gestion
devient irréalisable. De plus, cette méthode implique une définition totalement statique des associations de sécurité et
un non-renouvellement des clés.
Le protocole IKE a donc été développé pour une gestion automatique des associations de sécurité, en particuliers des
clés ainsi que des algorithmes à usiter.
35
IKE fait appel aux éléments suivants :
• un protocole de gestion des associations de sécurité, ISAKMP (Internet Security Association and Key
Management Protocol), définissant des formats de paquets pour créer, modifier et détruire des associations de
sécurité. Ce protocole sert également de support pour l'échange de clés préconisé par les protocoles de
gestion de clés. Il assure aussi l'authentification des partenaires d'une communication ;
• un protocole d'échange de clés de session basé sur SKEME et Oakley qui repose sur la génération de secrets
partagés Diffie-Hellman;
• un domaine d'interprétation ou DOI (Domain of Interpretation) qui définit tous les paramètres propres à
l'environnement IPsec, à savoir les protocoles d'échanges de clés, les paramètres d'associations de sécurité à
négocier … ;
• les clés utiles lors de l'authentification mutuelle des équipements IPsec qui intervient en préalable à toute
négociation d'association de sécurité. Ces clés peuvent être des clés partagées (pre-shared key)
préconfigurées par l'administrateur, ou bien des clés privées/publiques personnelles à chaque équipement
IPsec et préchargées dans les équipements, ou bien encore un certificat électronique géré par une
infrastructure à clés publiques (PKI : Public Key Infrastructure).
A l’heure actuelle 2 versions cohabitent, IKEv1 très complexe et IKEv2 qui en est une version simplifiée pour sa mise
en œuvre ainsi que par son mécanisme.
11. Mobilité de Machines : MIPv6

En termes de mobilité on distingue 2 mécanismes principaux : la micro-mobilité et la macro-mobilité. La micro-mobilité
est celle utilisée entre autre par le wifi. Les entités en cours de déplacement se réassocient à des stations de base et
conservent leur possibilité de connectivité au sein d’un domaine. Cette gestion des handovers est relativement fine et
limite la signalisation au sein du réseau. Ces mécanismes sont cependant peu efficaces au sein de plusieurs domaines.
En effet les adresses IP sont dans ce dernier cas renégociées pour mapper au domaine et pouvoir ainsi être routable.
La macro-mobilité résout ce problème en conservant une connectivité IP même lors d’un changement de domaine. Les
adresses IP originelles continuent d’être utilisées lors des communications. De même les sessions TCP peuvent ainsi
rester fonctionnelles lors d’un déplacement entre domaines. IPv6 intègre ce concept dans le protocole MIPv6 (Mobile
IPv6).
11.1 Concepts
Avant de poursuivre il s’agit de définir les mots clés principaux usités par MIPv6.
• Réseau Mère : Réseau auquel la machine appartient initialement ;

• Nœud correspondant : machine dialoguant avec le mobile ;
• Home Address : Adresse IPv6 dans le réseau mère ;
• Care-of Address : Adresse IPv6 dans le réseau visité ;
• Agent Mère : Machine du réseau mère servant « d’interface » entre le mobile et le nœud correspondant.
MIPv6 utilise intensivement la notion de tunnels. Schématiquement, les paquets transmis par le mobile dans un réseau
étranger passent par l’Agent Mère présent dans le réseau mère, avant d’être retransmis au Nœud correspondant. Le
chemin de retour est identique. Le routage sous-jacent apporte le paquet jusqu’à l’Agent Mère qui le retransmet au
mobile dans son réseau visité.
L’agent mère doit également à tout moment être capable de localiser ses mobiles en déplacement. Il utilise pour cela un
cache baptisé Binding Cache associant Home Address et Care-of Address de ses différents mobiles. Un mécanisme
de signalisation protégé par IPsec en mode ESP est par conséquent usité pour mettre à jour ce cache. Il ne sera pas
fait état des paquets MIPv6 ici, il s’agit simplement de savoir que cette mise à jour s’effectue à l’aide de paquets
particuliers nommés Binding Update. Ceux-ci sont généralement acquittés par l’Agent Mère par des Binding
Acknowledgment.
L’ensemble des mécanismes basiques de MIPv6 se situe au niveau de la couche IP dans le modèle TCP/IP. Ils ont été
modelés pour permettre une communication avec des entités n’ayant pas conscience des protocoles de mobilité. Ils
n'ont aucun impact sur les couches de niveau transport et applicative. Pour le correspondant cette communication est
totalement transparente.
36
11.2 Mobilité de Machines : MIP6
Le mobile situé dans son réseau mère utilise sa Home Address pour dialoguer avec des Nœuds correspondants de
manière classique. Lorsqu’il se déplace dans un réseau visité la procédure est la suivante :
1. Le mobile obtient une nouvelle adresse IP par combinaison de son adresse MAC et du nouveau préfixe réseau,
la Care-of Address. Il dispose toujours de sa Home Address .
2. Le mobile transmet un Binding Update à l’agent mère afin de mettre à jour son cache d’association. Ce paquet
étant protégé par IPsec en mode ESP, l’authentification, l’anti-rejeu, la confidentialité et l’intégrité sont assurés.
3. L’agent mère aura alors à charge de capturer les paquets auparativement transmis au mobile. II utilise dans
cette optique les possibilités offertes par le protocole de découverte des voisins (Neighbor Discovery) en
annonçant son adresse MAC comme destinataire de l’ensemble des paquets unicast à destination du mobile.
Les caches NDP des machines présentent sur le lien mère seront ainsi remis à jour.
4. Lorsque le mobile souhaite dialoguer avec un nœud correspondant il peut choir d’utiliser son nouvel adressage,
ou de masquer sa mobilité par l’utilisation de sa Home Address. Dans ce dernier cas il construit un tunnel ESP
avec son Agent Mère et encapsule les paquets à destination de son correspondant. L’adresse source de la
partie interne est ainsi la Home Address, l’adresse destination est celle du correspondant.
5. Le paquet parvient à l’Agent Mère, qui vérifie son authentification, le déchiffre, le désencapsule et le retransmet
sur le réseau.
6. Le correspondant pourra y répondre de manière symétrique. Cette réponse sera capturée par l’Agent Mère,
chiffrée et authentifiée avant d’être retransmise au mobile dans le tunnel ESP. En cas d’un déplacement en
cours de communication le binding cache aura été mis à jour permettant à l’Agent mère de retrouver son
mobile.
La Figure 39 positionne ces différentes entités dans un contexte MIPv6.
Figure 39 : Communication MIPv6 Basique sans optimisation.
11.3 Optimisations de routes

Les échanges entre mobiles et correspondants n’étant pas toujours les plus optimums en matière de routage, MIPv6
intègre un mode d’optimisation pour les correspondants intégrant des fonctions spécifiques. Il s’agit de supprimer
simplement la passerelle occasionnée par l’Agent Mère.
Pour cela MIPv6 définit 2 nouvelles options :
• Routing Header de type 2 : qui est simplement une extension d’entête Routing Header contenant la Home
Address du mobile
37
• Home Address Option : qui est une sous-option de l’extension d’entête Destination Option Header traité
uniquement par le récepteur du paquet.
Lorsqu'un correspondant supporte l'optimisation de routage, il maintient tout comme l'Agent Mère une table des
associations pour tous les mobiles avec lesquels il est en communication. Une vérification axée autour d’ICMPv6 est
préalable avant toute optimisation.
Le principe est alors assez proche de celui usité avec l’Agent Mère :
1. Le mobile en déplacement transmet un Binding Update au correspondant pour lui faire état de sa nouvelle
localisation après en avoir fait de même à son Agent Mère. Ce correspondant mettra alors à jour son Binding
Cache.
2. Lorsque le mobile veut transmettre un message au correspondant, il utilise en adresse source sa Care-of
Address mais ajoute l’option Home Address Option.
3. Le paquet subira le routage classique entre le mobile et le correspondant, remontera dans la pile MIPv6 de ce
correspondant qui échangera Care-of Address du champ adresse source et Home Address présentes dans
l’option Home Address Option. Pour la pile IPv6, le paquet sera transparent comme provenant directement du
mobile depuis son réseau Mère. Dans le cas où ce paquet est protégé par IPsec, les vérifications seront donc
basées sur l’adresse mère.
4. Avant de répondre, le correspondant cherchera dans sa table d’association la Care-Of Address du mobile. Il
transmettra alors le paquet en utilisant cette Care-Of Address en destination et y ajoutera l’option Routing
Header de type 2 remplie avec la Home Address.
5. Le paquet parviendra donc au mobile qui échangera préalablement l’adresse de destination avec la Home
Address. Le paquet remontera donc également dans les couches de manière totalement transparente.
Ce mécanisme donne donc des trajectoires optimums en matière de routage et permet de limiter les contraintes en
matière d’ingress et d’outgress filtering. Ce mécanisme de mise à jour d'association pose cependant d'importants
problèmes en matière de sécurité. En effet, il est aisé de protégé les échanges de signalisation entre le mobile et l'agent
mère du fait de la relation administrative qui permet par exemple l'utilisation d'un secret partagé mais ceci est
beaucoup plus compliqué en ce qui concerne les correspondants ; Sans protection, il serait possible de détourner les
communications d'un mobile en redirigeant le trafic pour l'espionner ou de mener une attaque par déni de service. Une
procédure spécifique baptisée Return Routability procédure doit donc être mise en œuvre avant toute décision
d’optimisation.
11.4 Return Routability procédure

Cette procédure est destinée à la protection partielle des associations de sécurité entre mobile et correspondant dans le
cas de l’optimisation de route. Elle repose sur une utilisation de 4 messages principaux :
• HoTI : Home Test Init;

• CoTI : Care-of Test Init;
• HoT : Home Test ;
• CoT : Care-of Test.
Les correspondants intégrant l’optimisation de route doivent préalablement disposer de nonces ainsi que d’une clé
secrète notée Kcn.
La procédure usitée est la suivante :
1. Un message HoTI est émis depuis la Home Address du mobile vers le correspondant via l'agent mère. Il
contient une valeur aléatoire sur 64 bits, le Home Init cookie ;
2. parallèlement un message CoTI est émis depuis la care-of address du mobile, directement vers le nœud
correspondant. Celui-ci contient une seconde valeur aléatoire sur 64 bits, le Care-of Init cookie ;
3. en réponse au message HoTI, un message HoT, est émis par le correspondant à destination de la Home
Address du mobile via l'Agent Mère. Ce paquet contient entre autre l’index d’un nonce choisi par le
correspondant ainsi qu’un Home Keygen token calculé par :
premier (64, HMAC_SHA1 (Kcn, (home address | nonce | 0 )))
4. De même, en réponse au message CoTI, un message CoT est émis par le correspondant vers la Care-of
Address du mobile. Ce paquet contient entre autre l’index d’un autre nonce choisi par le correspondant ainsi
qu’un Home Keygen token calculé par :
premier (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 0 )))
38
A l’issue de ces différentes étapes, le mobile calcule une clé notée Kbm :
Kbm = SHA1 ( "home keygen token" | "care-of keygen token")
La Figure 40 présente le cheminement de ces différents messages au travers de l’Internet.
Figure 40 : Return Routability Procédure.
Cette clé sera utilisée lors de la mise à jour des associations pour authentifier le mobile par le calcul d’un HMAC.
Cette procédure repose sur l’hypothèse forte qu’aucun espion n’écoute à la fois les messages CoT et HoT qui
normalement empruntent des chemins distincts. Dans le cas contraire il lui serait aisé de calculer Kbm et de générer
des faux messages d’association. Cette écoute n’est pas faisable dans le réseau visité puisque les échanges entre
Agent Mère et mobile sont chiffrés. Pratiquement cette attaque est aisée dans le réseau du correspondant mais celle-ci
n’est pas évaluée comme étant plus risquée que celles que l’on peut retrouver dans un contexte sans mobilité par
simple IP-spoofing, NDP spoofing …
Afin de réduire les risques, les nonces ainsi que la clé Kcn sont régulièrement mis à jour.
12. Mobilité de Réseaux : NEMO

MIPv6 gère la mobilité d'un hôte tandis que NEMO assure la mobilité d'un réseau IPv6 entier, appelé réseau mobile.
Dans le cas de NEMO, la complexité est centralisée sur un équipement dédié : le routeur mobile. Ainsi, chaque
mouvement (lorsque le réseau mobile se déplace d'un réseau d'accès vers un autre) est transparent pour l'ensemble
des hôtes IPv6 du réseau mobile. Un hôte IPv6 standard peut ainsi bénéficier d'une connectivité permanente au sein
d'un réseau mobile sans avoir toutefois besoin de protocoles additionnels.
NEMO, couplé avec certaines extensions, gère notamment la mobilité des réseaux IPv6, la continuité des flux, les
équipements multi-interfaces. Dans sa version actuellement standardisée NEMO ne gère cependant pas les
optimisations de route comme peut le gérer MIPv6.
13. Pratique & Mise En œuvre

La majeure partie des Systèmes d’exploitation, des softwares des équipements réseaux actuels disposent d’un support
IPv6. Vous pourrez le vérifier sur le site de l’IPv6 Ready Logo Committee, programme mondial de certification IPv6.
Vous obtiendrez sur ce site le détail des implémentations actuellement certifiées et vous pourrez aisément y constater
l’important retard de l’Europe.
Les infrastructures réseaux européennes ont également accumulées un retard considérable dans cette migration … Et
pourtant les réseaux de l’enseignement et de la recherche proposent depuis déjà plusieurs années un support Natif
39
d’IPv6 voir du multicast IPv6. Heureusement quelques ISP (Internet Service Provider), tels que Free, offrent depuis
quelques mois un adressage IPv6.
Ce paragraphe a pour objectif de vous faire appréhender la mise en œuvre basique d’IPv6 sur les principaux systèmes
usités, à savoir Windows et Linux. On suppose que vous disposez d’ores et déjà d’un adressage IPv6 parce que vous
êtes par exemple dans une des situations précédemment évoquées. On rappelle que les Internet IPv4 et IPv6 sont bien
distincts même si une utilisation des machines en double pile permet la superposition de certaines portions. Dans le cas
contraire, si vous désirez plus qu’un réseau local, il vous faudra utiliser un des mécanismes de transition décrit dans
l’article précédent. Nous vous conseillons préférentiellement un tunnel broker et en second choix un tunnel 6to4.
13.1 Avec Windows

La majeure partie des versions courantes de Windows disposent d’un support IPv6 : Vista, XP SP1, XP SP2, Server
2003, 2008. Sous Vista et Server 2008 ce support est activé par défaut. Sous XP ou Server 2003, il vous faudra
l’activer au préalable.
Selon les versions de Windows les mécanismes disponibles sont plus ou moins complets.
• La mobilité IPv6 ne prend en compte que la partie correspondant ; ni Home Agent ni Nœud Mobile ne sont
disponibles ;
• Sous Windows XP et Server 2003, IPsec pour IPv6 offre les mécanismes AH et ESP mais le chiffrement ainsi
que la gestion automatique des clés n’est pas disponible. Seul Vista et Server 2008 offrent ces fonctionnalités.
• Vista et Server 2008 permettent une utilisation de DHCPv6.
13.1.1 Activation de la pile IPv6 & Configuration des Adresses

Ce besoin ne se retrouve que sous XP et Windows Server 2003 dont la pile IPv6 est par défaut désactivée.
Cette activation se fait par le biais de l’outil ipv6.exe sous Windows XP où de la commande netsh disponible sur toutes
les versions.
Sous Windows XP, il s’agit d’exécuter : ipv6 install

Bien entendu les interfaces concernées doivent accepter la connectivité TCP/IPv6 dans le menu « Propriétés »
adéquat.
Une adresse Lien-locale associée à chacune de vos carte réseau sera alors automatiquement configurée par
concaténation du préfixe fe80 et de votre identifiant d’interface défini depuis l’adresse MAC associée. Les interfaces
reliées à un réseau IPv6 constitué d’un routeur annonçant des Router Advertisement, obtiendront de même
automatiquement une adresse globale unicast, unique, routable et contenant l’adresse MAC de l’interface concernée.
La commande ipconfig /all (ou netsh show) vous prouvera votre connectivité. La Figure 41 vous montre une
telle configuration sous Windows XP.
Figure 41 : commande netsh show sous Windows XP.
40
Vous constaterez également une adresse supplémentaire, qualifiée de Temporaire. Il s’agit en fait d’une adresse
globale, de durée de vie relativement courte destinée au masquage de l’adresse MAC (disponible depuis le SP2). Au
besoin vous pourrez la désactiver par : ipv6 –p gpu useTemporaryAddresse no
13.1.2 Commandes principales
13.1.2.1 Connectivité, chemin

Lorsque vous disposerez d’une adresse routable ou simplement pour tester la connectivité entre deux machines, vous
pourrez utilisez la commande ping6 qui est le pendant de ping pour IPv4. Cette commande génère un ensemble de
paquets ICMPv6 Echo Request et affiche les réponses associées ICMPv6 Echo Reply.
La Figure 42 montre un tel ping6 sur www.google.fr désormais adressable en IPv6. Les paquets résultants de cette
commande sont également indiqués par capture du trafic avec Wireshark.
Figure 42 : Ping6 www.google.fr
En IPv4, pour connaître le trajet suivi par les paquets, on utilise généralement la commande tracert. En IPv6, il s’agit
désormais de tracert6
13.1.2.2 Cache des voisins (NDP Cache)

La résolution MAC/Adresse en IPv4 donne naissance au cache ARP obtenu par arp –an par exemple. En IPv6, il
s’agit désormais du cache NDP qui peut être obtenu par :
• ipv6 nc,
• ou netsh interface ipv6 show neighbors
13.1.2.3 Diverses Commandes

L’ensemble des configurations essentielles IPv6 sous Windows s’effectuent à l’aide de Netsh (et/ou ipv6.exe sous
Windows XP). Hormis celles précédemment définies, les commandes essentielles sont indiquées dans le Tableau 26.
Commande Netsh Rôle

netsh interface ipv6 show interface Affiche les interfaces IPv6
netsh interface ipv6 set interface Permet d’activer le forwarding des interfaces, les
41
[[interface=]String] annonces de Router Advertisement
[[forwarding=]{enabled | disabled}]
[[advertise=]{enabled | disabled}]
[[mtu=]Integer] [[siteid=]Integer]
[[metric=]Integer] [[store=]{active |
persistent}]
netsh interface ipv6 add address Permet d’ajouter des adresses IPv6 aux interfaces
[[interface=]String]
[address=]IPv6Address
[[type=]{unicast | anycast}]
[[validlifetime=]{Integer | infinite}]
[[preferredlifetime=]{Integer |
infinite}] [[store=]{active | persistent}]
netsh interface ipv6 show Affiche le Binding cache utilisé par MIPv6
bindingcacheentries
netsh interface ipv6 show routes Affiche les routes IPv6
[[level=]{normal | verbose}]
[[store=]{active | persistent}]
netsh interface ipv6 add route Ajoute une route IPv6 dans la table de routage
[prefix=]IPv6Address/Integer
[[nexthop=]IPv6Address]
[[siteprefixlength=]Integer]
[[metric=]Integer] [[publish=]{no | yes
| immortal}] [[validlifetime=]{Integer |
infinite}] [[preferredlifetime=]{Integer
| infinite}] [[store=]{active |
persistent}]
netsh interface ipv6 renew Permet la réinitialisation des adresses IPv6
Tableau 26. Les commandes essentielles IPv6 sous Windows.
13.1.3 Accès Web en IPv6

Classiquement en IPv4, les URLs (Uniform Resource Locator) utilisées dans les accès HTTP (HypertexT Transfert
Protocol) utilisent le nommage DNS (Domain Name System). Avant toute requête l’adresse du serveur HTTP est donc
généralement préalablement traduite par le biais des serveurs DNS. Avec IPv6, il en est de même, le browser dans un
premier temps recherche l’ensemble des adresses IP associées au serveur HTTP. Si celui-ci dispose d’une adresse
IPv6, il tentera dans un premier temps de le joindre par IPv6. En cas d’échec, c’est le protocole IPv4 qui sera utilisé.
Nous rappelons qu’il n’est pas indispensable que le serveur DNS soit adressé en IPv4 pour retourner des adresses
IPv6.
A l’heure actuelle la majeure partie des navigateurs supporte IPv6 par défaut, Firefox, Internet Explorer … A titre
d’exemple vous pourrez vous connecter sur www.kame.net. Si vous disposez d’un accès extérieur IPv6 ainsi que d’un
browser compatible vous devriez voire en première page une tortue animée. Le cas échéant celle-ci sera fixe.
Avec IPv6, les adresses étant 4 fois plus longues, les URLs contenant des IPs devraient encore moins se pratiquer.
Cependant ceci reste possible et pour différencier les :: de l’adresse avec la section port de l’URL, il faut entourer l’IP de
[ ]. (exemple : http://[2001:4860:a003::68] pour accéder à google en IPv6).
13.2 Avec Linux

Quelle que soit la distribution contemporaine utilisée, celle-ci contient IPv6. Vous pourrez néanmoins tester la présence
de son support dans le noyau par vérification de la présence du chemin : /proc/net/if_inet6. Le module IPv6 doit
également être chargé avant toute utilisation. Un appel à lsmod vous le confirmera.
13.2.1 Activation de la pile IPv6 & Configuration des Adresses

Sous Linux l’ensemble des configurations IPv6 peut être réalisé à l’aide des anciennes commandes ifconfig, netstat …
Depuis les noyaux au moins supérieur au 2.4, le sous-système réseau a été complètement réécrit. L’iproute2 étend
ainsi grandement les possibilités et centralise les configurations réseaux. La commande principale est ip.
Le Tableau 27 présente donc quelques une des options principales pour configurer IPv6 :
42
Commande ip Rôle
ip -6 address show [dev <périphérique>] Affiche les adresses IPv6
ip -6 addr add <adresseipv6>/<longueurdupréfixe> dev <interface> Ajoute une adresse IPv6
ip -6 route show [dev <périphérique>] Affiche les routes IPv6
ip -6 route add <réseauipv6>/<longueurdupréfixe> via Ajoute une route IPv6
<adresseipv6> [dev <périphérique>]
ip -6 neigh show [dev <périphérique>] Affiche les voisins NDP
ip -6 neigh add <adresseIPv6> lladdr <adressedelacouche-lien> Ajoute un voisin NDP
dev <périphérique>
Tableau 27. Commandes principales pour la configuration d’IPv6 sous linux.
Le système Linux étant l'un des mieux documentés, si l’une des options vous manque vous pouvez toujours utiliser la
commande man (exemple : man 8 ip).
13.2.2 Mise en œuvre mode routeur

Afin de mettre en place un routeur et/ou une passerelle vous devez activer le forwarding entre les différentes interfaces
réseaux. Ceci peut être réalisé par le biais de fichiers de configuration spécifiques à chaque distribution (généralement
sous l’arborescence /etc/sysconfig/network) ou directement par dialogue avec le Kernel. Ce dialogue est temporaire et
à chaque reboot, il sera réinitialisé (sauf utilisation de script de démarrage, généralement /etc/rc.local). Il se réalise par
des appels à la commande sysctl ou par écriture dans les fichiers propres au kernel.
Il s’agit sous IPv6 de l’arborescence /proc/sys/net/ipv6. Le fait d’écrire « 1 » dans le fichier

/proc/sys/net/ipv6/conf/all/forwarding activera le forwarding entre toutes les interfaces. Au besoin, le contrôle du
forwarding par interface doit être réalisé en utilisant les jeux de règles de netfilter-IPv6 (à l’aide d’ip6tables) en spécifiant
les périphériques d'entrée et de sortie
Il vous faudra certainement en plus activer les Router Advertisements afin de permettre aux machines présentes sur le
lien de s’autoconfigurer. Ces paquets sont générés suite au démarrage du démon radvd. Ce démon utilise un fichier de
configuration présent généralement dans /etc/radvd.conf. Ce fichier stipule les principaux paramètres des Router
Advertisements, à savoir :
• Le préfixe ;
• La durée de vie du préfixe ;
• La fréquence des envois d'annonce ;
• …
En dernier point il vous faudra peut-être activer un protocole de routage intra-domaine (Ripng, OSPfv3) voir inter-
domaine (Is-Is, BGP-4+).
13.2.3 Commandes et outils principaux

Les commandes principales disponibles sous Linux sont équivalentes à celle précédemment évoquées pour Windows.
Les principales sont les suivantes :
• ping6 (Packet INternet Grouper) : pour diagnostiquer la connectivité réseau. (Exemple : ping6 [-I
<périphérique>] FF02::1 vous donnera l’ensemble des interfaces présentes sur le lien-local ;
• traceroute6 : pour détecter le chemin emprunté par les paquets ;
• tracepath6 : similaire au traceroute6, trace le chemin vers une destination donnée tout en découvrant la MTU le
long de ce chemin ;
• nslookup, host : utiles pour la résolution DNS en v4 ou v6.
L’ensemble des outils classiques réseaux disponibles sur Linux a été adapté à IPv6 : ssh, telnet, ftp, netcat, nmap …
Le firewall iptable classique dispose également d’une variante baptisée ip6table pour IPv6.
13.2.4 Mise en œuvre d’IPsec

La pile IPsec est maintenant intégrée en natif sur les noyaux 2.5.47 et supérieurs ; les versions inférieures nécessitaient
l’installation de piles spécifiques style FreeS/WAN ou celle du projet japonais USAGI. L’implémentation actuelle repose
d’ailleurs sur celle du projet USAGI. Elle peut cependant ne pas être activée par défaut pour IPv6 ; il vous faudra donc
43
potentiellement relancer préalablement une compilation du noyau et y activer AH, ESP voir IPComp (Compression de
charge IP).
La configuration des politiques IPsec ainsi que des clés et algorithmes en mode partagé s’effectue à l’aide de l’outil
setkey, dérivant du projet KAME et fournie avec le package ipsec-tools. Si vous choisissez un mode de configuration
automatique des associations de sécurité, il vous faudra user d’un outil supplémentaire, racoon ou racoon2 selon la
version d’IKE choisie.
Par simplification nous choisirons un mode manuel de gestion des associations de sécurité. Supposons donc que l’on
souhaite protéger en mode transport le trafic depuis une machine d’adresse 3ffe::1 vers les machines :
• 3ffe::2 : par ESP (Chiffrement : aes-cbc, clé : aescbcencryption ; Authentification : hmac-sha1, clé :
hmacsha1authenticati ; SPI : 10);
• 3ffe::3 : par ESP (Chiffrement : 3des-cbc, clé : 3descbcencryptiontesting ; Authentification : hmac-sha1, clé :
hmacsha1authenticati ; SPI : 11)
Chacune de ces différentes machines devra donc être configurée pour prendre en compte ce paramétrage IPsec. Ceci
peut se réaliser par définition d’un fichier de configuration nommé par exemple setkey.conf utilisant le format suivant :
flush ;
spdflush;
#Configuration SPD
#Configuration SAD
spddump;
dump esp ;
Si l’on considère 3ffe::1, Il faut donc dans un premier temps définir les SPD (Security Policy Database) afin que tout
trafic sortant en direction de 3ffe::2 et 3ffe::3 soit protégé par IPsec :
spdadd -6 3ffe::1 3ffe::2 any -P out ipsec esp/transport//require;

spdadd -6 3ffe::1 3ffe::3 any -P out ipsec esp/transport//require;
Dans un second temps il faut indiquer les SPI, les clés ainsi que les algorithmes à utiliser au niveau de la SAD :
add 3ffe::1 3ffe::2 esp 10

-E aes-cbc "aescbcencryption"
-A hmac-sha1 "hmacsha1authenticati";
-E 3des-cbc "3descbcencryptiontesting"
Bien entendu, 3ffe::2 et 3ffe::3 doivent comporter les SPDs et SADs correspondantes afin que toute trafic reçu puisse
être authentifié et déchiffré. La configuration de ces différents éléments sur 3ffe::2 sera donc proche de :
spdadd -6 3ffe::1 3ffe::2 any -P in ipsec esp/transport//require;

-E aes-cbc "aescbcencryption"
Ainsi tout trafic provenant de 3ffe::1 sera protégé par ESP en mode transport avec les clés et algorithmes définies.
Afin d’activer ces paramètres il vous faudra utiliser setkey : setkey –f setkey.conf
Vous remarquerez que seuls les échanges depuis 3ffe::1 vers 3ffe::2 ainsi que ceux depuis 3ffe::1 vers 3ffe::3 sont
protégés. La réciproque n’est pas vraie ; par exemple les paquets provenant de 3ffe::2 vers 3ffe::1 ne sont en aucun
cas protégés. Vous pouvez dès à présent vérifier ces assertions par un ping depuis 3ffe::1 vers 3ffe::3. Les Echo
Request doivent être protégés par IPsec tandis que les Echo Reply circuleront en clair. Afin de faciliter cette analyse
vous pourrez utiliser Wireshark ainsi que le module ESP intégré permettant le déchiffrement des paquets.
44
Figure 43 : Déchiffrement IPsec avec Wireshark.
14. Conclusion
Au travers de ces différents articles vous avez pu vous initier aux divers mécanismes principaux composant IPv6. Ces
mécanismes sont relativement nombreux, la modification de la couche réseau nécessite en effet beaucoup
d'adaptation. IPv6 est un protocole mature, ses premières bases ont été normalisées en 1998, et n'ont cessée d'être
raffinée depuis par l'IETF. La majeure partie des systèmes d'exploitation permettant actuellement de mettre en œuvre
ce protocole; le nombre d'adresses IPv4 allouable étant presque épuisé, la transition est inéluctable … c'est donc dès
maintenant qu'il s'agit de se familiariser avec ses concepts, sa mise en œuvre et les nouvelles opportunités offertes par
IPv6.
45
15. Références
Voici quelques références glanées sur Internet :
Lien Titre
http ://standards.ieee.org/regauth/oui/tutorials/EUI64.html Guidelines For 64-Bit Identifier (EUI-64) Registration
Authority
http://standards.ieee.org/regauth/oui/oui.txt OUI définis par l’IEEE
http://www.iana.org/assignments/ipv6-multicast-addresses IPv6 Multicast Adresses
http://www.iana.org/assignments/protocol-numbers/ Protocol Numbers
http://livre.point6.net/index.php IPv6 Théorie et Pratique - Gisèle Cizault
http://ipv6ready.org Site de l’IPv6 Ready Logo Committee
http://www.deepspace6.net/docs/ipv6_status_page_apps.html Statut des applications réseaux supportant IPv6
http://mirrors.deepspace6.net/Linux+IPv6-HOWTO-fr/ HOWTO IPv6 pour Linux
http://www.linux-france.org/prj/inetdoc/guides/Advanced- HOWTO du routage avancé et du contrôle de trafic
routing-Howto/ sous Linux
http://wiki.wireshark.org/ESP_Preferences Le module de déchiffrement et d’authentification ESP
pour Wireshark
Tableau 28. Références sur Internet.
Vous trouverez dans le Tableau 29 les références aux normes décrites au sein de cet article :
Norme Titre
RFC 1981 Path MTU Discovery for IP version 6
RFC 2403 The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2409 The Internet Key Exchange (IKE)
RFC 2450 Proposed TLA and NLA Assignment Rule
RFC 2451 The ESP CBC-Mode Cipher Algorithms
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)
RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
RFC 3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
RFC 3596 DNS Extensions to Support IP Version 6
RFC 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec
RFC 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security
Payload (ESP)
RFC 3775 Mobility Support in IPv6
RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
RFC 3963 Network Mobility (NEMO) Basic Support Protocol
RFC 3971 SEcure Neighbor Discovery (SEND)
RFC 4033 DNS Security Introduction and Requirements
RFC 4109 Algorithms for Internet Key Exchange version 1 (IKEv1)
RFC 4193 Unique Local IPv6 Unicast Addresses
RFC 4291 IP Version 6 Addressing Architecture
RFC 4301 Security Architecture for the Internet Protocol
RFC 4302 IP Authentication Header
RFC 4303 IP Encapsulating Security Payload (ESP)
RFC 4306 Internet Key Exchange (IKEv2) Protocol
RFC 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
RFC 4385 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification
RFC 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
46
RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
RFC 4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
RFC 4885 Network Mobility Support Terminology
RFC 4886 Network Mobility Support Goals and Requirements
RFC 4887 Network Mobility Home Network Models
RFC 4888 Network Mobility Route Optimization Problem Statement
RFC 4889 Network Mobility Route Optimization Solution Space Analysis
RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
RFC 768 User Datagram Protocol
RFC 791 Internet Protocol
RFC 792 Internet Control Message Protocol
RFC 793 Transmission Control Protocol
RFC 826 Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit
Ethernet Address for Transmission on Ethernet Hardware
RFC 1034 Domain names - concepts and facilities
RFC 1035 Domain names - implementation and specification
RFC 2390 Inverse Address Resolution Protocol
RFC 3022 Traditional IP Network Address Translator (Traditional NAT)
Tableau 29. Principales normes indiquées dans cet article.
47

IPv 6

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IPv 6

Transféré par

Droits d'auteur :

Formats disponibles

Le protocole IPv6

2.1 Cet article explique...

2.2 Ce qu'il faut savoir...

2.3 A propos de l'auteur

3. Adressage IPv6 et nommage

3.1 Format des adresses

Exemple : fe80:0000:0000:0000:0240:96ff:fea7:00d3 est une adresse IPv6

1. La notation « :: » permet de représenter plusieurs 0 consécutifs au sein de plusieurs mots de 16 bits. Le

La méthode de simplification 1 sur l’exemple précédent nous donne fe80::0240:96ff:fea7:00d3 .

3.2 Les différents types d’adresses

• Les adresses Unicast : destinées à la communication avec une interface unique,

Ces notions seront explicitées par la suite.

3.3 Adressage Unicast

• Les adresses Lien-local : destinées à la communication au sein d’un lien,

3.3.1 Identifiant EUI-64

• EUI-64 sur 64 bits,

Figure 1 : Format d'adressage EUI-64

Figure 2 : Format d'adressage MAC-48

Code Fabricant (OUI) sur 3 Vendeur/Fabricant

Exemple : L’adresse Mac 00-40-96-A7-C5-D3 donne ainsi l’identifiant d’interface 02-40-96-FF-FE-A7-C5-D3

3.3.2 Adresses Lien-local

Figure 4 : Format d’adresse Lien-local IPv6

3.3.3 Adresses Globales

3.3.4 Adresses de loopback

3.3.5 Adresses Indéterminées

3.4 Adressage Multicast

Le champ Scope indique la portée de l’adresse selon le Tableau 2.

Les adresses multicast se dérivent encore en 2 groupes :

3.5 Adressage Anycast

Figure 6 : Exemple de résolution DNSv6 avec nslookup

Figure 7 : Entête IPv4

Figure 8 : Entête IPv6

Champs Taille Rôle

4.1 Chaînage des entêtes et extensions d’entête

Protocoles Valeur du champ Next

• Hop-by-Hop Options Header,

Extension d’entête Valeur du champ Next

Figure 10 : Extension d'entête Hop-By-Hop

Champs Taille Rôle

4.1.2 Fragment Header

Figure 11 : Extension d'entête Fragment Header

Champs Taille Rôle

4.1.3 Destination Option Header

Champs Taille Rôle

4.1.4 Authentication Header & Encapsulating Security Payload

5. Protocoles de niveau Transport pour IPv6 : TCP & UDP

Les Figures 13 et 14 présentent le pseudo-Header utilisé en IPv4 ainsi qu’en IPv6.

Figure 13 : Pseudo-header IPv4

Ces différents messages se classifient en 2 catégories :

• Messages d’erreur : notés de 0 à 127 inclus,

6.1 Entête ICMPv6

Figure 15 : Entête ICMPv6 générique

Champs Taille Rôle

6.2 Messages d’erreurs

Messages d’erreurs Valeur du champ Type

Les entêtes de ces différents messages d’erreurs sont relativement proches.

6.2.1 Destination Unreachable

Figure 16 : Entête ICMPv6 Destination Unreachable

Champs Taille Rôle

Figure 17 : Entête ICMPv6 Packet Too Big

Champs Taille Rôle

6.2.3 Time Exceeded

Figure 18 : Entête ICMPv6 Time Exceeded