Sie sind auf Seite 1von 60

Laurent GEORGE

IPv6 Page 2 sur 60

TABLE DES MATIERES


Table des matières...................................................................................................................... 2
INTRODUCTION ..................................................................................................................... 4
I. Adressage................................................................................................................................ 5
A. Représentation des adresses .............................................................................................. 5
B. Les types d'adresses........................................................................................................... 6
C. Les adresses individuelles ou adresses unicast.................................................................. 7
1. Exemples d'adresses unicast........................................................................................... 8
2. Adresse unicast opérateur .............................................................................................. 8
3. Adresses NSAP .............................................................................................................. 9
4. Adresse unicast locale .................................................................................................... 9
5. Adresse unspecified ..................................................................................................... 10
6. Adresse de bouclage..................................................................................................... 10
7. Les adresses qui encapsulent les adresses IPv4 ........................................................... 10
D. Adresses cluster............................................................................................................... 10
E. Adresses multicast ........................................................................................................... 11
1. Format des adresses multicast...................................................................................... 11
2. Adresses multicast pré-définies ................................................................................... 13
F. Les types d'adresses reconnus par les nœuds................................................................... 13
II. Protocole réseau .................................................................................................................. 14
A. Format d’en-tête IPv6 ..................................................................................................... 14
B. Les extensions IPv6......................................................................................................... 17
1. Proche en proche .......................................................................................................... 18
2. Destination ................................................................................................................... 19
3. Routage ........................................................................................................................ 19
4. Fragmentation .............................................................................................................. 21
5. Authentification ........................................................................................................... 21
6. En-tête de confidentialité ............................................................................................. 22
III. Configuration automatique et contrôle .............................................................................. 24
A. Découverte des voisins (RFC 1970) ............................................................................... 24
B. Configuration automatique.............................................................................................. 25
1. Détection d’adresse double .......................................................................................... 26
2. Création de l’adresse lien-local.................................................................................... 27
3. Auto-Configuration sans état ....................................................................................... 27
4. Auto-Configuration avec état : DHCPv6 ..................................................................... 28
C. Renumérotation automatique des routeurs ...................................................................... 28
D. Mécanisme de découverte du PMTU (RFC 1981).......................................................... 29
IV. Supports de transmission ..................................................................................................... 1
A. Réseau à diffusion ............................................................................................................. 1
1. Ethernet (RFC 1972) ...................................................................................................... 1
2. FDDI (RFC 2019) ........................................................................................................ 32
3. IEEE 802.3 ..................................................................................................................... 1
4. Anneau à jeton — Token-Ring .................................................................................... 34
B. NBMA ............................................................................................................................. 34
C. Lien point à point, PPP (RFC 2023)................................................................................ 35
D. Tunnels ............................................................................................................................ 36
V. Routage ............................................................................................................................... 38

L. George
IPv6 Page 3 sur 60

A. Protocoles de routage ...................................................................................................... 38


B. Routage interne................................................................................................................ 38
1. RIPng ........................................................................................................................... 38
2. OSPFng ........................................................................................................................ 40
C. Routage externe ............................................................................................................... 41
D. Réseau IPv6 expérimental............................................................................................... 41
1. Le réseau 6bone ........................................................................................................... 41
2. Le G6bone.................................................................................................................... 43
VI. La sécurité [RFC 1752]...................................................................................................... 45
A. Quelques définitions........................................................................................................ 45
B. Les mécanismes de sécurité dans IPv6............................................................................ 46
1. Le mécanisme de l'en-tête d'authentification (Authentication Header) ....................... 46
2. La technique ESP (Encapsulating Security Payload) .................................................. 46
3. La combinaison des mécanismes de sécurité ............................................................... 47
C. La gestion des clés (Key Management) .......................................................................... 48
1. La distribution d'une clé manuelle ............................................................................... 48
2. La distribution d'une clé automatique .......................................................................... 48
D. L'utilisation des mécanismes de sécurité dans IPv6........................................................ 49
1. Les « Firewalls » .......................................................................................................... 49
2. La protection de la Qualité de Service (QoS) .............................................................. 49
3. Des réseaux compartimentés ou à niveau multiple (Multi-level) ................................ 50
E. La prise en compte des autres éléments relatifs à la sécurité .......................................... 50
VII. Mobilité dans IPv6 ........................................................................................................... 51
A. Quelques définitions........................................................................................................ 51
B. Les formats d'en-tête pour l'option de mobilité............................................................... 52
1. L'option de mobilité pour les données utilisateur ........................................................ 52
2. L'option de mobilité pour le contrôle........................................................................... 53
C. Le format d'entrée AMT................................................................................................... 54
D. Les méthodes d'authentification...................................................................................... 55
E. La connexion à un réseau ................................................................................................ 55
1. Les procédures utilisées sur le nœud mobile ............................................................... 55
2. Les procédures utilisées sur un noeud intermédiaire ................................................... 56
3. Les procédures utilisées sur un nœud situé à la frontière (Boundary Node) du réseau
maison .............................................................................................................................. 56
F. La communication des données ....................................................................................... 56
1. Les procédures appliquées au noeud source ................................................................ 56
2. Les procédures appliquées au nœud intermédiaire ...................................................... 57
3. Les procédures appliquées au nœud de destination ..................................................... 57
Conclusion ............................................................................................................................... 58
Glossaire................................................................................................................................... 59
BIBLIOGRAPHIE ................................................................................................................... 60

L. George
IPv6 Page 4 sur 60

INTRODUCTION
L’explosion de l'Internet (dont la taille double environ tous les 12 mois) a deux conséquences :
- la consommation des adresses s'est fortement accélérée ces dernières années, et l'on
commence à parler d'épuisement des adresses IPv4 (la " fin du monde IPv4 " est
estimée aux environs de 2010 !)
- la taille des tables de routage des équipements qui doivent connaître toutes les routes
mondiales (full routing) est devenue gigantesque et n'est pas sans poser quelques
problèmes aux opérateurs de services IP.

Pour pallier ces difficultés inhérentes à la version actuelle du protocole (IPv4), un nouveau
protocole a été spécifié, le protocole IP version 6. Il doit permettre d'adresser un espace
beaucoup plus grand et fournir des techniques de routage plus efficaces (en lien avec un
adressage hiérarchique).

Le rôle de l'IETF (Internet Engineering Task Force) a été prépondérant dans le processus
d'élaboration des spécifications du nouveau protocole. Il a d'abord fait publier un livre blanc
(RFC 1550) pour définir les fonctionnalités du nouvel IP. A l'issue d'un long travail d'analyse
et de débats, " les critères techniques pour choisir le nouvel IP " (RFC 1726) ont été publiés.
Trois propositions ont été retenues (sur les 21 recueillies), comme proches des critères
imposés. Il s'agit de CATNIP (Common Architecture for The Internet Protocol), SIPP (Simple
Internet Protocol Plus) et TUBA (TCP and UDP with Bigger Addresses).

Finalement, SIPP (moyennant un certain nombre de modifications) a été retenu. Le processus


aura duré 4ans ! (sans parler de la phase de développement et d'implantation dans les
équipements, où nous sommes aujourd'hui...).

Ipv6 est donc une nouvelle version d'IP qui s'inscrit comme l'évolution naturelle et normale
d’IPv4. Il est conçu pour fonctionner aussi bien sur des réseaux à très hauts débits comme
ATM que sur des réseaux à faible bande passante tels que les réseaux sans fils.

Les principales fonctionnalités d'IPv4 sont conservées dans IPv6 excepté certaines fonctions
peu ou pas utilisées qui ont été supprimées ou rendues optionnelles. En outre, quelques
priorités ainsi que de nouvelles fonctionnalités qui faisaient défaut à son prédécesseur (la
sécurité, le support du temps réel et du multipoint, ...) ont été ajoutées.

Nous verrons qu’IPv6 possède huit grandes caractéristiques :


- des possibilités étendues d'adressage et de routage,
- un format d'en-tête simplifié,
- des possibilités d'extension des en-têtes et des options,
- le « Source Routing » ou routage en fonction de l’adresse de la source,
- le multipoint,
- l'auto-configuration des équipements,
- la sécurité (authentification, confidentialité et intégrité),
- une transition d'IPv4 à IPv6 simple et flexible.

L. George
IPv6 Page 5 sur 60

I. Adressage
L'adressage est de la toute première importance dans le réseau Internet. L'intérêt des
utilisateurs est de pouvoir se connecter au réseau Internet pour avoir accès à des données ou
pour pouvoir se connecter sur n'importe quelle machine.

Les adresses IPv6 sont des identifiants de 128 bits pour des nœuds ou un ensemble de nœuds.
La taille d’une adresse IPv6 est donc le quadruple de celle d’une adresse IPv4. En prenant en
compte les estimations les plus pessimistes et les plus optimistes, on obtient l’encadrement
suivant où l’unité est le nombre d’adresses par m2 de surface terrestre (océans compris) :

1564 ≤ nombre d’adresses disponibles ≤ 3911873538269506102

Ce calcul est bien entendu complètement arbitraire. Il est difficile de prévoir l’utilisation des
adresses dans les années futures. Ainsi, par exemple, le plan d’adressage actuellement mis en
œuvre utilise un identifiant d’équipement sur 64 bits. En fait ce genre de calcul sert de
justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des
paquets) en montrant que le nombre d’équipements adressables est colossal.

On peut distinguer trois types d'adresses:


- Unicast : employé pour envoyer un datagramme à un unique nœud.
- Cluster : employé pour identifier un groupe de nœuds qui ont en commun un préfixe
d'adresse. Un datagramme envoyé à une adresse cluster sera délivré à un membre du
groupe.
- Multicast : employé pour envoyer un datagramme à tous les membres d'un groupe de
nœuds.

Il n'y a pas d'adresses de broadcast dans la version d'IPv6, les adresses multicast assurent leurs
fonctions.
Comme dans IPv4, un sous-réseau IPv6 est associé à une seule liaison. Mais Ipv6 permet
aussi d'associer plusieurs sous-réseaux à une même liaison.
Dans la suite de notre rapport, les champs des adresses ont des noms particuliers, prenons
l'exemple de "subscriber". Lorsqu'il est utilisé avec le terme "ID" pour identifieur, après le
nom ("subscriber ID"), on se réfère au contenu du champ nommé. Alors que s'il est utilisé
avec "prefix" ("subscriber prefix"), le terme se rapporte à tous les bits de poids fort de
l'adresse en incluant ce champ.

A. Représentation des adresses


Il y a trois formes conventionnelles de représentation d'adresses Ipv6 :

1- La forme la plus appréciée est x:x:x:x:x:x:x:x, où les 'x' sont les valeurs hexadécimales
des huit blocs de 2 octets chacun.

Exemples :
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:8:800:200C:417A
On remarquera qu'il n'est pas nécessaire d'écrire tous les zéros devant un chiffre hexadécimal
dans un champ individuel, mais il doit y avoir au moins un chiffre dans chaque champ.

L. George
IPv6 Page 6 sur 60

2- La méthode d'allocation des adresses IPv6 montre qu'il est commode de "mettre" des bits à
0 dans le milieu des adresses. Pour avoir une écriture facilitée, une syntaxe adéquate sera de
supprimer les zéros. L'expression de deux "::" indiquera un ou de multiple groupes de 16 bits
à 0.

Par exemple l'adresse multicast suivante :


FF01:0:0:0:0:0:43
sera représentée de la manière suivante :
FF01::43
les "::" ne peuvent apparaître qu'une seule fois dans l'adresse.

3- Une autre forme alternative est quelquefois plus commode lorsque l'on est dans un
environnement mixte de nœuds IPv6 et IPv4. Elle est x:x:x:x:x:x:d.d.d.d, où les 'x' sont des
valeurs hexadécimales (6 groupements de 16 bits) et les 'd' des valeurs décimales (4
groupements de 8 bits de la représentation standard d'IPv4).

Exemples :
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:1:129.144.52.38

ou dans le format compressé :


::13.1.68.3
::1:129.144.52.38

B. Les types d’adresses


Les types d'adresses d'Ipv6 sont décrites par les bits de poids fort de l'adresse. Nous appelons
ce champ de longueur variable le préfixe du format (Format Prefix - FP). Donnons
l'attribution des adresses suivant le préfixe :

Adresse Préfixe Fraction


espace
alloué
Réservé 0000 0000 1/256
Réservé 0000 0001 1/256

NSAP 0000 001 1/128


IPX 0000 010 1/128
Réservé 0000 011 1/128
Réservé 0000 100 1/128
Réservé 0000 101 1/128
Réservé 0000 110 1/128
Réservé 0000 111 1/128

Réservé 0001 1/16


Réservé 001 1/8

Adresse Unicast définie par fournisseur de 010 1/8


service

Réservé 011 1/8

L. George
IPv6 Page 7 sur 60

Réservé pour les adresses géographiques 100 1/8

Réservé 101 1/8


Réservé 110 1/8
Réservé 1110 1/16
Réservé 1111 0 1/32
Réservé 1111 10 1/64
Réservé 1111 110 1/128

Adresses locales 1111 1110 1/256


Adresses Multicast 1111 1111 1/256

Pour les nœuds utilisant le protocole IPv4, les adresses unicast IPv6 ont pour préfixe 0000
0000.
Cette allocation supporte l'allocation directe des adresses fournisseurs (provider), adresses
NSAP [NSAP-USE], adresses IPX, adresses d'usage local, et les adresses multicast. De
l'espace est réservé pour les adresses géographiques. Les espaces adresses "Réservé" (85% du
total adressable) seront attribués pour de futures utilisations. Elles pourront être utilisées pour
étendre les adresses existantes (e.g. adresses de fournisseurs supplémentaires, adresses IPX,
etc.) ou pour de nouveaux emplois.

On distingue les adresses unicast des adresses multicast par la valeur des octets de poids fort
de ces adresses. Une valeur de FF (1111 1111) identifie une adresse multicast, toutes les
autres sont des adresses unicast.

C. Les adresses individuelles ou adresses unicast


L'adresse unicast d'IPv6 est basée sur le même principe de l'adresse de la version 4 d'IP sous
le protocole de routage Internet sans classes (Classless Internet Domain Routing, CIDR).
C'est-à-dire que les adresses sont allouées de manière contiguë et ont en commun les mêmes
bits de poids fort, les mêmes préfixes.

Il existe plusieurs formes d'adresse unicast dans Ipv6 : adresse unicast hiérarchique opérateur,
adresse hiérarchique géographique, adresse hiérarchique NSAP, adresse hiérarchique IPX,
adresse locale, et adresse unique de station.
Les nœuds peuvent avoir une connaissance plus ou moins étendue de la structure interne des
adresses Ipv6, cela dépend du rôle "joué" par le nœud. Par exemple les fonctions d'une station
sont différentes de celles d'un routeur. Au minimum, un nœud peut "voir" les adresses unicast
(y compris la sienne) sans structure interne :

128 bits
Node address

Une station légèrement plus perfectionnée (mais restant encore assez simple) peut avoir
connaissance du ou des préfixes de sous-réseaux et donc des liaisons qui leur sont attachés. La
valeur de n est variable suivant les adresses:

n bits 128-n bits


Subnet prefix Node ID

L. George
IPv6 Page 8 sur 60

Bien qu'un très simple routeur puisse n'avoir aucune connaissance de la structure interne des
adresses unicast IPv6, les routeurs devront généralement avoir connaissance d'un ou de
quelques niveaux hiérarchiques pour les protocoles de routage. La connaissance des domaines
différera de chaque routeur, celle-ci dépendra des positions hiérarchiques des routeurs.

1. Exemples d’adresses unicast

Voici un exemple de format d'adresse unicast qui sera probablement commun à tous les LAN
et autres environnements dont les adresses MAC IEEE-802 sont disponibles :
n bits m bits 48 bits
Subscriber prefix Subnet ID Node ID

Les 48 bits du Node ID représentent l'adresse MAC. Dans d'autres environnements, où les
adresses IEEE-802 ne sont pas disponibles, d'autres adresses de la couche liaison peuvent être
utilisées, comme les adresses E.164.
L'utilisation d'un unique node identifier, comme nous l'avons vu précédemment, rend possible
et de manière assez simple l'auto configuration des adresses. Un nœud peut ainsi relever le
subnet ID en "écoutant" les messages "Advertisement" du routeur auquel il est rattaché, et
donc fabriquer sa propre adresse IPv6 en y ajoutant son adresse IEEE MAC comme node ID
dans ce sous-réseau. Les détails d'auto configuration de station seront vus dans le chapitre
suivant.
Un autre exemple de format d'adresse unicast est donné pour un site ou une organisation qui a
besoin de couches supplémentaires de hiérarchie. Son format est :

s bits n bits m bits 128-s-n-m bits


Subscriber prefix Area ID Subnet ID Node ID

Ici, la zone (area) et le sous-réseau (subnet) définissent N niveaux hiérarchiques locaux,


permettant d'utiliser le style de masquage de CIDR.

2. Adresse unicast opérateur

Le format est le suivant :

3 bits n bits m bits p bits 125-n-m bits -p


010 Provider ID Subscriber prefix Subnet ID Node ID

La partie haute de l'adresse est attribuée aux opérateurs (fournisseurs), qui attribuent des
portions d'espace d'adresse aux souscripteurs (subscribers).
Le terme "préfixe opérateur" fait référence à la partie haute de l'adresse, provider ID
compris. On est alors dans le même schéma que les adresses IP sous le protocole CIDR.

L. George
IPv6 Page 9 sur 60

Le subscriber ID permet de distinguer un souscripteur (ou abonné) parmi d'autres attachés au


même fournisseur repéré par le provider ID. Le terme de "préfixe du souscripteur" fait
référence à la partie haute de l'adresse, subscriber compris.
Le subnet ID identifie une liaison physique spécifique. Il peut y avoir plusieurs sous-réseaux
rattachés à la même liaison physique. Tandis qu'un sous-réseau ne peut pas être raccordé à de
multiples liaisons physiques. Le terme de "préfixe sous-réseau" se rapporte à la partie haute
de l'adresse, subnet ID compris. Le groupe de nœuds identifiés par un subnet ID doivent être
attachés à la même liaison.
Le node ID identifie un unique nœud parmi le groupe de nœuds déterminé par un préfixe de
sous-réseau.

3. Adresses NSAP

L'adresse NSAP a pour format dans la nouvelle version IP,

7 bits 1 4 bits 12 bits 32 bits 16 bits 48 bits


0000001 G AFC IDI Prefix Area ID

La nouvelle version d'IP "supporte" les adresses NSAP (Network Service Access Point) d'une
manière transparente (sans conversion) et celles-ci sont totalement compatibles avec l'en-tête
étendu de noeud-par-noeud. Ipv6 est totalement "compatible" avec le plan d'adressage NSAP
existant qui a été défini par l'ISO et ITU-T, incluant des adresses utilisant la longueur totale
maximale de 20 octets. Ceci est principalement adressé aux personnes qui ont déjà planifié ou
déployé un plan d'adressage NSAP pour l'usage "du protocole réseau sans connexion"
(Connectionless Network Protocol - CLNP) selon le plan d'adressage de la couche réseau
OSI. On trouvera dans la draft "OSI NSA usage in IPv6" les recommandations pour continuer
à dresser le plan d'adressage NSAP coexistant avec IPv6 et faire la transition pour IPv6.

4. Adresse unicast locale

Les adresses "d'emploi local" sont des adresses utilisées à l'intérieur d'un site d'un souscripteur
donné. Elles sont formatées de la manière suivante :

8 bits n bits m bits p bits


1111 1110 0………0 Subnet ID Node ID

Les adresses locales sont employées pour des sites ou des organisations qui ne sont pas
(encore) connectés au monde Internet. Pour accéder à ce dernier, il n'est pas besoin d'en faire
la demande ou de "voler" un préfixe d'adresse depuis le monde Internet. L'adresse locale
suffit, lorsque l'organisation veut se connecter au monde Internet, elle forme ses adresses
globales en remplaçant le préfixe local par un préfixe souscripteur.

L. George
IPv6 Page 10 sur 60

5. Adresse unspecified

L’adresse 0:0:0:0:0:0:0:0 est appelée adresse unspecified. Elle ne doit être affectée à aucun
nœud. Elle indique l'absence d'adresse. Par exemple, on peut la trouver dans le champ d'une
adresse source de n'importe quels datagrammes envoyés par une station "initialisée" avant que
cette dernière n'est réussie à constituer sa propre adresse.
L'adresse unspecified ne doit pas être employée comme adresse destination des datagrammes
ou dans les en-têtes de routage d'IPv6.

6. Adresse de bouclage

L'adresse unicast FE00:0:0:0:0:0:0:1 est appelée adresse de bouclage. Elle est utilisée par un
nœud pour envoyer un datagramme à lui-même. Elle n'est affectée à aucune interface.
L'adresse de bouclage ne doit pas être utilisée comme adresse source de datagrammes
envoyés à l'extérieur du nœud.

7. Les adresses qui encapsulent les adresses IPv4

La transition simple à IPv6 (Simple IPv6 Transition - SIT) utilise deux formes d'adresses
unicast IPv6, conçus spécialement pour faciliter l'évolution de l'Internet passant d'IPv4 à IPv6.
Dans les deux cas, l'adresse IPv4 est inclue dans la partie basse de l'adresse Ipv6 (32 derniers
bits).
La première forme d'adresse est conçue pour représenter les adresses IPv4 des nœuds IPv4
(les nœuds ne peuvent pas comprendre le protocole IPv6) en adresses Ipv6. Elle est de la
forme suivante :

80 bits 16 bits 32 bits


0000…………………………………………………0000 0000 Ipv4 address

La seconde forme d'adresse est conçue pour être utilisée par les nœuds IPv6 qui ont besoin de
"dialoguer" avec des nœuds IPv4. On dira que ces adresses IPv4 sont compatibles IPv6.

80 bits 16 bits 32 bits


0000…………………………………………………0000 FFFF Ipv4 address

D. Adresses cluster
Les adresses cluster sont des adresses unicast, employées pour atteindre le "plus proche"
nœud (selon une notion de routage unicast du plus proche nœud) d'un ensemble de routeurs
"frontières" d'un groupe de nœuds, ces derniers étant identifiés par un préfixe commun. Un
routeur frontière d'un groupe C possède au moins une adresse avec le préfixe C et au moins
une liaison avec un autre nœud de préfixe différent de C. Les adresses cluster sont de la forme
générale :

L. George
IPv6 Page 11 sur 60

n bits 128-n bits


Cluster prefix 0000.................................................................................................0000

Par exemple, pour atteindre le plus proche routeur frontière pour le domaine de routage défini
par un opérateur D, un datagramme doit être envoyé avec l'adresse cluster :

3 bits m bits 125-m bits


010 Provider = D 0000....................................................................................................0000

Pour atteindre le routeur frontière de souscripteur S d'un opérateur D, un datagramme doit être
émis de la façon suivante,
3 bits m bits n bits 125-m-n bits
010 Provider = D Subscriber = S 0000.................................................................0000

De même, pour atteindre le routeur frontière de sous-réseau T d'un souscripteur S, d'un


opérateur D, un datagramme doit être émis de la façon suivante,

3 bits m bits n bits s bits 125-m-n-s bits


010 Provider = D Subscriber = S Subnet = T 0000…………………0000

les groupes de routeurs frontières ont besoin de savoir, d'une part qu'ils sont des routeurs de
frontière et d'autre part "accepter" les datagrammes adressés à l'adresse cluster correspondante
comme s'ils leur étaient destinés.
Les adresses cluster sont plus communément utilisées comme des adresses intermédiaires
dans l'en-tête IPv6 de routage. Ceci afin de router un datagramme à un ou plusieurs "clusters"
en chemin jusqu'à la destination finale.
La valeur 0 est réservée à chaque niveau hiérarchique de l'adresse unicast pour former des
adresses cluster.
Les adresses cluster ne doivent pas être utilisées comme adresses sources dans le datagramme
IPv6.

E. Adresses multicast
1. Format des adresses multicast

Une adresse multicast (de diffusion de groupe) IPv6 est un identifiant pour un groupe de
nœuds. Un nœud peut appartenir à n'importe quel nombre de groupes multicast. Son format
est le suivant :

8 bits 4 bits 4 bits 112 bits


1111 1111 flags scope Group ID

les 1111 1111 du début de l'adresse caractérise l'adresse comme une adresse multicast.

L. George
IPv6 Page 12 sur 60

Á Les drapeaux (flags) sont au nombre de 4 :

0 0 0 T

Les trois bits de poids fort sont réservés, et doivent être positionnés à 0.

T=0 indique que l'adresse est multicast de façon permanente, allouée par l'autorité d'adressage
de l'Internet.

T=1 indique que l'adresse est une adresse multicast provisoirement (de transition).

Áscope est une valeur de 4 bits, de portée du champ multicast. Elle est utilisée pour limitée
l'étendue du groupe multicast. Les valeurs sont les suivantes :

0 reserved
1 intra-node scope
2 intra-link scope
3 (unassigned)
4 (unassigned)
5 intra-site scope
6 (unassigned)
7 (unassigned)
8 intra-organization scope
9 (unassigned)
A (unassigned)
B intra-community scope
C (unassigned)
D (unassigned)
E global scope
F reserved

Á group ID identifie le groupe multicast, qu'il soit permanent ou provisoire, à l'intérieur du


domaine donné.

Donnons un exemple. Si le groupe de serveurs est assigné à une adresse permanente multicast
avec un groupe ID de 43 en hexadécimal, alors :

FF01:0:0:0:0:0:0:43 signifie tous les serveurs NTP du même nœud que l'émetteur.

FF05:0:0:0:0:0:0:43 signifie tous les serveurs NTP du même site que l'émetteur.

FF0E:0:0:0:0:0:0:43 signifie tous les serveurs NTP du monde Internet.

Les adresses multicast provisoires ne sont significatives qu'à l'intérieur d'un domaine donné.
Par exemple, un groupe identifié par une adresse multicast intra-site provisoire,
FF15:0:0:0:0:0:0:43 d'un site donné, n'a aucun rapport avec un groupe utilisant la même
adresse sur un site différent, ou un groupe provisoire utilisant le même group ID mais une
valeur de scope différente, ou qu'un groupe permanent avec le même groupe ID.

L. George
IPv6 Page 13 sur 60

2. Adresses multicast pré-définies

Reserved Multicast Address: FF0s:0:0:0:0:0:0:0.


Ces adresses multicast (avec une valeur de scope, s) sont réservées, et ne devront être
assignées à aucun groupe multicast.

All Nodes Adresses:


FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
Ces adresses multicast identifient le groupe de tous les nœuds IPv6, à l'intérieur d'une étendue
intra-nœud (scope=1) ou intra-liaison (scope=2).

All Hosts Adresses:


FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
Ces adresses multicast identifient le groupe de toutes les stations IPv6, à l'intérieur d'une
étendue intra-nœud (scope=1) ou intra-liaison (scope=2).

All Routers Adresses:


FF01:0:0:0:0:0:0:3
FF02:0:0:0:0:0:0:3
Ces adresses multicast identifient le groupe de tous les routeurs IPv6, à l'intérieur d'une
étendue intra-nœud (scope=1) ou intra-liaison (scope=2).

F. Les types d'adresses reconnus par les nœuds


Pour une station:
* Adresses unicast allouées.
* Adresse de bouclage.
* Adresse multicast All Nodes.
* Adresse multicast All Hosts
* Toutes les autres adresses multicast auxquelles la station appartient.

Pour un routeur:
* Adresses unicast allouées.
* Adresses cluster de tous les groupements qui considèrent le routeur comme un routeur
frontière.
* Adresse de bouclage.
* Adresse multicast All Nodes.
* Adresse multicast All Hosts
* Toutes les autres adresses multicast auxquelles le routeur appartient.

L. George
IPv6 Page 14 sur 60

II. Protocole réseau


A. Format d’en-tête IPv6
Hormis la modification de la taille des adresses, ce qui conduit à une taille d’en-tête de 40
octets (le double de l’en-tête IPv4 sans les options), le protocole IP a subi un toilettage
reprenant l’expérience acquise au fil des ans avec IPv4. Le format des entêtes IPv6 est
simplifié et permet aux routeurs de meilleures performances dans leurs traitements :

— L’en-tête ne contient plus de champ checksum qui devait être ajusté par chaque routeur en
raison de la décrémentation du champ durée de vie. Par contre, pour éviter qu’un paquet dont
le contenu est erroné, en particulier sur l’adresse de destination, ne se glisse dans une autre
communication, tous les protocoles de niveau supérieur doivent mettre en oeuvre un
mécanisme de checksum de bout en bout incluant le pseudo-en-tête. Le checksum d’UDP
facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo-
en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP.

— La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone
de données utiles.

— Les options ont été retirées de l’en-tête et remplacées par de nouveaux en-têtes appelés
extensions qui peuvent être facilement ignorées par les routeurs intermédiaires.

— Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement surtout
avec les nouvelles architectures à 64 bits.

— La taille minimale des MTU Maximum Transmission Unit est de 576 octets1. Il est
question d’augmenter la taille minimale des MTU à 1280 octets.

— La fonction de fragmentation a été retirée des routeurs. Les champs qui s’y reportent
(identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes
de découverte du PMTU Path MTU évitent d’avoir recours à la fragmentation. Si celle-ci
s’avère nécessaire, une extension est prévue.

— Le champ type de service (ToS : Type of Service) des datagrammes IPv4 a été supprimé au
profit d’un champ classe. La fonction de ce champ dans le data-gramme IPv4 a été réaffectée
par le RFC 1349. Il est utilisé par l’émetteur pour indiquer si le routage doit favoriser le délai,
le débit, la fiabilité ou le coût. Mais il n’a jamais été exploité à grande échelle. Il peut
conduire à des boucles de routage et implique la nécessité de construire un plan de routage par
type de service.
Le champ type de service n’est plus présent dans la version actuelle d’IPv6. Un champ classe
a été défini, mais son utilisation à grande échelle pose autant de problèmes. Des propositions
de réaffectation de ce champ sont discutées dans le groupe de travail intserv.

Le format d’en-tête d’un paquet IPv6 est donné par le RFC 1883 (cf. schéma ci-dessous). Si le
format du paquet est universellement admis, l’affectation de certains champs indiqués dans le

1
En IPv4 le MTU minimal est de 68 octets, 576 octets est la taille minimale garantie pour un paquet IPv4. Le
choix de 576 comme MTU minimal en IPv6 a été fait pour des raisons de compatibilité avec certains supports de
transmission.

L. George
IPv6 Page 15 sur 60

RFC 1883 est encore sujet à de nombreuses discussions au sein des instances de
standardisation.
0 4 8 16 24 31
vers. prio. identificateur de flux
longueur des données en-tête suiv. nb de sauts

adresse de la source

adresse de la destination

ÁVersion : le champ version est le seul champ qui occupe la même place dans le paquet IPv6
et dans le paquet IPv4. Sa valeur est 6.

Á Priorité ou classe : le premier mot de 32 bits étant exclu du calcul du checksum avec les
pseudo-en-tête, il est plus facile de le faire évoluer. La version actuelle du standard IPv6
définit un champ priorité sur 4 bits suivi d’un champ d’identificateur de flux sur 24 bits. Dans
de nouvelles propositions, en cours d’étude, le champ priorité est remplacé par un champ
classe étendu de 4 bits pris sur l’identificateur de flux. Ceci pour permettre aux équipes de
recherche de tester des nouvelles fonctionnalités comme la gestion de flux multimédias ou la
différenciation de services.
0 4 8 12 16 24 31
Vers. classe identificateur de flux
longueur des données en-tête suiv. nb de sauts

adresse de la source

adresse de la destination

- Priorité : les valeurs comprises entre 0 et 7 sont allouées aux trafics mettant en oeuvre
un contrôle de flux, c’est-à-dire, principalement, utilisant le protocole TCP ; les
valeurs supérieures à 7 sont réservées pour des trafics supportant des pertes mais ayant
de fortes contraintes temporelles comme les données multimédias.

L. George
IPv6 Page 16 sur 60

- Classe : Le champ classe est un champ expérimental qui permet à une source de
caractériser son trafic. Il peut être pris en compte par les routeurs intermédiaires. Pour
le récepteur, le champ classe n’a aucune signification.

D prio réservé

Ce champ est divisé en trois parties :


• Un bit D sert à marquer (bit à 1) un trafic interactif pour lequel la contrainte en
délai est plus importante que la contrainte en débit. Ce bit correspond au bit du
champ ToS d’IPv4 minimisant le délai.
• Les 3 bits suivants du champ classe servent à une source de trafic pour indiquer
la priorité de remise de ces paquets. La priorité est relative aux autres paquets
émis par la source et est définie par des valeurs comprises entre 0 et 7.
• Les quatre bits restants (ceux pris sur le champ identificateur de flux) ne sont
actuellement pas définis. Ils pourront être utilisés à des fins expérimentales.

ÁIdentificateur de flux : ce champ contient un numéro unique choisi par la source qui a pour
but de faciliter le travail des routeurs et la mise en œuvre des fonctions de qualité de service.
Cet indicateur peut être considéré comme une marque à un contexte dans le routeur. Le
routeur peut alors faire un traitement particulier : choix d’une route, traitement en « temps-
réel » de l’information.

ÁLongueur des données utiles (payload) : contrairement à IPv4, ce champ, sur deux octets, ne
contient que la taille des données utiles, sans prendre en compte la longueur de l’en-tête. Pour
des paquets dont la taille des données serait supérieure à 65536 ce champ vaut 0 et l’option
jumbogramme de l’extension de « proche-en-proche » est utilisée.

ÁEn-tête suivant : ce champ a une fonction similaire au champ protocole du paquet IPv4. Il
identifie le prochain en-tête. Il peut s’agir d’un protocole (de niveau supérieur ICMP, UDP,
TCP…) ou de la désignation d’extensions.
Les extensions contiennent aussi ce champ pour permettre un chaînage.

ÁNombre de sauts : il est décrémenté à chaque nœud traversé. Un datagramme retransmis par
un routeur est rejeté avec l’émission d’un message d’erreur ICMPv6 vers la source si la valeur
après décrémentation atteint 0.
Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est
d’indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le
réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et
donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la
décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s’agit d’un
nombre de sauts, la décrémentation est toujours de 1.
La valeur n’est pas encore officiellement attribuée, mais certaines implantations prennent
actuellement la valeur 64.
La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau, une
modification de ce paramètre sera donc relativement simple quand la limite actuelle sera
atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n’autorise la traversée
que de 255 routeurs. En réalité, dans l’Internet actuel, le nombre maximal de routeurs
traversés est d’une quarantaine, ce qui laisse une bonne marge pour l’évolution du réseau.

L. George
IPv6 Page 17 sur 60

ÁAdresse de la source : (128 bits) champ adresse de l'émetteur du datagramme.

Á Adresse de la destination : (128 bits) champ adresse du destinataire du paquet. Il est


possible que l'adresse ne soit pas celle du destinataire final si une option de routage est
présente.

Exemples :
Les paquets IPv6 suivants ont été capturés au cours d’une connexion FTP :
IEFF
FFEDIEFF
FEIDH
DDD
DE

Le paquet commence par 6 qui indique la version du protocole. Le second 6 donne la classe réservée au trafic de
commande FTP (un trafic de données aurait la priorité 4)2. L’identificateur de flot n’a pas été défini par la source
00 00 00. La longueur du paquet est de 0x0028 octets. Le paquet ne contient pas d’extension puisque la valeur
de l’entête suivant, 0x06, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le
paquet pourra traverser est de 64 (0x40). Les adresses source et destination sont des adresses de test appartenant
au plan d’adressage fournisseur.

B. Les extensions IPv6


Les extensions d’IPv6 peuvent être vues comme un prolongement de l’encapsulation d’IP
dans IP. Ces informations complémentaires sont codées dans des en-têtes qui doivent être
placés entre l'en-tête IPv6 et l'en-tête de la couche transport.

Une extension a une longueur multiple de 8 octets. Elle commence par un champ en-tête
suivant (Next Header) d’un octet qui définit le type de données qui suit l’extension : une autre
extension ou un protocole de niveau 4. Pour les extensions à longueur variable, l’octet suivant
contient la longueur de l’extension en mots de 8 octets, le premier n’étant pas compté (une
extension de 16 octets a un champ longueur de 1).

Comme illustré dans les exemples suivants, un paquet IPv6 peut comporter aucun, un ou
plusieurs en-têtes supplémentaires,

2
Il s’agit de la notation définie dans le RFC 1883.

L. George
IPv6 Page 18 sur 60

À part l’extension de proche en proche traitée par tous les routeurs intermédiaires, les autres
extensions ne sont prises en compte que par les équipements destinataires du paquet.
Lorsqu'il y a plus d'un en-tête supplémentaire utilisé dans le même paquet, le RFC 1883
recommande l’ordre suivant :
- Proche en proche (doit toujours être en première position)
- Destination (sera aussi traité par les routeurs listés dans l’extension de routage par la
source)
- Routage par la source (type 0)
- Fragmentation
- Authentification
- Sécurité
- Destination (traité uniquement par l’équipement terminal)

Chaque type d'en-tête ne doit apparaître qu'une seule fois dans le paquet (excepter dans le cas
d'une encapsulation IPv6 dans IPv6, où chaque en-tête IPv6 encapsulé doit être suivi par son
propre en-tête supplémentaire).

1. Proche en proche

Cette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée
par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d’en-tête
en-tête suivant de l’en-tête précédent) est 0 et le champ longueur de l’extension contient le
nombre de mots de 64 bits moins 1.
0 8 16 24 31
En-tête suivant lg. extension

options

L’extension est composée d’options. Pour l’instant, seules quatre options, dont deux de
bourrage, sont définies. Chaque option est une suite d’octets.
Le premier octet est un type, le deuxième (sauf pour l’option 0) contient la longueur de
l’option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du
routeur quand il rencontre une option inconnue :

00 : le routeur ignore l’option ;


01 : le routeur rejette le paquet ;
10 : le routeur rejette le paquet et retourne un message ICMPv6
d’inaccessibilité;
11 : le routeur rejette le paquet et retourne un message ICMPv6
d’inaccessibilité si l’adresse de destination n’est pas multicast.

Le bit suivant du type indique que le routeur peut modifier le contenu du champ option
(valeur à 1) ou non (valeur à 0).

L. George
IPv6 Page 19 sur 60

Les quatre options de proche en proche sont :

— Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage ;

— Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le
champ longueur indique le nombre d’octets qui suivent.
Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu’un champ longueur
pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le
traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits.

— Jumbogramme (type 194 ou 0xc2). Cette option est utilisée quand le champ longueur des
données du paquet IPv6 n’est pas suffisant pour coder la taille du paquet. Cette option est
essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l’option
jumbogramme est utilisée, le champ longueur des données utiles dans l’en-tête IPv6 vaut 0.

— L’option Router Alert a aussi été définie récemment dans IPv4 (RFC 2113). L’émetteur
envoie les données à la destination, mais s’il précise l’option Router Alert, les routeurs
intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le
paquet. Ce mécanisme est efficace puisque les routeurs n’ont pas à analyser le contenu de tous
les paquets d’un flux.
Le type de l’option n’est pas encore attribuée, mais il devra commencer par la séquence
binaire , puisqu’un routeur qui ne connaît pas cette option doit relayer le paquet sans le
modifier. Le champ valeur de l’option contient :
0 : pour les messages ICMPv6 de gestion des groupes multicast ;
1 : pour les messages RSVP ;
les autres valeurs sont réservées.

Pad 1 0

Pad n 1 longueur 0 … 0

Jumbogramme 194 4 Longueur des données

Router Alert ??? 2 valeur

2. Destination

Cette extension, dont le format est identique à l’extension de proche en proche, contient des
options qui sont traitées par l’équipement destinataire. Pour l’instant, à part les options de
bourrage (voir Pad1 et Padn, page précédente) et de mobilité, aucune autre option n’est
définie.

3. Routage

Cette extension permet d’imposer à un paquet une route différente de celle offerte par les
politiques de routage présentes sur le réseau. Pour l’instant seul le routage par la source
(type = 0), similaire aux options Strict Source Routing et Loose Source Routing d’IPv4, est
défini.

L. George
IPv6 Page 20 sur 60

Le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin
directement accessible)3 ou libéral (loose) (un routeur peut utiliser les tables de routage pour
joindre le routeur suivant servant de relais).

Le principe du routage par la source ou Source Routing pour IPv6 est le même que pour IPv4.
L’émetteur met dans le champ destination du paquet IPv6, l’adresse du premier routeur
servant de relais, l’extension contient la suite de la liste des autres routeurs relais et le
destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension
de routage par la source, il permute son adresse avec l’adresse du prochain routeur et réémet
le paquet vers cette adresse suivante.

Le schéma suivant donne le format de l’extension de routage par la source :


0 8 16 24 31
en-tête suivant lg. extension type de routage segments restants
réservé bitmap strict/loose

adresse du routeur 1

adresse du routeur n

Á Longueur de l’en-tête : ce champ indique le nombre de mots de 64 bits qui composent


l’extension. Pour l’extension de type 0, cela correspond au nombre d’adresses présentes dans
la liste, multiplié par 2.

ÁType de routage : ce champ indique la nature du routage. Pour l’instant, seul le routage par
la source, de type 0 est spécifié. La suite de l’en-tête correspond à ce type.

ÁSegments restants : le nombre de segments restants est décrémenté après la traversée d’un
routeur. Il indique le nombre d’équipements qui doivent encore être traversés. Il permet de
trouver l’adresse qui devra être substituée. Pour le type 0, la valeur maximale est de 23.

Á Bitmap strict/loose : les 24 bits de la bitmap indiquent (de la gauche vers la droite), pour
chaque équipement de la liste, s’il s’agit d’un routage strict (valeur à 1) ou libéral (valeur à 0).

3
Cette possibilité est controversée et devrait disparaître à court terme.

L. George
IPv6 Page 21 sur 60

ÁAdresse du routeur : la liste comprenant les routeurs à traverser et le destinataire est fournie.
Ces adresses ne peuvent pas être multicast.

4. Fragmentation

L'en-tête de fragmentation est utilisé par la source pour envoyer des paquets plus grands que
ne peut acheminer le réseau à leurs destinataires. A la différence d'IPv4, la fragmentation est
exécutée seulement par les nœuds source et non plus par les routeurs qui acheminent les
paquets le long du chemin. L'en-tête de fragmentation est repéré par une valeur de En-tête
suivant égale à 44 juste après le précédent en-tête.
Le format est le suivant :
0 8 16 24 31
en-tête suivant Réservé (0) place du fragment 0 0M
identification

La signification des champs est identique à celle d’IPv4 :



Á Place du fragment : ce champ indique lors du réassemblage où les données doivent être
insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés
datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier,
doit être multiple de 8 octets.

ÁLe bit M s’il vaut 1 indique qu’il y aura d’autres fragments émis.

Á Le champ identification permet de repérer les fragments appartenant à un même paquet


initial. Il est différent pour chaque paquet et recopié dans ses fragments.

Remarque : le bit DF (don’t fragment) d’IPv4 n’est plus nécessaire puisque, si l’extension
n’est pas présente, il y aura rejet du paquet par le routeur.

Dans IPv4, la valeur d’une option était codée de manière à indiquer au routeur effectuant la
fragmentation, si elle devait être copiée dans les fragments. Dans IPv6, l’en-tête et les
extensions qui concernent les routeurs intermédiaires (pour l’instant proche en proche,
routage par la source) sont recopiées dans chaque fragment.

5. Authentification

L'en-tête d'authentification est utilisé pour authentifier et assurer l'intégrité des paquets. La
non-répudiation est obtenue par un algorithme d'authentification exécuté sur l'en-tête
d'authentification. Mais elle n'est pas obtenue par tous les algorithmes d'authentification
exécutés sur cet en-tête. L'en-tête d'authentification est déterminé par la valeur 51 du champ
En-tête suivant, et a le format suivant :

L. George
IPv6 Page 22 sur 60

0 8 16 24 31
en-tête suivant lg. extension réservé
indice des paramètres de sécurité

données d’authentification
(nombre variable de mots de 32 bits)

Á En-tête suivant (8 bits) : identifie le type d'en-tête suivant immédiatement l'en-tête


d'authentification. Les valeurs sont identiques à celles du champ de protocole de IPv4.

Á Longueur extension (8 bits) : c'est la longueur du champ de données d’authentification,


multiple de 8 octets.

ÁRéservé (16 bits ) : initialisé à 0 à l'émission, ignoré à la réception.

ÁIndice des paramètres de sécurité : Security Association ID (SAID - 32 bits) ; lorsqu'il est
combiné avec l'adresse source, il identifie au(x) destinataire(s) le type de sécurité établi,
associé aux paquets concernés.

Á Données d’authentification (longueur variable) : information sur l'algorithme spécifique


nécessaire à authentifier la source du paquet et à assurer son intégrité conformément à la
sécurité associée. La longueur de ce champ est variable et est un multiple de 8 octets.

6. En-tête de confidentialité

L’en-tête privé cherche à donner une confidentialité et une intégrité en cryptant les données à
protéger et en les plaçant dans la section « données » de l’en-tête de confidentialité (Privacy
Header). Suivant les exigences de sécurité de l'utilisateur, soit la trame de couche transport
(e.g. UDP ou TCP) est cryptée, soit le datagramme entier d'IPv6 l'est. Cette approche par
encapsulation est nécessaire pour assurer une confidentialité du datagramme complet original.
S'il est présent, l'en-tête de confidentialité est toujours le dernier champ non-crypté dans un
paquet.

L'en-tête de confidentialité travaille entre stations, entre une station et un gateway (passerelle)
de sécurité, ou entre des gateways de sécurité. Ceci permet sans d'importants coûts financiers
et de performance d'assurer un réseau digne de confiance en transitant du trafic sécurisé sur
des segments du réseau qui ne le sont pas.

L. George
IPv6 Page 23 sur 60

0 8 16 24 31
indice des paramètres de sécurité
données de synchronisation
(longueur variable)

en-tête suivant lg. extension réservé


données protégées
(longueur variable)
trailer

Á Indice des paramètres de sécurité (SAID - 32 bits) : identifie le type de sécurité au


datagramme. Si aucune association de sécurité n'a été établie, la valeur de ce champ est
0x0000. Une association de sécurité est unilatérale. Une communication sécurisée entre deux
stations doit avoir normalement deux SAID (un pour chaque sens des échanges). La station
destinataire utilise la combinaison de la valeur du SAID et de l'adresse origine pour distinguer
la correcte association.

ÁDonnées de synchronisation (longueur dépendant du SAID) : ce champ est optionnel et sa


valeur dépend du SAID utilisé. Par exemple, le champ peut contenir des données de
synchronisation de cryptographie pour un algorithme de codage. Il peut aussi contenir un
vecteur d'initialisation cryptographique. L'implantation d'un en-tête de confidentialité utilisera
une valeur de SAID pour déterminer si le champ n'est pas vide, et si c'est le cas, évalue la
longueur du champ et l'utilise.

ÁEn-tête suivant (8 bits), crypté : identifie le type d'en-tête suivant immédiatement l'en-tête
de confidentialité. Les valeurs sont identiques à celles du champ de protocole de IPv4.

ÁRéservé (17 bits), crypté : ignoré à la réception.

Á Longueur (8 bits), crypté : longueur de l'en-tête privé, à l'exclusion des 8 premiers octets,
donnée en un multiple de 8 octets.

Á Données protégées (longueur variable), crypté : ce champ peut contenir un datagramme


complet encapsulé IPv6, une séquence d'option(s) IPv6 ou pas, et enfin le paquet de la couche
transport. Ou bien, il est constitué du paquet de la couche transport précédé ou pas d'une série
d'option(s).

ÁAlgorithme-dependant Trailer (trailer - longueur variable suivant SAID), crypté : ce champ
est utilisé pour faire du bourrage (nécessité de certains algorithmes) ou pour enregistrer des
données d'authentification à utiliser avec un algorithme de cryptographie qui fournit la
confidentialité sans l'authentification. Ce champ n'est présent que si l'algorithme utilisé le
nécessite.

L. George
IPv6 Page 24 sur 60

III. Configuration automatique et contrôle


A. Découverte des voisins (RFC 1970)
Le protocole de découverte des voisins (neighbor discovery) permet à un équipement de
s’intégrer dans l’environnement local, c’est-à-dire le lien sur lequel sont physiquement
transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même
support (stations et routeurs).

Le champ nombre de sauts de l’en-tête IPv6 contient la valeur 255 — il peut sembler
paradoxal d’utiliser une valeur aussi grande pour des datagrammes qui ne doivent pas être
routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur
plus petite, cela signifie que l’information provient d’un autre réseau et que le datagramme
doit être rejeté.

Le champ priorité vaut 154.

Le protocole réalise les différentes fonctions suivantes :

— Résolution d’adresses. Comme pour IPv4, ce protocole construit des tables de mise en
correspondance entre les adresses IPv6 et physiques.

— Détection d’inaccessibilité des voisins ou NUD (Neighbor Unreachability Detection).


Cette fonction n’existe pas en IPv4. Elle permet d’effacer des tables de configuration d’un
équipement les voisins qui sont devenus inaccessibles (panne, changement d’adresse,...). Si
un routeur devient inaccessible la table de routage peut être modifiée pour prendre en compte
une autre route.

— Configuration. La configuration automatique des équipements est l’un des attraits


principaux d’IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont
mises en œuvre :
- Découverte des routeurs : ce protocole permet aux équipements de déterminer les
routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont remplies
par le protocole ICMP Router Discovery.
- Découverte des préfixes : l’équipement apprend le ou les préfixes du réseau en
fonction des annonces faites par les routeurs. En y ajoutant l’identifiant d’interface de
l’équipement, celui-ci construit son ou ses adresses IPv6.
Il n’existe pas d’équivalent pour le protocole IPv4 puisque les adresses sont trop
courtes pour faire de l’auto-configuration.
- Détection des adresses dupliquées : comme les adresses sont construites automati-
quement, il existe des risques d’erreurs en cas d’identité de deux identifiants. Ce
protocole teste qu’aucun autre équipement sur le lien ne possède la même adresse
IPv6.
Cette fonctionnalité est une évolution de l’ARP gratuit d’IPv4 émis à l’initialisation de
l’interface.
- Découverte des paramètres. Ce protocole permet aux équipements d’apprendre les
différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de

4
Valeur définie dans le RFC 1883. Cette exigence devrait bientôt disparaître.

L. George
IPv6 Page 25 sur 60

sauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration


automatique avec état (comme DHCPv6) est active...
Il n’existe pas d’équivalent en IPv4.

Indication de redirection. Ce message est utilisé quand un routeur connaît une route
meilleure (en nombre de sauts) pour aller à une destination.

Les différentes fonctionnalités de découverte des voisins utilisent 5 types de messages


ICMPv6 :

— Message de sollicitation d’un routeur : il est émis par un équipement au démarrage pour
recevoir plus rapidement des informations du routeur. Ce message est émis à l’adresse IPv6
de multicast réservée aux routeurs sur le même lien.

— Annonce du routeur : ce message est émis périodiquement par les routeurs ou en réponse à
un message de sollicitation d’un routeur par un équipement.

— Sollicitation d’un voisin : ce message permet d’obtenir des informations d’un voisin,
c’est-à-dire situé sur le même lien physique (ou via des ponts). Le message peut lui être
explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de
l’adresse physique, il correspond à la requête ARP du protocole IPv4.

— Annonce d’un voisin : ce message est émis en réponse à une sollicitation, mais il peut
aussi être émis spontanément pour propager plus rapidement une information. Dans le cas de
la détermination d’adresse physique, il correspond à la réponse ARP pour le protocole IPv4.

— Indication de redirection : la technique de redirection est la même que dans IPv4. Un


équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et
l’adresse d’un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie
ce message pour indiquer qu’une route plus courte existe. En effet, avec IPv6, comme le
routeur par défaut est appris automatiquement, la route n’est pas forcément la meilleure.
Un autre cas d’utilisation particulier à IPv6 concerne des stations situées sur un même lien
physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par
le routeur par défaut. Ce dernier les avertit qu’une route directe existe.

Chacun de ces messages peut contenir des options qui sont au nombre de 4 (adresse physique
de la source/cible, information sur le préfixe, en-tête redirigé, MTU).

B. Configuration automatique
Traditionnellement, la configuration d’une interface réseau d’une machine demande une
configuration manuelle. C’est un travail souvent long et fastidieux. Avec IPv6, cette
configuration est automatisée donnant par là-même des caractéristiques de fonctionnement
immédiat (« plug and play ») à l’interface réseau. La configuration automatique signifie
qu’une machine obtient toutes les informations nécessaires à sa connexion à un réseau local
IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son
nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire
des informations de « spécialiste ».

L. George
IPv6 Page 26 sur 60

L’auto-configuration a pour objectif :


- l’acquisition d’une adresse quand une machine est attachée à un réseau pour la
première fois ;
- l’obtention de la nouvelle adresse suite à la renumérotation des machines du site après
un changement d’opérateur. L’opération de re-numérotage revient concrètement à
changer la partie haute de l’adresse. L’auto-configuration d’adresse va servir de
vecteur dans l’attribution du nouveau préfixe.

Le rôle du routeur est important dans l’auto-configuration. Il dicte à la machine, par les bits 0
et 2 du message d’annonce de routeurs, la méthode à retenir et fournit éventuellement les
informations nécessaires à sa configuration. La valeur de ces bits est donnée par
l’administrateur. La mise à la valeur 1 indique à la machine de retenir la méthode d’auto-
configuration avec état. L’algorithme de la procédure d’auto-configuration d’adresse se
décompose de la manière suivante :

— La toute première étape consiste à créer l’adresse lien-local.

— Une fois l’unicité de cette adresse vérifiée, la machine est en mesure de communiquer
avec les autres machines du lien.

— Maintenant, la machine doit chercher à acquérir un message d’annonce du routeur pour


déterminer la méthode d’obtention de l’adresse unicast globale.

— S’il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le
message d’annonce de routeurs, à savoir :
- l’auto-configuration sans état (stateless autoconfiguration), utilisée quand la gestion
administrative des adresses attribuées n’est pas nécessaire au sein d’un site.
- l’auto-configuration avec état (stateful autoconfiguration), retenue lorsqu’un site
demande un contrôle strict de l’attribution des adresses.

— En l’absence de routeur sur le lien, la machine doit essayer d’acquérir l’adresse unicast
globale par la méthode d’auto-configuration avec état. Si la tentative échoue, c’est terminé.
Les communications se feront uniquement sur le lien avec l’adresse lien-local. La machine
n’a pas une adresse avec une portée qui l’autorise à communiquer avec des machines autres
que celles du lien.

1. Détection d’adresse double

Pour vérifier l’unicité des adresses unicast, les machines doivent exécuter un algorithme de
Détection d’Adresse Double (DAD) avant de les utiliser. L’algorithme utilise les messages
ICMPv6 « sollicitation d’un voisin » et « annonce d’un voisin ». Si une adresse double est
découverte, elle ne pourra être attribuée à l’interface. L’auto-configuration s’arrête et une
intervention humaine devient obligatoire. Une adresse est qualifiée de « provisoire » pendant
l’exécution de l’algorithme DAD et ce jusqu’à la confirmation de son unicité. Une adresse
provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation
et d’annonce d’un voisin. Les autres messages reçus sont ignorés. L’algorithme DAD consiste
à envoyer un message sollicitation d’un voisin avec comme adresse cible l’adresse provisoire.

L. George
IPv6 Page 27 sur 60

Trois cas se présentent :

— Un message annonce d’un voisin est reçu ; l’adresse provisoire est utilisée comme adresse
valide par une autre machine. L’adresse provisoire n’est pas unique et ne peut être retenue.

— Un message sollicitation d’un voisin est reçu ; l’adresse provisoire est également une
adresse provisoire pour une autre machine qui est en train d’exécuter l’algorithme DAD.
L’adresse provisoire ne peut être utilisée par aucune des machines.

— Rien n’est reçu au bout d’une seconde (valeur par défaut) ; l’adresse provisoire est unique,
elle passe de l’état de provisoire à celle de valide et elle est assignée à l’interface.

2. Création de l’adresse lien-local

À l’initialisation de son interface, la machine construit un identifiant pour l’interface qui doit
être unique au lien. Cet identifiant a été dans sa première version l’adresse MAC de la
machine ; actuellement il est sous le format de l’identifiant EUI-64. Le principe de base de la
création d’adresse IPv6 est de marier un préfixe avec l’identifiant. L’adresse lien-local est
créée en prenant le préfixe lien-local ()() qui est fixé. L’adresse ainsi constituée est
encore interdite d’usage. Elle possède un état provisoire car la machine doit encore vérifier
l’unicité de cette adresse sur le lien au moyen de la procédure de détection d’adresse double.
Si la machine détermine que sa création d’adresse lien-local a échoué (c’est-à-dire qu’elle
n’est pas unique), l’auto-configuration s’arrête et une intervention manuelle est nécessaire.
Une fois que l’ambiguïté sur l’unicité de l’adresse lien-local a été levée, l’adresse provisoire
devient une adresse valide pour l’interface. La première phase de l’auto-configuration
consistant à créer une adresse lien-local est achevée.

3. Auto-Configuration sans état

L’auto-configuration sans état ne demande aucune configuration manuelle des machines, une
configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du
protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant
un sous-réseau à diffusion. Cette méthode ne s’applique que pour les machines et ne peut être
retenue pour la configuration des routeurs. Le principe de base de l’auto-configuration sans
état est qu’une machine génère son adresse IPv6 à partir d’informations locales et
d’informations fournies par un routeur. En fait le routeur fournit à la machine les informations
sur le sous-réseau associé au lien, il donne le préfixe ou le localisateur de l’adresse. Comme
pour la création de l’adresse lien-local, l’adresse unicast globale est obtenue en concaténant le
préfixe avec l’identifiant de l’interface. Le préfixe provient du message d’annonce de routeurs
et plus précisément de l’option « information sur le préfixe ». Bien qu’il faille vérifier
l’unicité de toutes les adresses unicast, dans le cas d’une adresse unicast obtenue par auto-
configuration sans état cela n’est pas nécessaire. En effet, l’identifiant de l’interface a déjà été
contrôlé dans l’étape de création de l’adresse lien-local. L’identifiant étant le même, il n’y a
plus aucune ambiguïté sur son unicité. L’adresse unicast globale constituée est aussi unique
que celle lien-local. La re-numérotation des machines d’un lien s’effectue au moyen des
routeurs qui passent les adresses utilisées dans un état déprécié et annoncent par la suite le
nouveau préfixe. Les machines pourront recréer une adresse préférée.

L. George
IPv6 Page 28 sur 60

4. Auto-Configuration avec état : DHCPv6

Avec l’auto-configuration avec état, une machine IPv6 obtient les adresses et/ou d’autres
informations de configuration par l’intermédiaire d’un serveur. Tout le mécanisme d’auto-
configuration avec état est bâti sur le modèle du client-serveur et repose sur l’utilisation du
protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6). Le protocole DHCPv6
sert à remettre des paramètres de configuration d’un serveur DHCP à un client IPv6. Un
paramètre de configuration est une information utile à la machine pour configurer son
interface réseau de manière qu’elle puisse communiquer sur son lien ou sur l’Internet. Ceci
comprend notamment les adresses pour le client, le serveur de nom, le nom de domaine etc.
Pour les adresses, par exemple, le serveur maintient une table pour lui permettre de savoir
quelles sont les adresses allouées et celles qui ne le sont pas. L’ensemble des adresses gérées
par le serveur est créé par l’administrateur du site. Le serveur DHCP ne se trouve pas
forcément sur le même lien que le client et dans ce cas, les échanges DHCPv6 passent par un
relais. Grâce à ces relais, le serveur peut maintenir la configuration des machines situées sur
plusieurs liens différents. Conformément au modèle client-serveur, les échanges se composent
de requêtes et de réponses. Une transaction est pratiquement toujours entamée sur l’initiative
d’un client par une requête DHCP. La fiabilité de la transaction est assurée par le client, qui
répète sa requête DHCP jusqu’à recevoir une réponse ou obtenir la certitude que le serveur
DHCP est indisponible. DHCPv6 est un protocole d’application qui se sert du protocole de
transport UDP au-dessus de IPv6. Un client envoie les requêtes sur le port 547 du serveur et
recevra les réponses par le port 546.

Le protocole DHCPv6 se compose de 6 types de messages :

— Sollicitation DHCP, message émis vers un serveur ou un relais DHCP. Un client émet un
tel message pour obtenir l’adresse d’un serveur DHCP.

— Annonce DHCP, message émis en réponse à un message Sollicitation DHCP. Il donne


l’adresse IPv6 d’un serveur DHCP.

— Requête DHCP, message émis d’un client vers un serveur pour demander des paramètres
de configuration.

— Réponse DHCP, message émis par le serveur suite à une demande du client.

— Libération DHCP, demande du client de libérer des ressources allouées par le serveur.

— Reconfiguration DHCP, message émis par le serveur pour informer le client qu’il a de
nouvelles informations de configuration. Le client doit alors commencer une nouvelle
transaction pour acquérir ces informations.

C. Renumérotation automatique des routeurs


Le protocole de découverte de voisin permet la configuration initiale et la reconfiguration des
équipements terminaux de manière automatique. Il ne s’applique pas aux routeurs, pour des
raisons de sécurité et parce que la configuration d’un routeur est plus complexe. C’est une des
critiques sur IPv6 en l’état actuel : un site qui change de fournisseur d’accès doit reconfigurer

L. George
IPv6 Page 29 sur 60

tous ses routeurs à la main. Un des buts du plan d’adressage GSE était de supprimer ce
problème. Une autre approche est de concevoir un protocole spécifique pour la
reconfiguration automatique des routeurs. Un tel protocole est en cours de discussion.

Ce protocole est basé sur un message ICMPv6 spécial, dont le type n’a pas encore été précisé.
Ce message contient un préfixe de test, une opération, et des nouveaux préfixes. Lorsqu’un
routeur reçoit un tel message, il regarde si le message concerne un des préfixes associés à une
de ses interfaces : pour cela il regarde si le préfixe de test est un préfixe de ce préfixe
d’interface. Si c’est le cas, on applique l’opération contenue dans le message à l’interface ;
l’opération peut être :
- ajouter : on ajoute à l’interface les nouveaux préfixes contenus dans le message,
- remplacer : on remplace le préfixe sélectionné de l’interface par les nouveaux préfixes
contenus dans le message,
- affecter : on remplace tous les préfixes associés à l’interface par les nouveaux préfixes
contenus dans le message.

En fait, chaque préfixe ajouté (ou de remplacement) est formé en concaténant un nouveau
préfixe et un champ de bits pris dans l’ancien préfixe d’interface (champ longueur à
conserver du message). Ceci permet de changer la partie haute de plusieurs préfixes en un
seul message.

Le protocole comprend aussi des mécanismes de détection de messages perdus ou dupliqués,


et un mécanisme de signature pour sécuriser la reconfiguration.
Avec un tel protocole il est possible, lors d’un changement de fournisseur d’accès, de
reconfigurer tous les routeurs du site en quelques messages. Une fois les routeurs
reconfigurés, les protocoles de configuration automatique (avec ou sans état) permettent de
reconfigurer tous les équipements du site.

D. Mécanisme de découverte du PMTU (RFC 1981)


Pour des considérations d’efficacité, il est généralement préférable que les informations
échangées entre équipements soient contenues dans des datagrammes de taille maximale.
Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille
autorisée par l’ensemble des liens traversés.

Elle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de
taille maximale sur le chemin).

Initialement, l’équipement émetteur fait l’hypothèse que le PMTU d’un certain chemin est
égal au MTU du lien auquel il est directement attaché. S’il s’avère que les paquets transmis
sur ce chemin excédent la taille maximale autorisée par un lien intermédiaire, alors le routeur
associé détruit ces paquets et retourne un message d’erreur ICMPv6 de type « paquet trop
grand », en y indiquant le MTU accepté. Fort de ces informations, l’équipement émetteur
réduit le PMTU supposé pour ce chemin.

Plusieurs itérations peuvent être nécessaires avant d’obtenir un PMTU permettant à tout
paquet d’arriver à l’équipement destinataire sans jamais excéder le MTU de chaque lien
traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de
576 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole

L. George
IPv6 Page 30 sur 60

reposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la
fiabilité de la communication en retransmettant si nécessaire.

Si la détermination du PMTU se fait essentiellement lors des premiers échanges entre les
équipements concernés, elle peut également être revue en cours de transfert si, suite à un
changement de route, un lien plus contraignant est traversé.

L’émetteur vérifie aussi que le PMTU n’a pas augmenté en envoyant de temps en temps un
paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est
augmentée.

Signalons enfin que l’algorithme de découverte du PMTU fonctionne indifféremment avec


des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU
minimal permis par l’ensemble des chemins vers chaque site destinataire du groupe de
diffusion.

Mise en œuvre :
L’exploitation de l’information de PMTU se fait de plusieurs façons suivant l’endroit où les
données à transmettre sont segmentées :
- si un protocole de type TCP est utilisé, celui-ci assurera la segmentation de façon
transparente pour les applications, en fonction des informations de PMTU que pourra
lui communiquer la couche IPv6.
- si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par
une couche supérieure, éventuellement l’application. Il faut donc que celle ci (1)
puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la
suite, et (2) puisse segmenter ses données en conséquence.

Parce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de
fragmentation.

Un deuxième aspect concerne l’identification des chemins afin de pouvoir y associer les
informations de PMTU. Plusieurs possibilités, laissées à l’implémenteur, sont possibles. Un
chemin peut être identifié par l’adresse destination, ou par l’identificateur de flux si celui-ci
est utilisé, ou par la route suivie dans le cas où elle est imposée.

Enfin, s’il est fortement recommandé que chaque équipement supporte le mécanisme de
recherche du PMTU, ce n’est pas obligatoire. Ainsi, un équipement qui n’en dispose pas (par
exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU
minimal que doit supporter tout lien soit 576 octets.

L. George
IPv6 Page 1 sur 60

IV. Supports de transmission


Le principe du transport d’un datagramme IPv6 entre deux machines directement reliées entre
elles est le même que pour IPv4. Il est tout d’abord routé vers une interface d’émission qui
l’encapsule dans une trame (PDU de niveau 2 dans le modèle de référence de l’OSI), elle-
même transmise sur un lien physique. La machine destination reçoit la trame sur son interface,
la décapsule et la traite. Une adresse sur un lien sera appelée Adresse MAC.

A. Réseau à diffusion
Le protocole de transport de datagrammes IPv6, reposant sur des supports permettant le
multicast, autorise l’utilisation du protocole de découverte de voisins pour faire la
correspondance entre adresse IPv6 et adresse MAC.

1. Ethernet (RFC 1972)

Les datagrammes IPv6 utilisent l’encapsulation standard dans des trames Ethernet, chaque
trame contenant un seul datagramme. L’en-tête de la trame Ethernet contient les adresses
Ethernet source et destination, et le champ type vaut ['' (pour IPv4 le champ type
valait [).

La structure d’une trame est :

trame Ethernet
paquet IPv6
adresse de
6 octets
la source

adresse de En-tête IPv6


6 octets
destination + extensions

2 octets 0x86DD

≤ 1500 octets données


données utiles

4 octets CRC

La taille maximale d’un datagramme pouvant être transmis directement par une interface
Ethernet (MTU) est normalement de 1500 octets. Une valeur plus faible peut être forcée par
configuration manuelle ou en utilisant l’option MTU des annonces de routeurs.

L. George
IPv6 Page 32 sur 60

Si un datagramme est plus grand que le MTU prévu, l’interface le rejette. La couche
supérieure de transport doit soit changer la taille des paquets, soit utiliser l’extension de
fragmentation.

Pour les adresses de multicast, le protocole de découverte des voisins n’est pas utilisable.
L’adresse Ethernet est calculée en concaténant le préfixe [ et les 4 octets de poids
faible de l’adresse IPv6.

Pour la construction des adresses lien-local et des adresses auto-configurées, l’identifiant


d’interface est celui dérivé de l’adresse MAC IEEE 802 constructeur de l’interface Ethernet.

Pour les messages ICMPv6 de découverte de voisins, le format des options « adresse
physique Source/Destination » est :

Type : type de l’option « Neighbor Discovery »


Long : 1 (i.e. 8 octets)

8 bits 8 bits 48 bits

Type Long = 1 Adresse MAC

2. FDDI (RFC 2019)

La taille maximum d’une trame FDDI est de 4500 octets, ce qui autoriserait un MTU
maximum de 4470 octets. Pour permettre des extensions, le MTU IPv6 par défaut pour FDDI
a été fixé à 4352 octets. Toutefois, à cause de la présence possible de ponts IEEE 802.1d
(Spanning Tree,...), le MTU effectif peut être plus faible (par exemple en présence de ponts
Ethernet/FDDI, le MTU doit être de 1 500 octets). La valeur par défaut du MTU peut donc
être modifiée, soit par configuration manuelle, soit en utilisant l’option MTU des paquets
« Annonce du routeur ».

Les datagrammes IPv6 sont transmis dans des trames FDDI asynchrones avec jeton simple,
chaque trame contenant un datagramme. L’encapsulation utilisée est l’encapsulation
LLC/SNAP avec adresses 48 bits et un champ type protocole valant 0x86DD.

La structure d’une trame est :

avec : FC « Frame Code». Doit être dans l’intervalle [ - [.


DSAP, SSAP Valeur [$$, indiquant une encapsulation SNAP.
CTL Valeur [, indiquant une information non numérotée.
OUI Valeur [ (« Qrganizationally Unique Identifier »).
Code Valeur [''.

L. George
IPv6 Page 1 sur 60

trame FDDI

1 octet FC Encapsulation NSAP


trame LLC+SNAP
adresse de
6 octets 1 DSAP paquet IPv6
la source
1 SSAP
1 CTRL en-tête +
adresse de
6 octets extensions
destination 3 OUI

2 code

< 4500 octets données


données
données

4 octets CRC

Le principe régissant le calcul de l’identifiant d’interface et celui de l’adresse MAC à partir


d’une adresse IPv6 de multicast est le même que pour Ethernet. L’option « adresse physique
Source/Destination » est aussi décrite dans le chapitre consacré à Ethernet.

3. IEEE 802.3

A priori, un des obstacles à l’utilisation directe du protocole IEEE 802.3 semble levé avec
IPv6. Avec IPv4, comme il n’existe pas de numéro de SAP attribué au protocole ARP,
l’encapsulation SNAP est obligatoirement utilisée.

Avec IPv6, le protocole ARP est remplacé par le protocole de découverte des voisins qui
utilise les messages ICMPv6. Techniquement, IPv6 peut être utilisé au-dessus du protocole
IEEE 802.3. Reste le problème de l’alignement des champs. Un soin tout particulier a été
apporté dans la conception des en-têtes pour les aligner sur des mots de 64 bits. Or l’en-tête
IEEE 802.2, obligatoire, fait 3 octets. L’encapsulation SNAP est toujours nécessaire, car avec
ses 5 octets, elle aligne le début du paquet IPv6 au début d’un mot de 64 bits.

L’encapsulation est la même que pour FDDI.

4. Anneau à jeton — Token-Ring

L. George
IPv6 Page 34 sur 60

Il n’y a pas actuellement de RFC pour le transport de IPv6 sur les autres supports de type
IEEE 802, comme l’anneau à jeton. En s’inspirant du STD 43 (RFC 1042) qui définit
l’encapsulation pour IPv4, ainsi que des sections précédentes, il serait aisé de définir un
protocole de transport adéquat. Une proposition encore à l’état de draft [NCT-id] a été faite
pour l’anneau à jeton (IEEE 802.5) :

— La taille maximale possible pour un paquet est très variable à cause de la possibilité du
« source routing » qui ajoute des informations pour indiquer le chemin à travers les ponts. La
valeur du MTU est donc configurable, avec une valeur défaut de 1500, mais les valeurs de
longueur de trame indiquées dans les trames de « source routing » peuvent être prise en
compte.

— Le format des trames est celui d’une encapsulation LLC/SNAP avec un champ type
[''. Le format est analogue à celui de FDDI. Le format de l’identifiant d’interface et de
l’option « adresse physique Source/Cible » suit les même règles que pour Ethernet ou FDDI.

— La correspondance entre adresse multicast et adresse physique n’est pas aussi simple
qu’avec Ethernet ou FDDI. En effet les composants pour l’anneau à jeton ne permettent de
positionner qu’un seul bit dans l’adresse. Il en résulte 10 classes d’adresses MAC pour le
multicast dans lesquelles sont rangées plusieurs adresses IPv6 de multicast.

B. NBMA
Les réseaux à destinataires multiples (donc pas point à point) mais sans diffusion, les NBMA
(Non Broadcast Multiple Access) posent des problèmes particuliers car la découverte des
voisins s’appuie fortement sur les services de multicast.

Le principal exemple aujourd’hui de réseau NBMA est l’ATM (le mode de transfert
asynchrone) qui adresse les problèmes de qualités de services dont il serait intéressant de
disposer aussi au niveau IPv6.

Le problème qui se pose aujourd’hui est de savoir comment traduire les qualités de service
qu’offre ATM en des qualités de services Internet. La notion de qualité de service n’étant
toujours pas claire dans le monde IP, le groupe « IntServ » de l’IETF s’est chargé de définir
les différents services à intégrer dans l’Internet.

Parallèlement, le groupe ISSLL (Integrated Services on Specific Link Layers) de l’IETF


étudie actuellement la manière de réaliser la mise en correspondance des deux types de
qualités de service.

Soulignons que le problème des qualités de service n’est pas propre à IPv6. Cependant, IPv6 a
plus de chance de s’adapter aux solutions qui seront proposées, grâce à la structure de l’en-
tête IPv6. En effet, les chercheurs sont en train d’explorer les possibilités d’exploiter les
champs « priorité » et « identificateur de flux » pour parvenir à la mise en correspondance des
deux types de qualités de service (IP/ATM).

Par ailleurs, la mise en oeuvre du protocole IPv6 au-dessus d’une infrastructure ATM est
toujours un domaine de recherches très actif. Une solution semble se dessiner au tour des
propositions de Grenville Armitage qui s’appuie sur MARS (Multicast Address Resolution

L. George
IPv6 Page 35 sur 60

Servers, RFC 2022), la redirection externe de la découverte des voisins (voir plus loin) et
NHRP (NBMA Next Hop Resolution Protocol).

Le système MARS permet d’obtenir un service multicast pour IPv4 au-dessus d’ATM au sein
d’un petit réseau (typiquement de la taille d’un LIS de classical IP ou d’un réseau virtuel :
VLAN de LANE (LAN Emulation). Il est facilement extensible à IPv6 et peut être défini pour
d’autres architectures NBMA (surtout pour un trafic restreint) et permet donc de récupérer les
fonctionnalités multicast nécessaires pour la découverte des voisins sur un petit réseau nommé
« lien logique ».

La redirection externe permet de déterminer si un nœud dans un même préfixe non


entièrement sur le lien physique est directement accessible en donnant au passage son adresse
physique. De tels voisins sont qualifiés de « temporaires » et peuvent appartenir dans ce cadre
à d’autres liens logiques (ce mécanisme est donc une optimisation du routage inter-liens
logiques).

Le protocole NHRP (NBMA Next Hop Resolution Protocol) permet de détecter et de


construire des raccourcis dans une infrastructure NBMA découpée en petites entités. Pour
IPv6 sur ATM il est utilisé entre routeurs inter-liens logiques pour détecter les raccourcis, la
redirection externe construisant les raccourcis quand l’une des extrémités au moins n’est pas
un routeur.

Les datagrammes IPv6 sont transportés dans des trames AAL5 (ATM Adaptation Layer 5) et
conformément au RFC 1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5).
Deux méthodes sont possibles pour transporter les trames AAL5 dans les VC (circuits
virtuels) suivant les possibilités offertes par l’environnement :
- Circuits dédiés
- Encapsulation LLC/SNAP

La taille maximale d’un datagramme pouvant être transmis directement par une interface
ATM (IP-MTU) est normalement de 9180 octets, la MTU de l’interface étant 9188 octets (8
octets pour l’en-tête LLC/SNAP).

C. Lien point à point, PPP (RFC 2023)


L’encapsulation est faite dans une trame « PPP Data Link Layer ». Chaque datagramme IPv6
forme une trame séparée. Le champ protocole de la trame doit être [.

Le protocole de contrôle de PPP pour IPv6 s’appelle IPV6CP. Il permet la configuration, la


validation et l’invalidation des modules IPv6 de PPP. Chaque datagramme IPV6CP est
transmis dans une trame « PPP Data Link Layer » de champ protocole [. Le protocole
IPV6CP permet de négocier deux options, la valeur de l’identifiant d’interface et la
compression.

Comme il n’existe pas d’adresse MAC IEEE 802 ou EUI-64 pour les interfaces PPP, il n’y a
pas de valeur par défaut standard. Si la machine (ou une autre interface) possède un EUI-64
ou une adresse MAC IEEE 802, on utilise l’identifiant associé. Sinon il faut fournir une
valeur (non universelle) à partir d’un numéro de série, ou même d’un générateur aléatoire.

L. George
IPv6 Page 36 sur 60

Dans tous les cas, la négociation d’identifiant d’interface de IPV6CP doit être utilisée pour
forcer l’unicité de l’identifiant.

Le MTU est variable car déterminé par la connexion PPP sous-jacente. Il doit être au moins
égal à 576.

Il faut remarquer que PPP n’a pas de notion d’adresse physique, donc l’option « adresse
physique Source/Cible » du protocole de découverte de voisin n’est pas utilisée. De même, il
n’est pas nécessaire de définir un traitement particulier pour les paquets multicast : comme sur
tout lien point à point, le multicast IPv6 est supporté sans action particulière.

Une méthode de compression des en-têtes IPv6 du même type que celle utilisée par IPv4 a été
proposée. Elle est optionnelle et son utilisation est négociée par IPV6CP.

D. Tunnels
Un tunnel est un moyen de transporter des paquets IP directement entre deux points connectés
par IP. L’extrémité émettrice du tunnel encapsule le datagramme IP dans un autre
datagramme IP et l’envoie vers l’autre extrémité du tunnel. L’extrémité réceptrice reçoit le
message, décapsule le datagramme IP et le traite. On peut voir ce mécanisme comme un lien
point à point ou un lien NBMA, selon qu’on considère des relations 2 à 2 ou un émetteur en
face du réseau Internet.

Il existe de nombreux formats de tunnels en IPv4 : celui utilisé en mobilité, celui utilisé par le
Mbone pour le multicast, le format GRE [RFC 1701]...

En IPv6, l’utilisation des en-têtes d’extension et le support du multicast en natif font que la
plupart des utilisations de tunnels par IPv4 n’ont plus de raison d’être.

Il existe cependant un usage important des tunnels dans la phase de déploiement de IPv6, tant
que la connectivité mondiale n’est pas assurée : c’est l’utilisation des tunnels IPv6 dans IPv4,
permettant de relier des réseaux IPv6 isolés à travers l’Internet IPv4. Cette approche est
utilisée de manière intensive pour réaliser le réseau 6bone.

Transport de IPv6 sur IPv4 :


Le transport des paquets IPv6 à l’intérieur de paquets IPv4 est décrit dans [RFC 1933]. Il
existe deux modes de tunnel, point à point (ou configuré) qui établit une liaison fixe entre
deux machines (en général des routeurs), et NBMA (ou automatique), qui permet à une
machine isolée d’accéder à toutes les autres machines à l’aide des adresses IPv4 compatibles.
Le MTU est variable. Une valeur possible pour un tunnel point à point est PTMU —20 où
PTMU est le « Path MTU » IPv4 entre les deux extrémités du tunnel. Il doit être au moins
égal à 576.
L’encapsulation est faite dans un paquet IPv4 de type protocole 41 (0x29). Chaque
datagramme IPv6 forme un paquet séparé. Ce paquet peut être fragmenté par IPv4.

0 8 16 24 31
4 5 0x00 longueur

L. George
IPv6 Page 37 sur 60

identificateur drap. place fragment


TTL proto = 0x29 Checksum
adr. de la source tunnel IPv4
adr de destination tunnel IPv4

En-tête et données IPv6

Le choix de l’identifiant d’interface n’est pas défini dans le RFC 1933. On peut par exemple
le dériver de l’adresse IPv4 de l’extrémité du tunnel.

Il n’y a pas d’autre paramètre à définir pour un tunnel point à point. Pour un tunnel NBMA, le
RFC 1933 ne définit pas l’option « adresse physique Source/Cible » ni le support du
multicast.

L. George
IPv6 Page 38 sur 60

V. Routage
A. Protocoles de routage
Les principes des protocoles de routage n’ont pas changé avec IPv6. Les travaux en cours
consistent uniquement à les adapter aux nouveaux formats d’adresse. Ces protocoles de
routage profitent des propriétés maintenant incluses dans la nouvelle version du protocole
IPv6 comme l’authentification ou le multicast.
Comme dans IPv4, il faut faire la distinction entre deux grandes familles de protocoles de
routage : le routage interne et externe.

B. Routage interne
Les protocoles dits de routage interne permettent une configuration automatique des tables de
routage. Les routeurs découvrent automatiquement la topologie du réseau et déterminent le
plus cours chemin pour atteindre un réseau distant. Les protocoles de routage interne
nécessitent une configuration minimale du routeur. Celui-ci doit connaître les réseaux
auxquels il est attaché.
Pour IPv4, en plus de protocoles développés par les constructeurs de routeurs, il existe deux
grandes catégories de protocoles de routage conçus par l’IETF.

1. RIPng

Les algorithmes appelés « distant vector », sont utilisés par les protocoles de routage RIP
[RFC 1058] et RIPv2 [RFC 1723].

Ils sont basés sur l’algorithme de Bellman-Ford et figurent parmi les premiers algorithmes de
routage interne utilisés dans l’Internet.

Les routeurs diffusent leurs tables de routage sur les liens auxquels ils sont connectés. Les
autres routeurs modifient une route dans leur table si la métrique reçue (dans ce cas le nombre
de routeurs à traverser pour atteindre une destination) est plus petite que celle déjà stockée
dans la table. Si une annonce de route n’est pas présente dans la table, le routeur la rajoute.
Ces modifications sont à leur tour diffusées sur les autres réseaux auxquels sont connectés les
routeurs. Elles se propagent donc sur l’ensemble du réseau. On montre que cet algorithme
converge et qu’en condition stable, aucune boucle n’est créée sur le réseau (c’est-à-dire qu’un
paquet ne sera pas transmis indéfiniment de routeur en routeur sans jamais pouvoir atteindre
sa destination).

Les tables sont émises périodiquement. Si un routeur tombe en panne ou si le lien est coupé,
les autres routeurs ne recevant plus l’information suppriment l’entrée correspondante de leur
table de routage.

RIPng est le premier protocole de routage dynamique proposé pour IPv6 [RFC 2080]. RIPng
est une simple extension à IPv6 du protocole RIPv2 d’IPv4. Il en hérite les mêmes limitations
d’utilisation. De plus, l’agrégation des routes en IPv6 pose de nouveaux problèmes qui
nécessitent de configurer précisément les routeurs.

L. George
IPv6 Page 39 sur 60

Utiliser RIPng peut sembler être un retour en arrière puisque l’IETF déconseille l’utilisation
de RIP au profit d’OSPF dans les réseaux IPv4. Pour l’instant les réseaux IPv6 ont encore une
topologie relativement simple, sur laquelle RIP est relativement bien adaptée. De plus la très
grande simplicité du protocole a permis une mise en œuvre et un déploiement rapide de
RIPng. Il permet d’attendre la définition et les mises en œuvre de protocoles de routage
intérieur plus élaborés tels OSPFng ou IS-IS. Il s’applique donc à de petits réseaux
expérimentaux. Il est fortement déconseillé de trop généraliser son utilisation.

Fonctionnement :

Le format générique des paquets RIPng est très proche de celui des paquets du protocole
RIPv2. Seule la fonction d’authentification a disparu. Elle est en effet inutile car RIPng peut
s’appuyer sur les mécanismes de sécurité IPSec disponibles en IPv6.
0 7 15 31
Commande Version Mis à zéro

Entrée 1

Entrée n

ÁCommande :
Ce champ contient : 1 pour une requête de table de routages
2 pour une réponse à une requête ou une émission périodique.

Á Version : ce champ est aujourd’hui défini à la valeur 1.

ÁEntrée : ce champ contient l’information de routage. Le nombre d’informations de routage


contenues dans un paquet RIPng dépend directement du MTU des liens utilisés. Si RIPng doit
annoncer un grand nombre de réseaux, plusieurs paquets RIPng seront nécessaires.
La structure de ce champ est la suivante :

Préfixe IPv6

marque de routage lg préfixe métrique

Les champs préfixe et longueur de préfixe décrivent les réseaux annoncés.

L. George
IPv6 Page 40 sur 60

Le champ métrique comptabilise le nombre de routeurs traversés. Pour résoudre les


problèmes de convergence (« comptage jusqu’à l’infini »), la valeur maximale de métrique
(« infini ») est 16. Cette valeur est largement suffisante pour le domaine d’application du
protocole. Le champ métrique peut donc prendre toutes les valeurs comprises entre 0 et 16.

Si le champ métrique vaut [)), le champ préfixe donne l’adresse d’un routeur (prochain
saut). Une telle entrée indique que les destinations des entrées suivantes sont accessibles par
le routeur explicitement indiqué, et non par celui envoyant le paquet RIPng (utilisation en
mode « proxy »). Dans ce cas, les champs « marque de routage » et « longueur du préfixe »
sont mis à 0.

Dans RIPv2, cette possibilité était indiquée dans chaque information de routage. Vu la
longueur des adresses IPv6, dans RIPng l’indication du prochain saut est valable pour toutes
les routes qui suivent jusqu’à la fin du paquet ou jusqu’à la prochaine entrée de ce type. Ainsi,
bien que les adresses soient quatre fois plus grandes qu’en IPv4, la taille des informations de
routage est la même que dans RIPv2.

Les paquets RIPng sont émis vers l’adresse de multicast all-rip-router )) et
encapsulés dans un paquet UDP avec le numéro de port 521.

2. OSPFng

Le deuxième protocole de routage internet, basé sur l’algorithme du plus court chemin,
s’appelle OSPF (Open Shortest Path First).

Relativement plus difficile à mettre en œuvre, il est beaucoup plus efficace dans les détections
et la suppression des boucles dans les phases transitoires. Ce protocole est basé sur plusieurs
sous-protocoles. Le premier permet une inondation fiable du réseau. Chacun des routeurs
possède alors une copie des configurations de tous les autres routeurs présents sur le réseau.
Ils peuvent simultanément calculer le plus court chemin pour aller vers l’ensemble de
destinations.

Pour réduire la durée des calculs et surtout pour éviter un recalcul complet des routes à
chaque changement de configuration, OSPF offre la possibilité de découper le réseau en aires.
Une aire principale appelée backbone doit pouvoir relier toutes les autres aires. Les réseaux
trouvés dans les aires données sont envoyés aux autres routeurs en frontière d’aires.

OSPFng a été adapté à IPv6 en remplaçant la notion de sous-réseau par celle de liens. Les
informations d’adressages ont été retirées des formats de paquets et de LSA (Link State
Advertisements) afin de rendre le cœur d’OSPF indépendant du protocole réseau et de le
restreindre au transport d’informations sur la topologie. Dans le reste d’OSPF le format des
adresses a été changé pour accepter des adresses IPv6. La notion de portée (lien, aire, ...)
utilise le mécanisme de portée d’IPv6.

Un lien supporte plusieurs instances du protocole OSPFng ce qui permet de l’utiliser plus
facilement sur des liens partagés entre plusieurs domaines de routage. OSPFng utilise des
adresses lien-locales pour l’échange de paquets OSPFng sur les liens. Le mécanisme de
sécurité a été remplacé par les facilités d’authentification et de confidentialité d’IPv6.

L. George
IPv6 Page 41 sur 60

C. Routage externe
La seconde famille de routage concerne le routage externe. Le terme externe vient du fait
qu’il s’agit d’un échange de tables de routage entre deux domaines d’administration distincts,
généralement entre un client et son fournisseur, un fournisseur et son transporteur
international ou entre fournisseurs ou transporteurs internationaux.

En IPv4 cette notion de domaine d’administration est représenté par un numéro de système
autonome (AS : Autonomous System)

Il n’est pas clair que cette notion soit encore utile en IPv6 puisque dans un plan d’adressage
hiérarchique, le préfixe peut jouer une notion équivalente au numéro d’AS.

Avec un protocole de routage externe, il ne s’agit plus de trouver la topologie du réseau, mais
d’échanger des informations d’accessibilité explicite entre routeurs configurés pour le faire.
Ceux-ci traitent les informations reçues pour éliminer celles qui ne sont pas pertinentes ou
contraires à la politique de routage définie pour le site. En effet, toute annonce de réseau par
un domaine implique qu’il accepte de router les paquets vers cette destination.

BGP-4 est le protocole de routage externe actuellement utilisé pour IPv4 (la version 4,
identique pour BGP et IP, est pure coïncidence). Dans le cas d’IPv6, deux extensions de
BGP4 ont été proposées : BGP4+ qui est un clone de BGP4 utilisant un transport TCP sur
IPv6 et des nouveaux attributs pour coder les préfixes, et BGP5 qui, de plus, permet d’avoir
des numéros de système autonome (AS) de taille variable.

Dans l’immédiat, BGP4+ s’est imposé. Peu de nouvelles possibilités ont été introduites. Les
numéros d’AS utilisés pour IPv4 servent aussi à IPv6.

Il semble que BGP4+ soit plutôt une solution à court terme pour résoudre les problèmes
pratiques de routage sur le 6bone et qu’une solution à long terme, peut-être basée sur IDRP,
reste à développer.

BGP4+ introduit deux nouveaux attributs pour transporter des informations de routages autres
que les routes unicasts IPv4, en particulier des routes multicasts (BGP4+ peut ainsi servir de
base à un routage multicast inter-domaines) et des routes pour d’autres protocoles, dont IPv6
qui est le seul réellement envisagé dans les premières propositions.

Ces nouveaux attributs permettent d’annoncer l’accessibilité ou la non-accessibilité de


préfixes (NLRI Network Layer Reachability Informations dans la terminologie des protocoles
inter-domaines). À un ensemble de NLRI est associé des attributs standard de BGP (comme le
chemin d’AS Autonomous Systems), la famille d’adresses, une sous-famille (unicast et/ou
multicast), une information sur le routeur à utiliser (next-hop) avec son adresse,
éventuellement son adresse locale au lien et une ou plusieurs adresses physiques.

D. Réseau IPv6 expérimental


1. Le réseau 6bone

L. George
IPv6 Page 42 sur 60

Le 6bone est un réseau expérimental destiné à tester les protocoles IPv6 et leur mise en
œuvre. Il a démarré officiellement le 15 juillet 1996 entre les groupes suivants : UNI-C au
Danemark, WIDE au Japon et le G6 en France. Les premières connexions se sont faites à
travers des tunnels IPv6 sur IPv4 utilisant les liaisons Internet classiques. Depuis, certains
liens IPv6 natifs ont vu le jour, mais la majorité du trafic emprunte encore ces tunnels. Le
modèle d’architecture de site choisi le plus souvent est bâti sur un réseau local IPv6 natif relié
au 6bone par un routeur/tunnelier.
Aujourd’hui, près de 200 sites sont interconnectés dans les 30 pays suivants :

AT-Austria FI-Finland NO-Norway


AU-Australia FR-France PL-Poland
BE-Belgium GB-Great Britain PT-Portugal
BG-Bulgaria HU-Hungary RO-Romania
CA-Canada IE-Ireland RU-Russian Federation
CH-Switzerland IT-Italy SE- Sweden
CN-China JP-Japan SG-Singapore
DE-Germany KR-Korea SK-Slovakia
DK-Denmark KZ-Kazakhstan TW-Taiwan
ES-Spain NL-Netherlands US-United States

En tant que réseau de test, le 6bone n’offre aucune garantie de service. Ce n’est en aucun cas
un réseau de production. Il est, par contre, d’une grande souplesse et peut être reconfiguré
assez facilement.

L. George
IPv6 Page 43 sur 60

Un certain nombre de leçons ont déjà été tirées de ces expériences. Au début, les différents
sites s’interconnectaient de façon anarchique. Très rapidement, un besoin d’organisation s’est
fait sentir pour essayer de maintenir l’accessibilité et le routage entre sites. Tant que le 6bone
n’excédait pas une dizaine de sites, un routage statique était suffisant. Les choses sont vite
devenues ingérables et la nécessité d’un protocole de routage dynamique s’est fait sentir. En
décembre 1996 on a déployé les premières versions de RIPng. Cela a permis d’étendre le
6bone jusqu’à une centaine de sites. Cependant, RIPng est un protocole de routage intérieur et
souffre des mêmes problèmes de convergence que RIP pour IPv4. Dès avril 1997, le 6bone
s’est rendu à la nécessité d’avoir un protocole de routage externe. BGP4+ s’est vite imposé et
plusieurs implémentations ont rapidement été disponibles. En août 1997, la décision a été
prise d’imposer BGP4+ pour les nœuds principaux du 6bone chargés d’assurer le routage
global.

La notion d’adressage s’est révélée très importante. Les adresses de type IPv4-compatible se
sont vite montrées d’un intérêt très limité et leur utilisation a été restreinte aux seuls tunnels.
Le plan d’adressage prestataire décrit dans le RFC 1897 a été testé dès le début et a vite
montré ses limites. Depuis le 1er octobre 1997, le plan d’adressage agrégé est
progressivement mis en place. Une tâche importante est désormais de le tester et d’essayer
d’en découvrir les cas limites pour le valider. À cette fin, un seul préfixe TLA, ))(,
est attribué pour l’ensemble du 6bone de façon à ne pas gaspiller trop d’espace d’adressage.
Ce TLA est découpé une première fois en NLA1, préfixes de longueur 24
())([\) pour simuler l’attribution de TLA. Ces préfixes sont appelés pTLA
(pour « pseudo-TLA »). Ils sont attribués aux sites qui en font la demande et qui s’engagent à
agréger ensuite derrière eux d’autres sites en leur délégant à leur tour des pNLA1s (en fait,
des NLA2s) à l’intérieur de leur pTLA.

2. Le G6bone

L. George
IPv6 Page 44 sur 60

Le G6bone, réseau IPv6 du G6, est un exemple de mise en œuvre de la politique d’adressage
du 6bone. Il s’est vu attribué le pTLA ))(. Le G6 a proposé un plan
d’adressage national basé sur un certain nombre de points d’interconnexion appelés hubs. On
distingue trois types de hubs : les hubs régionaux, les hubs d’organisation et le hub national.

Les hubs régionaux interconnectent les sites expérimentaux « proches » d’eux. Cette notion
de proximité peut être variable d’un hub à l’autre, elle est définie dans la charte de chacun
d’entre eux. Les hubs d’organisation sont prévus pour permettre à des organismes multi-sites
tels l’INRIA ou le CNET de partager un préfixe commun entre leurs différents sites. Le hub
national abrite les liaisons internationales et connecte les sites distants n’ayant pu
s’interconnecter directement ailleurs. L’ensemble des hubs régionaux et d’organisation sont
connectés au hub national.

Chaque hub a reçu une délégation de pNLA1 de 32 bits, c’est-à-dire qu’il gère un préfixe de
type ))([\; par exemple, le hub Grenoblois gère le préfixe ))(
et le hub Ile de France ))(. Chaque hub a ensuite la charge de définir un
redécoupage de son pNLA1 comme il l’estime nécessaire, par exemple en allouant un pNLA2
avec un préfixe de longueur 40 à un sous-hub ou en allouant un préfixe de longueur 48 à un
site. Il faut noter que ces délégations successives ne sont pas nécessairement faites sur des
frontières d’octets : on peut très bien décider d’allouer des préfixes de longueur 37, 38 ou 39.

Les sites feuilles se connectent au hub de leur choix et obtiennent un préfixe de longueur 48
de celui-ci.

Les interconnexions sont en 1997 réalisées par des tunnels IPv6 sur IPv4 qui utilisent dans la
majorité des cas les infrastructures du réseau de la recherche Rénater. L’un des projets du G6
pour 1998 est de faire évoluer ce réseau G6bone en utilisant des liens IPv6 natifs.

L. George
IPv6 Page 45 sur 60

VI. La sécurité [RFC 1752]


Dans le domaine de la sécurité, IPv6 doit arriver à rendre deux services :
- Intégrer un système d'authentification de l'utilisateur et garantir l'intégrité des données.
- Offrir un système de cryptage applicable soit à la totalité du datagramme IP, soit à
l'unité des données du niveau 4 transport.

Ces systèmes, nous le verrons, doivent être suffisamment décorrélés des algorithmes
employés, afin que l'armée ou l'industrie puisse les mettre en œuvre facilement.

Il semble que les groupes de travail se soient accordés sur un certain nombre de points tels
que la séparation du moyen d'authentification de celui du cryptage des informations.
Clairement, une infrastructure de gestion des clés est requise afin de rendre possible
l'utilisation d'en-têtes d'authentification et de cryptage. Cependant, cet aspect n'est pas encore
réellement au point d'autant plus que l'effet pervers de ces techniques de sécurité est l'ajout de
coûts supplémentaires et la baisse des performances du système.

Avant d'étudier les différents mécanismes de sécurité mis en œuvre, il convient de définir un
certain nombre de concepts.

A. Quelques définitions
L’authentification : Elle permet de savoir si la donnée reçue est la même que celle envoyée et,
de la même façon, si le demandeur désiré est bien identifié.

L'intégrité : Elle assure la bonne transmission de la donnée, de sa source à sa destination sans


aucune altération intermédiaire.

La confidentialité : Elle garde les communications confidentielles afin que seuls les
participants puissent identifier ce qui a bien été envoyé.

Le cryptage : Il s'agit d'un mécanisme communément utilisé pour permettre la confidentialité


des informations.

SAID : ou encore « Security Association Identifier »

Security Association : L'ensemble des informations de sécurité relatives à la connexion d'un


réseau donné ou à un ensemble de connexions ; ce qui inclue des clés de cryptage, des clés de
durée de vie, des algorithmes, des degrés de sensibilité (non-classé, secret, propriétaire), mais
aussi des services de sécurité (authentication-only, Transport-Mode Encryption, IP-Mode
Encryption) ou toutes les autres possibilités envisageables.

L'analyse du trafic : Elle correspond à une sorte d'attaque du réseau où l'adversaire est capable
de faire des déductions sur le réseau lui-même grâce à l'analyse des données repérées sur le
trafic (telles que la fréquence de transmission, qui parle à qui, la taille des paquets, le Flow
IDentifier utilisé, etc.).

L. George
IPv6 Page 46 sur 60

B. Les mécanismes de sécurité dans IPv6


Le premier objectif est d'obtenir des mécanismes de sécurité sûrs et disponibles pour tous les
utilisateurs qui le désirent. Les algorithmes développés pour ces fonctionnalités ne doivent,
bien entendu, pas affecter les autres aspects de l'implémentation IP.
Il existe deux mécanismes de sécurité dans IPv6. Le premier est le mécanisme de l'en-tête
d'authentification (Authentication Header) ; le second, une technique d'encapsulation affectée
à la sécurité appelée ESP (Encapsulating Security Payload) permettant l'intégrité,
l'authentification et la confidentialité. Cependant, les mécanismes de sécurité IPv6 ne sont pas
efficaces face à des attaques de type analyse du trafic, pour le moment.

1. Le mécanisme de l'en-tête d'authentification (Authentication Header)

L’en-tête d'authentification IPv6 cherche à rendre possibles l'intégrité et l'authentification des


datagrammes IPv6. Ceci est obtenu par la mise en place d'une fonction d'authentification du
cryptage sur le datagramme IPv6 ainsi que l'utilisation d'une clé secrète d'authentification.
L'utilisateur qui émet inclut des données d'authentification dans les paquets IPv6 à traiter ;
quant à l'usager qui les reçoit, il vérifie la justesse des données d'authentification. Certains
champs de l'en-tête, qui évoluent lors de la transition (cas du champ Hop Limit), sont omis
lors de l'authentification. Cependant, cette omission n'a pas de véritables conséquences sur la
sécurité elle-même. La non-répudiation peut devenir nécessaire pour certains algorithmes
d'authentification utilisant l'en-tête d'authentification (par exemple, les algorithmes
asymétriques lorsque les clés de l'émetteur et du récepteur sont utilisées lors de la procédure
de calcul de l'authentification).
La confidentialité et la protection de l'analyse du trafic ne sont pas traitées par le mécanisme
de l'en-tête d'authentification.
Ainsi, les informations d'authentification sont analysées à partir des champs du datagramme
IPv6 qui n'évoluent pas durant son transfert de la source à la destination. Tous les éléments
(en-têtes, données, etc.) sont intégrés à l'analyse. La seule exception concerne certains champs
comme le « nombre de saut » (en-tête IPv6) ou l’« adresse suivante » (en-tête de routage
IPv6) qui sont omis.
En outre, il est fort probable que le mécanisme de l'en-tête d'authentification risque d'accroître
les coûts du processus IPv6 ainsi que l'attente de la communication.
Enfin, le mécanisme de l'en-tête d'authentification apporte une véritable sécurité dans
l'Internet sans affecter l'exportabilité des données ni augmenter trop significativement les
coûts d'implémentation. Il est, bien entendu, fortement recommandé d'utiliser ce mécanisme
de sécurité de l'origine à la destination finale.
Toutes les stations de travail IPv6-only doivent implémenter la technique de l'en-tête
d'authentification avec au minimum l'algorithme MD5 utilisant une clé de 128 bits sachant
que d'autres algorithmes pourront être implémentés.
Nous ne développerons pas davantage cette technique du fait de l'absence actuelle d'une
documentation publique et détaillée sur ce problème. En outre, nous avons présenté l'en-tête
d'authentification précédemment (cf. V.F). Un autre mécanisme de sécurité est proposé avec
le système ESP.

2. La technique ESP (Encapsulating Security Payload)

L. George
IPv6 Page 47 sur 60

ESP (ou l’en-tête de confidentialité) pour IPv6 permet d'apporter l'intégrité, l'authentification
et la confidentialité dans les datagrammes IPv6. Ceci s'obtient soit par l'encapsulation d'un
datagramme IPv6 dans son intégralité, soit par le cryptage de la majorité des composants ESP
au niveau de l'en-tête IPv6 sachant que la partie non codée de l'en-tête est utilisée afin de
transporter les données protégées à travers le réseau. Le destinataire du datagramme enlève, se
débarrasse de l'en-tête et des options IPv6 non codées, décrypte les éléments ESP, traite puis
retire les en-têtes ESP ; enfin, il obtient le datagramme IPv6 d'origine décodé ou la donnée de
spécification normale du protocole IPv6.

Description des modèles ESP :


Il existe deux modèles ESP. Le premier, connu comme un modèle IP (IP-mode), encapsule le
datagramme IP au sein de l'en-tête ESP. Le second modèle ou Transport-mode, encapsule
généralement une structure UDP ou TCP dans IP et non l'en-tête IPv6.

Utilisation d’ESP :
ESP évolue soit entre deux stations de travail, soit entre une station et un gateway (passerelle)
de sécurité, soit encore entre deux gateways de sécurité. Les gateways de sécurité permettent
à des réseaux correctement reliés à ces derniers de ne pas se préoccuper du cryptage et d'éviter
ainsi l'accroissement des coûts monétaires et la baisse des performances dus au cryptage tout
en bénéficiant de la fonction de confidentialité.
Lorsque les stations de travail implémentent directement ESP sans l'intermédiaire des
gateways de sécurité, il leur est alors possible d'utiliser le Transport-mode. Ce mode réduit à
la fois la largeur de bande consommée et le coût du protocole pour l'utilisateur qui n'a pas
besoin de garder confidentielle l'intégralité du datagramme IPv6.

Les impacts d’ESP sur la performance :


Le mécanisme ESP a des impacts notables sur les performances du réseau. En effet, la mise
en œuvre du protocole s'avère plus complexe si la technique ESP est utilisée dans la mesure
où elle requiert davantage de temps et de puissance de la part processus.
L'accroissement du retard est dû au cryptage et au décryptage de chaque datagramme IPv6
contenant ESP. Les conséquences relatives au coût sont variables selon les spécificités de
l'implémentation telles que l'algorithme de cryptage utilisé, la taille de la clé, etc. Pour ces
deux raisons, il est probable que les utilisateurs préféreront utiliser le mécanisme de l'en-tête
d'authentification (Header Authentication) à la place de la technique ESP.
En outre, afin d'assurer l'interopérabilité au sein du monde Internet, toutes les
implémentations ESP pour IPv6 doivent accepter l'utilisation de Data Encryption Standard
(DES) dans le mode Clipher-Block Chaining (CBC) ; cependant, d'autres modes et
algorithmes peuvent être rajoutés.
Nous avons proposé une présentation de l'en-tête de confidentialité (technique ESP)
précédemment (cf. V.G)

3. La combinaison des mécanismes de sécurité

Il est possible de combiner à la fois les mécanismes Authentication Header IPv6 et ESP pour
IPv6 afin d'obtenir le niveau de sécurité désiré.
La technique de l'en-tête d'authentification permet toujours l'intégrité et l'authentification ainsi
que la non-répudiation en utilisant certains algorithmes (RSA).
Le mécanisme ESP fournit toujours l'intégrité et la confidentialité mais aussi l'authentification
via des algorithmes spécifiques de cryptage.

L. George
IPv6 Page 48 sur 60

Ainsi, le mélange des deux mécanismes permet de profiter véritablement de tous les éléments
de sécurité : intégrité, authentification, non-répudiation et confidentialité.
D'autres mécanismes de sécurité permettent aussi de se protéger contre l'analyse de trafic, il
faut les implémenter au niveau de la couche IP.

C. La gestion des clés (Key Management)


Le protocole de gestion des clés couplé à d'autres mécanismes de sécurité via SAID peut être
utilisé pour IPv6. IPv6 n'est pas destiné à fournir une gestion des clés de type « in-band », où
les données de gestion des clés sont portées par un en-tête IPv6 spécifique. En revanche, IPv6
utilisera dans un premier temps une gestion des clés de type « out-of-band » où les données de
gestion des clés sont portées par un protocole de couche supérieure tel que UDP ou TCP sur
un numéro de port spécifique.
De manière générale, ceci permet le découpage du mécanisme de gestion des clés pour
d'autres systèmes de sécurité ainsi que la substitution de nouvelles méthodes de gestion des
clés (à la place des anciennes) sans avoir à modifier tous les autres outils de sécurité.
Nous allons brièvement explorer les techniques de gestion des clés.

1. La distribution d'une clé manuelle

La forme la plus simple de gestion des clés est la gestion manuelle des clés où un individu
configure manuellement chaque système avec sa propre clé mais aussi les clés des autres
systèmes de communication. Ceci s'avère relativement pratique dans un environnement
statique et de petite taille. En prenant l'exemple d'un environnement réseau de type LAN, au
sein d'un simple domaine administratif, il est pratique de configurer les clés de chaque routeur
de telle sorte que les données routées puissent être protégées et qu'il soit possible de réduire le
risque d'intrusions étrangères au sein d'un routeur. Cependant, ce n'est pas une approche
viable à moyen ou long terme.

2. La distribution d'une clé automatique

Le déploiement et l'utilisation des fonctions de sécurité dans IPv6 nécessitent un protocole de


gestion des clés au standard Internet. A l'origine, un tel protocole devait proposer une gamme
de services dans le monde Internet et pas seulement se réserver à la sécurité dans IPv6. Il
existe des travaux en cours afin d'ajouter des clés signées sur des stations de travail via DNS ;
les clés DNS permettant d'authentifier les messages de gestion des clés par rapport aux autres
éléments de la gestion des clés utilisant un algorithme asymétrique.
Il existe deux approches de la technique de clé (keying) pour IPv6. La première approche
appelée « host-to-host keying » autorise tous les utilisateurs de la station 1 puissent partager la
même clé sur le trafic destiné à tous les utilisateurs de la station 2. La seconde, appelée « user-
to-user keying », laisse la possibilité à l'utilisateur A sur la station 1 d'avoir une clé de session
unique avec l'utilisateur B sur la station 2 qui ne soit pas partagée avec les autres utilisateurs
de station 1.
Lorsque l'approche « host-to-host keying » est utilisée et que des utilisateurs mutuellement
suspicieux sont présents, alors il est possible pour l'utilisateur A de déterminer la clé « host-
to-host » via des méthodes comme l'attaque Chosen Plaintext. Si un utilisateur A a obtenu une
clé « impropre » alors il peut lire le trafic crypté de l'utilisateur B voire le falsifier. Dans le cas

L. George
IPv6 Page 49 sur 60

où l'approche « user-to-user keying » est appliquée, le type d'attaque précédent est impossible.
C'est donc cette dernière technique qu'il convient d'implémenter sur IPv6.
Enfin, il convient de signaler qu'une « Multicast Key Distribution » est en cours d'élaboration
pour IPv6.
A l'heure actuelle, de nombreux travaux sur IPv6 sont en cours d'élaboration, nous pouvons
cependant déjà signaler la présence de trois notions présentes dans IPv6 et pour lesquelles leur
normalisation et admission définitives ne font aucun doute, à savoir : Authentication Header,
Encapsulating Security Payload, Key Management.

D. L'utilisation des mécanismes de sécurité dans IPv6


Cet aspect sur la sécurité a pour principal objectif de donner un aperçu des différents
mécanismes assurant la réduction des risques dans IPv6.

1. Les « Firewalls »

Les Firewalls, absents dans la version actuelle d'Internet mais utilisés dans IPv6, vont
permettre de corriger les suites d'en-têtes et de déterminer le protocole de transport (UDP ou
TCP) ainsi que le numéro de port de ce protocole. La performance des Firewalls dans IPv6 ne
devrait pas en être trop affectée dans la mesure où le format des en-têtes IPv6 facilite la
procédure de correction.
Les Firewalls utilisent le mécanisme de l'Authentication Header pour s'assurer
l'authentification et la justesse des données utilisées pour les décisions de contrôle d'accès à
savoir la source, la destination, le protocole de transport, le numéro de port. Cette
authentification est impossible dans IPv4.
Les organisations disposant de plusieurs sites interconnectés utilisant les services
commerciaux proposés par IP peuvent sélectionner un Firewall crypté. Par exemple, si un
Firewall crypté est placé entre la Société A et le fournisseur du service commercial IP, le
Firewall fournit alors un tunnel crypté au sein de tous les sites de la Société A. Il lui est ainsi
possible de crypter tout le trafic entre elle et ses fournisseurs, ses clients ou des tiers. Une telle
pratique permet de protéger facilement le trafic d'un grand nombre d'organisations de type
gouvernemental par exemple qui peuvent même mettre en œuvre un mécanisme de « fully
encrypting Firewall » autorisant aussi bien un filtrage du trafic décrypté qu'un cryptage des
paquets IP.

2. La protection de la Qualité de Service (QoS)

Le mécanisme de l'Authentication Header, utilisé avec la méthode de gestion des clés


appropriée, permet d'authentifier les paquets, comme nous l'avons évoqué précédemment. Le
champ Flow Identifier dans IPv6 peut agir comme un Low-Level Identifier (LLID) ; par
conséquent, la classification du paquet au sein des routeurs devient simple si le routeur est
fourni avec la clé appropriée. Pour des raisons de performance, les routeurs authentifient des
groupes de paquets.
Ainsi, la qualité de service fournie est obtenue par l'utilisation du champ Flow ID conjointe à
celle d'un protocole de réservation de ressources (tel que RSVP). Ainsi, la classification des
paquets authentifiés s'obtient en s'assurant que chaque paquet reçoive bien la manipulation
appropriée et correcte au sein des routeurs concernés.

L. George
IPv6 Page 50 sur 60

3. Des réseaux compartimentés ou à niveau multiple (Multi-level)

Un réseau « multi-level secure » (MLS) est un réseau unique utilisé pour communiquer des
données selon différents degrés (non-classifié ou secret). De nombreux gouvernements
trouvent beaucoup d'intérêt dans l'architecture réseau MLS. IPv6 devrait supporter ce type de
structure. MLS nécessite l'utilisation des Mandatory Access Controls (MAC) que des
utilisateurs normaux sont incapables de contrôler ou de violer.
Le mécanisme de l'Authentication Header peut être utilisé aussi bien pour authentifier
plusieurs stations de travail dans un niveau unique du réseau que pour garantir les décisions
MAC dans un réseau à niveau multiple. Si les étiquettes IP sont utilisées et la confidentialité
considérée comme non obligatoire au sein d'un environnement opérationnel particulier, le
mécanisme de l'Authentication Header permet l'authentification du paquet dans son
intégralité, incluant un cryptage obligatoire du degré de sensibilité (non-classifié ou secret) de
l'en-tête IPv6 et des données de l'utilisateur.
La technique ESP peut être combinée avec des politiques de clé appropriées pour garantir un
réseau « multi-level secure » complet ainsi qu'un ensemble d'algorithmes appropriés. Dans ce
cas, chaque clé doit être utilisée pour un degré de sensibilité et un compartiment précis. Par
exemple, la clé A peut être utilisée pour des paquets non-classifiés ; la clé B, pour des paquets
secrets pour un trafic sans compartiment, etc.
Le cryptage est une technique très pratique et souhaitable même dans un environnement bien
protégé. L'algorithme de cryptage au standard Internet devrait être utilisable via une gestion
des clés appropriée, afin de fournir de véritables Discretionary Access Controls (DAC)
corrélés au degré de sensibilité des étiquettes, au-delà des seules possibilités MAC offertes
pour le moment.
Le développement d'un mécanisme de cryptage complet devrait être disponible pour toutes les
communications futures.
Cet exposé concernant la sécurité dans IPv6 est incomplet dans la mesure où cet aspect fait
encore l'objet de travaux en cours.

E. La prise en compte des autres éléments relatifs à la sécurité


De manière générale, il faut retenir pour l'instant que la qualité de service fournie par les
nouveaux mécanismes développés dans IPv6 dépend totalement de l'efficacité des algorithmes
de cryptage implémentés, de la justesse de l'implémentation de ces algorithmes, des clés à
utiliser, de la sécurité du protocole de gestion des clés, de l'implémentation d'IPv6 et
particulièrement de ses mécanismes de sécurité.

En outre, certains aspects propres à la sécurité (comme la protection contre l'analyse du trafic)
ne sont pas encore fournis par les mécaniques abordés précédemment. L'utilisateur doit donc
faire preuve d'une extrême vigilance.

Enfin, quelques applications (comme le courrier électronique) nécessitent des applications de


protection et de sécurité spécifiques qui ne sont pas du ressort des techniques de sécurité
propres à IPv6 mais pour lesquels des RFC seront entièrement consacrées.
Il nous semble désormais intéressant de nous préoccuper d'un aspect tout autant novateur dans
IPv6 que la sécurité, à savoir la mobilité.

L. George
IPv6 Page 51 sur 60

VII. Mobilité dans IPv6


[RFC 1752]

Le concept de mobilité signifie, dans le cas présent, la séparation des identificateurs et des
adresses, ces deux éléments possédant un format similaire. L'identificateur d'un nœud mobile
ne change jamais quelque soit ses déplacements tandis que son adresse est spécifique à son
point de rattachement à Internet. L'adresse est seulement utilisée pour le routage des paquets
et non pour l'identification du nœud à l'inverse de l'identificateur qui peut même
éventuellement servir d'adresse par défaut.

Deux options ont été rajoutées dans les options de l'en-tête de type Hop-by-Hop afin de rendre
possible la mobilité. L'une est utilisée pour la communication de données et l'autre pour le
contrôle.

TCP/UDP identifie un nœud par son identificateur et non son adresse. Afin d'optimiser le
routage, chaque nœud dispose d'une partie cachée ou Address Mapping Table (AMT). IPv6
résout le problème de l'identificateur et de l'adresse en utilisant AMT, puis en renvoyant le
paquet avec la prise en compte de son adresse complète.

Les entrées AMT sont créées puis mises à jour en fonction de la réception ou de l'envoi de
paquets selon les options de mobilité choisies après, bien entendu, l'authentification du
paquet.

Cependant, avant d'aborder les différentes techniques développées pour la mobilité, il


convient de définir un certain nombre de concepts.

A. Quelques définitions
Un nœud : Il s'agit d'un terme général utilisé pour évoquer à la fois une station de travail et/ou
un routeur.

Un nœud mobile : C'est un nœud qui a la possibilité de changer de point de rattachement sur
l'Internet.

Une adresse : C'est un numéro qui spécifie le point de rattachement à l'Internet. Une adresse
est attribuée à chaque interface réseau d'un nœud. Nous avons vu que, pour IPv6, la taille
d'une adresse est de 128 bits. L'adresse d'une interface change lorsque le nœud se déplace sur
un autre réseau.

Un identificateur : C'est un numéro attribué à un nœud unique. Chaque nœud dispose de son
propre identificateur indépendamment du nombre d'interfaces réseaux dont il bénéficie. Non
seulement un identificateur est unique et définitif quel que soit le nœud de rattachement à
l'Internet, mais il bénéficie du même format qu'une adresse classique ce qui lui permet
éventuellement de se substituer à une adresse.

Un réseau maison (home subnet) : Il s'agit du réseau indiqué par l'identificateur d'un nœud
mobile.

L. George
IPv6 Page 52 sur 60

Une résolution d'adresse (address resolution) : C'est une fonction qui oriente l'identificateur
vers l'adresse correspondante.

Un « résolveur » d'adresse (address resolver) : C'est nœud qui utilise une résolution d'adresse.
Il existe deux types de résolveurs d'adresses pour un nœud mobile.
- le résolveur primaire : un résolveur d'adresse est connecté au réseau maison d'un nœud
mobile. Un nœud mobile indique périodiquement le(s) résolveur(s) primaire(s) de son
identificateur ainsi que son adresse courante.
- le résolveur temporaire : dans le cas d'un résolveur d'adresse non connecté au réseau
maison d'un nœud mobile, un résolveur temporaire crée et met à jour ses paquets
AMT reçus ou envoyés (avec l'option mobile dans l'en-tête).

Address Mapping Table (AMT) : Une table constituée d'entrées pour chacune desquelles il y a
l'information de routage entre l'identificateur et l'adresse. Chaque nœud doit disposer d'une
AMT pour la résolution d'adresse.

Après ce développement sur la terminologie spécifique à la mobilité, nous sommes en mesure


d'aborder la description des formats spécifiques à la mobilité.

B. Les formats d’en-tête pour l'option de mobilité


Deux options pour la mobilité sont possibles via les propriétés de l'en-tête IPv6 Hop-by-Hop.
La raison principale pour laquelle ces options sont inclues dans l'en-tête IPv6 Hop-by-Hop est
la possibilité de créer et de mettre à jour des entrées AMT sur chaque nœud le long du chemin
suivi par le paquet envoyé.

1. L'option de mobilité pour les données utilisateur

ÁOption Type : Ce champ prend pour valeur 0x2?, ce qui signifie que cette option ne relève
pas de la propriété d'évaluation de l'intégrité obtenue via l'en-tête d'authentification dans la
mesure où les données de l'option peuvent évoluer.

ÁOption Data Length : La longueur est de 64 octets.

L. George
IPv6 Page 53 sur 60

Á Source Identifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud
source sans considérer sa localisation (c'est-à-dire en-dehors de l'adresse source de l'en-tête
IPv6).

ÁSource Address Version : Ce champ dont la taille est de 32 bits signale le numéro de version
des identificateurs et adresses sources. Cette information doit être invariablement incrémentée
à chaque nouvelle adresse attribuée.

Á Holding Time : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en
secondes, durant lequel un nœud conserve l'entrée AMT du nœud source du paquet considéré.

ÁTimestamp : Ce champ dont la taille est de 32 bits signale le temps nécessaire au nœud, en
secondes, pour transmettre un paquet.

ÁAuthentication Data : Ce champ dont la taille est de 128 bits authentifie, en fournissant le
résultat de l'évaluation de l'algorithme MD5, le nœud source du paquet et garantie l'intégrité
de l'option de mobilité pour les données.

ÁDestination Identifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud
de destination final sans se préoccuper de sa localisation (c'est-à-dire en-dehors de l'adresse
destination de l'en-tête IPv6).

ÁDestination Address Version : Ce champ dont la taille est de 32 bits signale le numéro de
version des identificateurs et adresses destinations.

2. L'option de mobilité pour le contrôle

ÁOption Type : Ce champ prend pour valeur 0x0?, ce qui signifie que cette option relève de
la propriété d'évaluation de l'intégrité obtenue via l'en-tête d'authentification.

ÁOption Data Length : La longueur est de 108 octets.

L. George
IPv6 Page 54 sur 60

ÁIdentifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud pour lequel
l'entrée AMT doit être créée ou mise à jour.

ÁAddress : Ce champ identifie le nœud pour lequel l'entrée AMT doit être créée ou mise à
jour.

ÁAddress Version : Ce champ dont la taille est de 32 bits signale le numéro de version des
identificateurs et adresses.

Á Holding Time : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en
secondes, durant lequel un nœud conserve l'entrée AMT du nœud désigné par le champ
identificateur (Identifier).

ÁTimestamp : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en secondes,
au nœud source pour transmettre un paquet. Ce champ permet aussi de prévenir les attaques
récidivistes.

Á Authentication Data : Ce champ authentifie, en fournissant le résultat de l'évaluation de


l'algorithme MD5 et/ou la signature digitale RSA, et garantie l'intégrité de l'option de mobilité
pour les données.

Quelques explications s'avèrent utiles afin de mieux appréhender le mécanisme AMT.

C. Le format d'entrée AMT

ÁStatus : Il s'agit des drapeaux que montre le statut de l'entrée AMT. Les trois drapeaux sont
les suivants :
- invalid : l'entrée AMT est invalide si le drapeau est activé « on », la raison pour
laquelle cette entrée AMT est invalide est de détecter d'une entrée AMT sur un autre
nœud ;
- home : le nœud qui permet l'entrée AMT est connecté au réseau maison du nœud
désigné par cette entrée AMT.
- local : le nœud désigné par l'entrée AMT est connecté au même réseau si le drapeau
est activé « on ».

L. George
IPv6 Page 55 sur 60

ÁIdentifier : Ce champ représente la clé de l'entrée.

ÁAddress : L'adresse courante du nœud désigné par le champ Identifier.

ÁAddress Version : Le numéro de version de l'identificateur et de l'adresse.

Á Holding Time : La valeur de ce champ est périodiquement décrémentée. L'entrée est


détruite lorsque la valeur arrive à zéro.

Á Timestamp : Ce champ permet de mesurer le temps nécessaire à l'option de mobilité qui


crée et met à jour l'entrée.

ÁAuthentification Data : Ce champ permet d'authentifier les données de l'option de mobilité


qui crée et de met à jour l'entrée.

D. Les méthodes d'authentification


Les options de mobilité utilisent deux méthodes d'authentification, « keyed MD5 » et « RSA
digital signature ».

Keyed MD5 est utilisée dans le cadre de l'authentification end-to-end d'un paquet via l'option
de mobilité pour les données utilisateurs ce qui nécessite de partager une clé secrète commune
entre le nœud authentifiant et le nœud authentifié. La taille de la clé est de 128 bits, les calculs
couvrent les champs suivants : Source Address (dans l'en-tête IPv6), Source Identifier, Source
Address Version, Holding Time et Timestamp.

La méthode RSA digital signature est utilisée pour l'authentification de nœuds intermédiaires
utilisés pour l'envoi de paquets avec l'option de mobilité pour le contrôle. La taille de la clé
est de 512 bits, les calculs couvrent les champs suivants : Identifier, Address, Address
Version, Holding Time et Timestamp.

E. La connexion à un réseau
Lorsqu'un nœud est connecté à un réseau, il lui est attribué une adresse IPv6 temporaire dans
le sous réseau par le mécanisme d'auto-configuration d'adresses. A l'inverse, l'identificateur du
nœud mobile ne change pas. Le nœud mobile transfert un paquet IPv6 via l'option de mobilité
pour le contrôle située dans son réseau maison. Lors de toute cette procédure, les entrées
AMT pour le nœud mobile sont créées et mises à jour à la fois sur les nœuds intermédiaires et
ceux du réseau maison.

1. Les procédures utilisées sur le nœud mobile

Lorsqu'un nœud mobile est connecté à un réseau, il transmet un paquet IPv6 via l'option de
mobilité pour le contrôle à son réseau maison. Chaque champ de ce réseau est rempli de la
manière suivante.

L. George
IPv6 Page 56 sur 60

Identifier : l'identificateur du nœud mobile.


Address : l'adresse temporaire IPv6 de l'interface utilisée.
Address Version : le numéro de version de l'adresse et de l'identificateur IPv6 temporaires.
Holding Time : le temps, en secondes, pour lequel l'entrée AMT du nœud mobile doit être
conservé.
Timestamp : l'instant auquel le paquet est transmis.
Authentication Data : la signature digitale RSA qui couvre les cinq champs précédents.

2. Les procédures utilisées sur un noeud intermédiaire

Lorsqu'un nœud intermédiaire reçoit un paquet via l'option de mobilité pour le contrôle, il
peut exécuter les procédures suivantes après ou avant l'envoi des paquets.

Authentification : le nœud intermédiaire authentifie le paquet s'il connaît la clé publique du


nœud mobile spécifié par le champ Identifier de l'option de mobilité. Si l'authentification
réussit alors la modification AMT est exécutée.

Modification AMT : le nœud intermédiaire crée une entrée AMT pour le nœud mobile
spécifié par le champ Identifier de l'option de mobilité s'il ne la connaît pas déjà ; ou bien, il
met à jour l'entrée AMT existante à condition qu'elle ne soit pas obsolète (le numéro de
l'option de mobilité ne doit jamais être plus grand que celui de l'entrée AMT).

Dans le cas où l'entrée AMT est obsolète, le nœud intermédiaire peut diffuser le paquet reçu à
toutes ses interfaces.

3. Les procédures utilisées sur un nœud situé à la frontière (Boundary Node)


du réseau maison

Lorsqu'un paquet avec une option de mobilité pour le contrôle est reçu, un nœud situé à la
frontière du réseau maison du nœud mobile désigné par le champ Identifier de l'option
exécute les procédures d'authentification et de modification AMT, puis diffuse le paquet dans
le réseau maison s'il s'agit d'un réseau de type diffusion. Si le nœud situé à la frontière dispose
d'une entrée AMT obsolète, il transmet alors le paquet à l'adresse désignée par le champ
Address de l'entrée AMT obsolète.

F. La communication des données


Dans les données de communication, l'option de mobilité pour les données des utilisateurs est
intégrée dans chaque paquet IPv6. TCP/UDP désigne le nœud de destination avec
l'identificateur. La résolution d'adresse pour le nœud de destination est exécutée soit au niveau
du nœud source, soit au niveau du nœud intermédiaire, ou bien au niveau d'un nœud localisé
au sein du réseau maison du nœud de destination, puis le paquet est routé vers le nœud de
destination.

1. Les procédures appliquées au noeud source

L. George
IPv6 Page 57 sur 60

Le nœud source crée un paquet IPv6 via l'option de mobilité pour les données des utilisateurs.
Dans l'option, les champs relatifs au nœud source (Source Identifier, Source Address Version,
Holding Time et Timestamp) sont remplis avec les valeurs appropriées, puis les données
d'authentification sont calculées et attribuées au champ Authentication Data.

Une requête de transmission de la couche supérieure précise le nœud de destination et son


identificateur (champ Destination Identifier) mais pas l'adresse. Le nœud source essaie de
résoudre la correspondance de l'identificateur et de l'adresse grâce à la technique AMT. Si
l'entrée AMT pour le nœud de destination existe, l'adresse et son numéro de version sont
attribués respectivement au champ de destination de l'en-tête IPv6 ainsi qu'au champ du
numéro de version de l'adresse de destination de l'option.

2. Les procédures appliquées au nœud intermédiaire

Il existe deux procédures dans le cas d'un nœud intermédiaire avec l'option de mobilité des
données des utilisateurs, à savoir la modification AMT et la résolution d'adresse.

Lors de la modification AMT, l'entrée AMT pour le nœud mobile désigné par le champ
Source Identifier de l'option peut être créée ou modifiée. Dans un premier temps, le nœud
intermédiaire authentifie le paquet si ce dernier connaît la clé commune du nœud source. Si
l'authentification réussit, les procédures suivantes sont exécutées. Si une entrée AMT pour le
nœud mobile désigné par le champ Source Identifier de l'option n'existe pas, elle est alors
créée. S'il n'y a pas d'entrée AMT (information obsolète), alors des modifications sont
réalisées en accord avec les valeurs de l'option.

Dans le cas de la résolution d'adresse, l'adresse de destination dans l'en-tête IPv6 et le numéro
de version de l'adresse de destination de l'option peuvent être modifiés. Si l'entrée AMT pour
le nœud de destination du paquet existe, alors il faut comparer le numéro de version de
l'adresse de destination du paquet avec le numéro de version de l'adresse de l'entrée. Si
l'entrée AMT dispose d'informations plus récentes, alors le champ Destination Address de
l'en-tête IPv6 et le numéro de version de l'adresse de destination de l'option sont modifiés
conformément à l'entrée.

3. Les procédures appliquées au nœud de destination

Le nœud de destination exécute la procédure de modification AMT décrite ci-dessus puis la


signale à la couche supérieure de réception du paquet avec l'identificateur du nœud source
mais pas son adresse.

L. George
IPv6 Page 58 sur 60

CONCLUSION
Lors de sa conception, IPv6 devait logiquement être considéré comme l'évolution normale de
l'Internet facilitée par son entière compatibilité avec IPv4 et, par conséquent connaître un
déploiement stratégique très rapide. Or, la transition vers IPv6 sera vraisemblablement
longue.

En effet, si dans les organismes de recherche, les travaux sur IPv6 semblent très convaincants,
il convient de bénéficier d'un autre soutien et non des moindres, à savoir celui des grands
constructeurs, qui restent encore prudents.

Dès lors la question qui émerge est de savoir qui doit migrer vers IPv6 et quand. La réponse
est naturellement liée aux priorités de chacun, mais aussi aux possibilités nouvelles offertes
par IPv6 et qui pour certaines d'entre elles au moins vont probablement devenir essentielles
aux applications courantes de demain : applications de vidéoconférences ou de temps réel,
nécessitant une qualité de service garantie, la configuration automatique des équipements, la
sécurité des données transportées…

L. George
IPv6 Page 59 sur 60

GLOSSAIRE
Quelques définitions :

Adresse (address) : un identifiant de la couche Ipv6 pour une interface ou un groupe


d'interfaces.

ICMPv6 : (Internet Message Control Protocol, ICMP) le protocole de contrôle d’IP revu pour
IPv6 (détection d’erreurs, test, configuration automatique des équipements).

IAB : (Internet Architecture Board) l’IAB fournit une supervision de l’architecture de


l’Internet et de ses protocoles.

IETF : (Internet Engineering Task Force) l’organisme de standardisation de l’Internet.

Interface : un attachement d'un nœud à une liaison.

Liaison (link) : un moyen de communication ou médium sur lequel les nœuds peuvent
communiquer avec la couche liaison (la couche immédiatement sous IPv6).

MTU de liaison (link MTU) : l'unité de transmission maximale (Maximum Transmission Unit
- MTU), c'est à dire la taille maximale du paquet en octets, qui peut être acheminé en un seul
"morceau" sur une liaison (un paquet étant composé d'un en-ête IPv6 et de son "payload").

MTU de chemin (path MTU) : le plus petit MTU de liaison de toutes les liaisons que compose
un chemin entre un nœud source et un nœud de destination.

Nœud (node) : un module protocolaire qui implémente IPv6.

RFC : (Request For Comments) ce sont les documents officiels de l’Internet ; ils sont
disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site
miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/.

Router (routeur) : un nœud qui transmet des paquets IPv6 non explicitement adressés à lui-
même.

Station (host) : tout nœud qui n'est pas un routeur.

Voisins (neighbors) : nœuds rattachés à la même liaison.

L. George
IPv6 Page 60 sur 60

BIBLIOGRAPHIE

IPv6 (Théorie et pratique) par Gisèle CIZAULT (Ed. O’REILLY)

Internet :

IPv6 par Bernard TUY (cours de l'UREC) :


http://www.urec.fr/cours/Reseau/ipv6/index.htm

L. George

Das könnte Ihnen auch gefallen