Protocole IPv6

1. Description du protocole IPv6

Tandis que la technique CIDR permet de repousser l'échéance de la pénurie d'adres-

ses IP de quelques années, tout le monde s'accorde à dire que les jours du protocole IP
dans sa forme actuelle (IPv4) sont comptés. Hormis le problème technique, une autre
interrogation est apparue jusqu'à récemment, le réseau Internet était utilisé largement par
les universités, les industries de pointe, le gouvernement américain (surtout le
Département de la Défense). Mais, dès le milieu des années 1990, Internet intéresse de
plus en plus les entreprises et les sociétés commerciales et il est clair que son expansion
se poursuivra au prochain millénaire. Il sera utilisé par un plus grand nombre d'individus
et de systèmes exprimant les uns les autres des besoins différents. Par exemple, des
millions de personnes pourront utiliser des radio-ordinateurs portables pour rester en
contact avec leur entreprise ou leur domicile. Autre exemple : avec la convergence
imminente de l'ordinateur, des réseaux, de l'audiovisuel et de l'industrie des loisirs,
chaque poste de télévision deviendra avant longtemps un équipement d'accès à Internet
permettant à des milliards d'individus de pratiquer, par exemple, la vidéo à la demande,
le télé-achat ou le commerce électronique. Dans ces circonstances, il est évident que le
protocole IP devait évoluer et devenir plus flexible.
Voyant ces problèmes pointer à l'horizon, en 1990, l'IETF débuta les travaux d'une
nouvelle version du protocole IP qui ne devrait jamais être en rupture d'adresses, qui
devrait résoudre toute une variété de problèmes nouveaux et offrir plus de flexibilité et
d'efficacité. Les objectifs principaux de ce nouveau protocole furent de :
• supporter des milliards d'ordinateurs, en se libérant de l'inefficacité de l'espace
des adresses IP actuelles ;
• réduire la taille des tables de routage ;
• simplifier le protocole, pour permettre aux routeurs de router les datagrammes
plus rapidement ;
• fournir une meilleure sécurité (authentification et confidentialité) que l'actuel
protocole IP ;
• accorder plus d'attention au type de service, et notamment aux services associés
au trafic temps réel ;
• faciliter la diffusion multi destinataires en permettant d'en spécifier l'envergure ;
• donner la possibilité à un ordinateur de se déplacer sans changer son adresse ;
• permettre au protocole une évolution future ;
• accorder à l'ancien et au nouveau protocole une coexistence pacifique.

Pour définir un protocole qui réponde à tous ces objectifs, l'IETF a émis un appel à
propositions et à discussions, consigné dans le RFC 1550. Vingt-et-une réponses ont été
reçues, toutes n'étant ras des propositions complètes. En décembre 1992, sept pro-
positions sérieuses furent mises sur la table. Elles furent classées, depuis celles
prévoyant des modifications mineures de l'actuel protocole IP, jusqu'à d'autres
envisageant son abandon total et son remplacement par un protocole complètement
différent.
L'une des propositions prônait l'exécution du protocole TCP au dessus du protocole
CLNP (ConnnectionLess Network Protocol), qui avec ses 160 bits d'adresses aurait

1
procuré un espace d’adresses quasi infini et aurait permis l’unification de deux protocoles
majeurs de couche réseau.
Le protocole CLNP est calqué sur IP, les deux ne sont pas très différents. En fait, le
protocole choisi en dernier ressort diffère plus du protocole IP que de CLNP. Une
critique formulée contre CLNP fut la pauvreté des types de services supportés,
notamment en matière d'efficacité dans le transfert de données multimédias.
Trois des meilleures propositions furent publiées dans la revue IEEE Network
(Deering, 1993 ; Francis, 1993 ; Katz et Ford, 1993). Après beaucoup de discussions, de
révisions et d'amendements, une version combinée et modifiée des propositions de
Deering et Francis, nommée SIPP (Simple Internet Protocole Plus) fut sélectionnée et
prit le nom IPv6 (IPv5 étant déjà utilisé par un protocole temps réel expérimental).
IPv6 répond raisonnablement aux objectifs édictés. Il maintient les meilleures
fonctions d'IPv4, en écarte ou minimise les mauvaises, et en ajoute de nouvelles quand
elles sont nécessaires. En général, IPv6 n'est pas compatible avec IPv4, mais est
compatible avec tous les autres protocoles Internet, dont TCP, UDP, ICMP, IGMP,
OSPF, BGP, et DNS ; quelque fois, de légères modifications sont requises (notamment
pour fonctionner avec de longues adresses). Les principales fonctions d'IPv6 sont
présentées ci-dessous. Des informations complémentaires peuvent être obtenues dans les
RFC 1883 à 1887.
En premier, la nouveauté majeure d'IPv6 est qu'il utilise des adresses plus longues
qu'IPv4. Elles sont sur 16 octets et permettent de résoudre le problème qui mit IPv6 fut à
l'ordre du jour : procurer un ensemble d'adresses Internet quasi illimité. Nous aurons
beaucoup à dire sur les adresses dans la suite.
La seconde amélioration majeure d'IPv6 c'est la simplification de l'en-tête des
datagrammes. L'en-tête du datagramme de base IPv6 ne comprend que 7 champs (contre
13 à la version IPv4). Ce changement permet aux routeurs de traiter les datagrammes
plus rapidement et améliore globalement leur débit. Nous analysons en détail dans la
suite l'en-tête des datagrammes IPv6.
La troisième amélioration est d'offrir plus de souplesse aux options. Ce changement
est essentiel avec le nouvel en-tête, car les champs obligatoires de l'ancienne version sont
maintenant devenus optionnels. De plus, la façon dont les options sont représentées est
différente ; elle permet aux routeurs d'ignorer plus simplement les options qui ne leur
sont pas destinées. Cette fonctionnalité accélère le temps de traitement des datagrammes.
Le quatrième point sur lequel IPv6 apporte une grande avancée, c'est la sécurité.
L'IETF en avait assez des histoires inondant la presse sur des enfants précoces de 12 ans
qui utilisaient leur ordinateur personnel pour s'introduire dans des bases de données
bancaires ou militaires via le réseau Internet. L'IETF avait le sentiment qu'il fallait faire
quelque chose pour apporter la sécurité dans le réseau Internet. L'authentification et la
confidentialité constituent les fonctions de sécurité majeures du protocole IPv6.
Finalement, une plus grande attention que par le passé a été accordée aux types de
services. Bien que champ Type de services du daragramme IPv4 ne soit que très rarement
utilisé, la croissance attendue du trafic multimédia dans le futur nécessite de s'y
intéresser.
L'en-tête de base des datagrammes IPv6 est présenté à la figure 1.1. Le champ
version est égal à 6 pour IPv6 (à 4 pour lPv4). Pendant la période de transition de IPv4
vers IPv6, qui durera probablement une décennie, les routeurs devront examiner ce

2
champ pour savoir quel type de datagramme ils routent.
Faire ce test gaspille quelques instructions et sur un chemin critique cela se traduit
par une perte de performances. C'est pourquoi nombre d'implémentations l'évitent (et
l'éviteront) : elles utilisent (et utiliseront) un champ de l'en-tête de trame de la couche
liaison (le données pour distinguer les datagrammes IPv4 ou IPv6, de façon à ce que les
datagrammes soient passés directement au bon protocole de la couche réseau. Avoir une
couche liaison de données qui connaisse le type de datagramme (ou de paquet) de la
couche réseau supérieure viole complètement le principe de conception stipulant que
chaque couche ne doit pas avoir connaissance du type de données qui lui sont fournies
par les couches supérieures et inférieures. La polémique entre ceux qui prônent le « faire
bien » et ceux qui prônent le « faire vite » n'est pas prête de s'éteindre.

32 bits
version Priorité Etiquette de flot

Longueur de charge utile En-tête suivant Nombre max

de sauts
Adresse source
(16octets)
Adresse de destination
(16 octets)
Fig. 1.1 En-tête de base des datagrammes IPv6

Le champ Priorité est utilisé pour distinguer les sources qui doivent bénéficier du
contrôle de flux de celles qui ne le doivent pas. Des priorités de 0 à 7 sont affectées aux
sources capables de ralentir leur débit en cas de congestion. Les valeurs 8 à 15 sont
assignées au trafic temps réel dont le débit est constant, même si de nombreux
datagrammes doivent être perdus. Les données audio et vidéo font parie de cette dernière
catégorie.
Cette distinction des flux permet aux routeurs de mieux réagir en cas de congestion.
Dans chaque groupe prioritaire, le niveau de priorité le plus faible correspond aux
datagrammes les moins importants. Le standard IPv6 suggère, par exemple, d'utiliser les
priorités 1 pour les news, 4 pour ftp, et 6 pour telnet en effet retarder un datagramme de
news n'est pas grave, alors que retarder un datagramme de telnet l'est certainement.
Le champ étiquette de flot est un champ expérimental qui permet à une source ou une
destination d'ouvrir une pseudo-connexion avec des propriétés et des exigences
particulières. Par exemple, un flot de datagrammes provenant d'un ordinateur et destiné à
un autre ordinateur pourrait avoir des exigences rigoureuses de délai d'acheminement et
souhaiter disposer d'une certaine bande passante. Le flot peut être déterminé à l'avance et
posséder alors un numéro d'identification. Quand un datagramme doté d'une étiquette de
flot non nulle apparaît, tous les rouleurs le décodent et examinent leur table interne pour
savoir quel traitement particulier lui affecter. Les flots répondent à deux attentes : la
flexibilité d'un sous-réseau de type datagramme et les garanties d'un sous-réseau de type
circuit virtuel.
Chaque flot est désigné par une adresse source, une adresse de destination et un
numéro de flot. Ainsi plusieurs flots peuvent être actifs en même temps entre des paires
d'adresses IP. Même si deux flots provenant d'ordinateurs différents sont dotés d'un

3
même numéro de flot, lorsqu'ils traversent le même routeur celui-ci peut les distinguer
par leurs adresses source et destination. Il est prévu que les numéros de flot soient choisis
aléatoirement plutôt qu'assignés séquentiellement à partir de 1 pour faciliter leur
destruction par les routeurs.
Le champ Longueur de charge utile indique le nombre d'octets de données qui suivent
l'en-tête de 40 octets de la figure 1.1. Par rapport à la version IPv4, le nom de ce champ a
changé; il s'intitulait Lg_ent et indiquait la longueur totale du datagramme. Dans le cas
d'IPv6, la longueur de l'en-tête n'est plus comptabilisée dans la longueur totale du
datagramme, seule la longueur de charge utile compte.
Le champ En-tête suivant spécifie le type de l'en-tête suivant éventuel. La raison ayant
conduit à une simplification de l'en-tête réside dans la possible utilisation des en-têtes
d'extension additionnels (optionnels). Le champ En-tête suivant indique quel en-tête
d'extension suit l'en-tête fixe parmi les 6 définis actuellement. Si l'en-tête est le dernier
d'une suite d'en-têtes IP, le champ En-tête suivant indique à quel protocole de transport le
passer (par exemple, TCP ou UDP).
Le champ Nombre max de sauts est utilisé pour empêcher les datagrammes de circuler
indéfiniment. Il joue le même rôle que le champ Durée de vie d'IPv4, à savoir qu'il
contient une valeur représentant un nombre de sauts ou de pas (hops) qui est décrémenté
à chaque passage dans un routeur. En théorie, dans IPv4, il y a une notion de temps en
secondes mais aucun routeur ne l'utilisant comme tel, le nom a changé pour refléter
l'usage actuel.
Viennent ensuite les champs Adresse source et Adresse de destination. La proposition
originale de Deering, SIPP, utilisait une adresse sur 8 octets, mais lors du processus de
révision des propositions, plusieurs personnes ont pressenti qu'avec 8 octets d'adresses,
IPv6 atteindrait ses limites d'adresses en peu de temps, alors qu'avec 16 octets, il ne les
atteindrait jamais. D'autres personnes ont argué que 16 octets était exagéré, d'autres
encore étaient assez favorables à des adresses sur 20 octets afin d'être compatible avec le
protocole CLNP du monde OSI. Il en est aussi qui réclamaient des adresses de longueur
variable. Après de nombreuses discussions, il fut décidé que les adresses de longueur fixe
égales à 16 octets constituaient le meilleur compromis.
La répartition des adresses IPv6 est décrite à la figure 1.2. Les premiers bits de
l'adresse - le préfixe - définissent le type de l'adresse. Les adresses commençant par 8
zéros sont réservées, notamment pour les adresses IPv4. C'est ainsi que toutes les
adresses commençant par 80 zéros sont réservées aux adresses IPv4. Deux variantes sont
supportées ; elles se distinguent selon les 16 bits suivant (soit 16 bits à 0 ou à 1). Ces
variantes décrivent comment les datagrammes IPv6 doivent être encapsulés pour
traverser en mode tunnel l'actuelle infrastructure IPv4.
L'utilisation de préfixes séparés pour les adresses affectées à un fournisseur et le
adresses affectées à une zone géographique constitue un compromis entre deux
différentes visions du futur du réseau Internet. Les adresses affectées à un fournisseur
prennent tout leur sens lorsqu'on considère qu'il y aura dans le futur (comme cela

0000 0000 Réservé (compatible IPv4) 1/256

0000 0001 Non affecté 1/256
V
0000 001 Adresses NSAP OSI 1/128

4
 0000 010 Adresses Netware IPX Novell 1/128
0000 011 Non affecté 1/128
0000 1 Non affecté 1/32
0001 Non affecté 1/16
001 Non affecté 1/8
010 Adresses affectées à un fournisseur de 1/8
011 services
Non affecté 1/8
100 Adresses affectées à caractère 1/8
101 géographique
Non affecté 1/8
110 Non affecté 1/8
1110 Non affecté 1/16
1111 0 Non affecté 1/32
1111 10 Non affecté 1/64
1111 110 Non affecté 1/128
1111 1110 0 Non affecte 1/512
1111 1110 10 Adresses de lien local 1/1024
1111 1110 11 Adresses des te local 1/1024
1111 1111 Adresses de diffusion multidestinataire 1/256
fig. 1.2 - Répartition des adresses IPv6.

commence à être le cas aujourd'hui) un très grand nombre de sociétés qui offriront des
accès au réseau Interner, comme les opérateurs de télécommunications, les prestataires
d'accès spécialisés, les câblo-opérateurs, etc. Chacun de ces fournisseurs dispose d'une
fraction réservée de l'espace d'adressage (1/8 de cet espace). Les 5 premiers bits qui
suivent le préfixe 010 sont utilisés pour indiquer dans quel « registre » se trouve le
fournisseur d'accès. Actuellement, trois registres sont opérationnels, pour l'Amérique du
nord, l'Europe et l'Asie. Jusqu'à 29 nouveaux registres pourront être ajoutés ulté-
rieurement.
Chaque registre est libre de diviser les 15 octets restants comme il l'entend. Il faut
s'attendre à ce que beaucoup d'entre eux utilisent un numéro de fournisseur sur 3 octets,
ce qui correspond à 16 millions de fournisseurs potentiels différents et permettant à de
grandes sociétés d'agir comme leur propre fournisseur. Une autre possibilité est d'utiliser
un octet pour indiquer la nationalité du fournisseur et de laisser toute liberté aux octets
suivant pour définir une structure d'adresses spécifique. De cette manière, des niveaux de
hiérarchie supplémentaires pourraient être introduits selon les besoins.
Le modèle géographique est le même que celui du réseau Internet actuel, dans lequel
les fournisseurs d'accès ne jouent pas un grand rôle. Dans ce cadre, IPv6 peut gérer deux
types d'adresses.
Les adresses de liens et de sites locaux n'ont qu'une signification locale. Elles peuvent
être réutilisées par d'autres organisations sans qu'il y ait de conflit. Elles ne peuvent pas
être propagées hors des limites des organisations, ce qui les rend bien adaptées à celles

5
qui utilisent des gardes-barrières pour protéger leur réseau privé du réseau Internet.
Les adresses de diffusion multidestinataire disposent d'un champ Drapeau (4 bits) et
d'un champ Envergure (4 bits) à la suite du préfixe, puis d'un champ identificateur de
groupe (112 bits). L'un des bits du drapeau distingue les groupes permanents des groupes
transitoires. Le champ Envergure permet une diffusion limitée sur une zone : le lien
courant, le site, l'organisation ou la Terre entière. Ces quatre zones sont déployées sur 16
valeurs pour permettre de définir de nouvelles zones ultérieurement. Par exemple, le code
de zone s planète » est 14 pour la Terre ; le code 15 est disponible pour une extension
future du réseau Internet à d'autres planètes, systèmes solaires et galaxies.
En plus de supporter l'adressage point à point classique (unicast) et l'adressage de
diffusion multidestinataire (multicast), IPv6 supporte un nouveau type d'adressage de
diffusion, la diffusion au premier vu (anycast). Cette technique est similaire à la
diffusion multidestinataire. L'adresse de destination est un groupe d'adresses, mais plutôt
que d'essayer de livrer le datagramme à tous les membres du groupe, elle essaie de le
livrer à un seul membre du groupe, celui le plus proche ou le plus à même de le recevoir.
Par exemple, pour contacter un groupe de serveurs de fichiers qui coopèrent, un client
peut utiliser la diffusion au premier vu pour trouver le serveur de fichiers le plus proche
de lui, sans avoir à connaître précisément sa localisation. La diffusion au premier vu
utilise des adresses multidestinataires classiques. C'est au système de routage de choisir
l'heureux destinataire du datagramme.
Une nouvelle notation a été définie pour décrire les adresses IPv6 de 16 octets. Elle
comprend huit groupes de quatre chiffres hexadécimaux séparés avec le symbole deux-
points. Par exemple :
8000:0000:0000:0000:0123:4567:89AB:CDEF
Puisque plusieurs adresses ont de nombreux zéros dans leur libellé, trois optimisations
ont été définies. Tout d'abord, les premiers zéro d'un groupe peuvent être omis, par
exemple 0123 s'écrira 123. Ensuite, un ou plusieurs groupes de 16 zéros consécutifs
peuvent être remplacés par un double deux-points. C'est ainsi que l'adresse ci-dessus
devient :
8::123:4567:89AB:CDEF
Enfin, les adresses IPv4 peuvent être écrites en utilisant la représentation de l'adresse
en notation décimale pointée précédée d'un double deux points, comme par exemple :
::192.31.320.46
Il n'est pas nécessaire d'être plus explicite sur cette notation d'adresses, mais il faut
savoir qu'il y a un nombre important d'adresses sur 16 octets. Précisément, il y en a 2128,
soit approximativement 3 x 1038. Si la Terre entière (terre et eau confondues), était
couverte d'ordinateurs, IPv6 pourrait allouer 7 x 1023 adresses IP par m2. Les étudiants en
chimie noteront que ce nombre est plus grand que le nombre d'Avogadro. Bien qu'il ne
soit pas dans l'intention de donner une adresse IP à chaque molécule de la planète. Nous
n'en sommes pas loin.
En pratique, l'espace d'adresses ne sera pas utilisé efficacement, pas plus que l'espace
d'adresses de la version IPv4 ou les numéros de téléphone. Dans le RFC 1715, C.
Huitema a calculé qu'en utilisant l'allocation des numéros de téléphone comme guide,
même dans le scénario le plus pessimiste, il y aurait bien plus de 1000 adresses IP par m2
sur la surface de la Terre (terre et eau confondues). Dans n'importe lequel des scénarios
possibles, il y aurait des trillions d'adresses par m2. En bref, il parait impossible de

6
déborder des limites d'adresses dans un futur prévisible. Il est intéressant de signaler que
seulement 28% de l'espace d'adresses a été alloué. Les 72% restant sont disponibles pour
de futurs projets dont on n'a pas encore idée.
Il est intéressant de comparer l'en-tête IPv4 à l'en-tête IPv6 (figure 1.1) afin dé voir ce
qui a changé avec IPv6. Le champ Lg eut a disparu car l'en-tête IPv6 a une longueur fixe.
Le champ Protocole est exclu parce que le champ En-tête suivant du dernier en-tête IP
d'un datagramme précise le type de protocole (par exemple, UDP ou TCP).
Tous les champs relatifs à la fragmentation ont été retirés, parce qu'IPv6 a une
approche différente de la fragmentation. Pour commencer, tous les ordinateurs et routeurs
conformes à IPv6 doivent supporter les datagrammes de 576 octets. Cette règle place la
fragmentation dans un rôle secondaire. De plus, quand un ordinateur envoie un trop grand
datagramme IPv6; contrairement à ce qu'il se passe avec la fragmentation, le routeur qui
ne peut le transmettre retourne un message d'erreur à la source. Ce message précise à
l'ordinateur source d'interrompre l'envoi de nouveaux datagrammes vers cette destination.
Avoir un ordinateur qui transmette immédiatement des datagrammes à la bonne
dimension est bien plus efficace que de voir les routeurs les fragmenter à la volée.
Enfin, le champ Total de contrôle n'existe plus car son calcul est trop réducteur de
performance. En effet, la fiabilité des réseaux actuels, combinée avec le fait que les
couches liaison de données et transport effectuent leur propre contrôle, le gain en qualité
d’un total de contrôle supplémentaire ne vaut pas le prix à payer pour le calculer.
Enlever toutes ces fonctions au protocole IPv6 a eu pour résultat de définir un
protocole de couche réseau maigre et avare. C'est ainsi que les objectifs d'IPv6 d'être un
protocole rapide, flexible et doté d'un très large espace d'adressage ont été parfaitement
atteints.

En-têtes d'extension
Quelques-uns des champs manquants du datagramme IPv4 sont néanmoins
occasionnellement requis, aussi IPv6 a-t-il introduit le concept d'un en-tête d'extension
(optionnel). Cet en-tête, s'il est présent, fournit une information complémentaire de façon
efficace. Six types d'en-tête d'extension ont été définis dans un premier temps, ils sont
listés à la figure 1.3. Chacun d'eux est optionnel. Si plus d'un en-tête est présent, ils
doivent apparaître immédiatement après l'en-tête fixe, de préférence dans l'ordre de la
liste.
Certains en-tête ont un format fixe ; d'autres contiennent un nombre variable de
champs variables. Pour cela, chaque item est codé sous forme d'un triplet (Type,
Longueur. Valeur). Le Type est un champ d'un octet qui précise la nature de l’option. Les
différents types ont été choisis de façon à ce que les 2 premiers bits disent quoi faire aux
routeurs qui ne savent pas exécuter l'option. Les choix sont : sauter l'option, détruire le
datagramme, détruire le datagramme et retourner un message ICMP à la source,
En-tête d’extension Description
Pas-après-pas informations destinées aux routeurs
Routage Route à suivre complètement ou partiellement
Fragmentation Gestion des fragments de datagramme

7
 Authentification Vérification de l'identité de l'émetteur
Charge utile chiffrée Information sur le chiffrement des données
Option de destination Information additionnelle pour le destinataire
Fig. 1.3 - En-têtes d'extension IPv6.

détruire le datagramme sans retourner de message ICMP s'il s'agit d'un datagramme
multidestinataire (afin d'éviter un nombre trop important de rapport ICMP en retour).
La Longueur est un champ d'un octet. Elle indique la taille du champ Valeur (de 0 à
255 octets) qui contient une information quelconque adressée au destinataire.
L'en-tête Pas-après-pas contient des informations destinées à tous les routeurs sur le
chemin. Bien que plusieurs options soient prévues pour cet en-tête, jusqu'à présent une
seule option a été définie : permettre l'utilisation de datagrammes d'une taille supérieure à
64 Ko. Le format de cet en-tête est décrit à la figure 1.4. Comme pour tous les en-têtes
d'extension, il commence par un champ d'un octet indiquant quel est le type d'en-tête
suivant. Un second champ d'un octet donne la longueur (en octets) de l'en-tête Pas-après-
pas ; les 8 premiers pas sont obligatoires. Les deux champs suivants précisent que l'en-
tête donne la taille du datagramme (code 194). Les 4 derniers octets fournissent alors la
taille du datagramme. Celle-ci ne doit pas être inférieure à 65 536 ; en effet le
datagramme serait détruit par le premier routeur rencontré qui renverrait un message
d'erreur 1CMP à la source. Les datagrammes utilisant cet en-tête d'extension sont appelés
des jumbo-datagrammes ou jumbogrammes. L'utilisation de ces grands datagrammes est
importante pour certaines applications qui doivent transférer des Gigaoctets de données
rapidement dans le réseau Internet, comme par exemple des échanges de volumineux
fichiers entre superordinateurs.

En-tête 0 194 0
suivant
Longueur de la charge utile
Fig. 1.4 - En-tête d'extension de l'option
Pas-après-pas pour les grands datagrammes.

L'en-tête Routage donne la liste d'un ou de plusieurs routeurs qui doivent être visités
sur le trajet vers la destination. Deux formes de routage sont mises en œuvre de façon
combinée : le routage strict (la route intégrale est définie) et le routage lâche (seuls les
routeurs obligatoires sont définis). Le format de l'en-tête Routage est présenté à la figure
1.5.
Les quatre premiers champs de l'en-tête d'extension Routage contiennent 4 entiers d'un
octet : le type d'en-tête suivant, le type de routage (couramment 0), le nombre d'adresses
présentes dans l'en-tête (1 à 24), et un index donnant la prochaine adresse à visiter. Ce
dernier champ commence à la valeur 0, il est incrémenté à chaque adresse visitée.

8
 En-tête 0 Nombre Adresse
suivant d’adresses suivante

Réservé Mappage binaire d’adresses

1 à 4 adresses

Fig. 1.5 - En-tête d'extension Routage.

On trouve ensuite un octet réservé, puis un mappage binaire qui associe un bit à
chacune des 24 adresses IPv6 éventuelles qui suivent. Les bits du mappage précisent si
chaque adresse de la liste (celle d'un routeur) doit être visitée immédiatement après la
précédente dans la liste (cas du routage strict), ou si d'autres adresses externes à la liste
(celles d'autres routeurs) peuvent se glisser entre l'adresse précédente et la suivante de la
liste (routage lâche).
L'en-tête Fragmentation traite de la fragmentation de manière similaire à IPv4. L'en-
tête contient l'identifiant de datagramme, le numéro de fragment et un bit précisant si
d'autres fragments suivent. Dans IPv6, contrairement à IPv4, seul l'ordinateur source peut
fragmenter le datagramme. Les routeurs sur le trajet ne le peuvent pas. Bien que ce
changement soit une rupture philosophique majeure avec le passé. Il simplifie le travail
des routeurs et rend le routage plus rapide. Comme indiqué plus haut, si un routeur est
confronté à un datagramme trop grand, il le détruit et transmet en retour un message
ICMP à la source. Cela permet à l'ordinateur source de fragmenter le datagramme en
morceaux et d'utiliser l'en-tête Fragmentation pour transmettre les morceaux.
L'en-tête Authentification fournit un mécanisme permettant au destinataire d'un
datagramme de s'assurer de l'identité de la source. Dans IPv4, aucune garantie semblable
n'est offerte. L'utilisation du chiffrement des données du datagramme (sa charge utile)
renforce sa sécurité ; seul le vrai destinataire peut les lire. Cet en-tête utilise des
techniques de chiffrement pour accomplir sa mission. Nous en donnons une brève
description ci-dessous.
Quand un émetteur et un récepteur veulent communiquer en toute sécurité, ils doivent
tout d'abord se mettre d'accord sur une ou plusieurs clés secrètes connues d'eux seuls.
Comment se mettent-ils d'accord ? Cela sort des propos d'IPv6. Il est assigné un nombre
clé de 32 bits à chacune des deux clés. Les nombres clés sont globaux de façon que, par
exemple, si Christine utilise la clé 4 pour parler à Michel, elle ne peut pas utiliser cette
clé 4 pour parler à Sylvie. D'autres paramètres sont associés à chaque nombre clé, tel que
sa durée de vie, etc.
Pour envoyer un message authentifié, l'ordinateur source construit premièrement un
datagramme contenant tous les en-têtes IP et la charge utile, puis il remplace les champs
qui changent peu souvent par des zéros (par exemple, le champ Nombre max. de sauts).
Le datagramme est complété avec des zéros pour devenir un multiple de 16 octets. De
façon similaire, la clé secrète utilisée est aussi complétée avec des zéros pour être un
multiple de 16 octets. Puis, un total de contrôle chiffré est calculé après concaténation de
la clé secrète complétée, du datagramme complété et, à nouveau, de la clé secrète
complétée. Les utilisateurs peuvent définir eux-mêmes l'algorithme de calcul du total de
contrôle chiffré ; les non-avertis des arcanes de la cryptographie se contenteront de
l'algorithme par défaut : MD5.

9
 Examinons à présent l'en-tête Authentification. Il contient trois parties. La première
compte 4 octets précisant le numéro d'en-tête suivant, la longueur de l'en-tète
d'authentification, et 16 bits à zéro. La seconde définit le nombre clé sur 32 bits. La
troisième contient le total de contrôle chiffré (avec l'algorithme MD5 ou un autre).
Le destinataire utilise le nombre clé pour trouver la clé secrète. La valeur complétée de
la clé secrète est ajoutée avant et après la charge utile elle-même complétée, les champs
variables de l'en-tête sont vidés de leurs zéros, puis le total de contrôle chiffré est calculé.
Si le résultat du calcul est égal au total de contrôle chiffré contenu dans l'en-tête
Authentification, le destinataire est sûr que le datagramme vient bien de la source avec
laquelle il partage la clé secrète. Il est également sûr que le datagramme n'a pas été
falsifié à son insu en arrière-plan. En effet, les propriétés de l'algorithme MD5 rendent le
calcul du total de contrôle chiffré impossible pour un intrus qui voudrait falsifier l'identité
de l'émetteur ou modifier le datagramme d'une manière qui échapperait à la détection.
Il est important de noter que la charge utile d'un datagramme authentifié peut être
envoyée non chiffrée. Tout routeur sur le parcours peut lire ce qu'il voit. Pour beaucoup
d'applications, le secret des données n'est pas fondamental, ce qui est important c'est
l'authentification de l'émetteur. Par exemple, si un utilisateur donne instruction à sa
banque de payer sa facture de téléphone, il n'y a pas un réel besoin de secret sur le
montant de la facture ; il est en revanche absolument nécessaire que la banque soir sûre
de savoir qui envoie le datagramme contenant l'ordre de paiement.
Pour les datagrammes qui doivent être envoyés secrètement, il faut utiliser l'en-tête
d'extension Charge utile chiffrée. Cet en-tête commence par un nombre-clé de 32 bits,
suivi par la charge utile chiffrée. L'algorithme de chiffrement utilisé est au choix de
l'émetteur et du récepteur ; l'algorithme par défaut est DES en mode chaînage par blocs
de chiffrement. Lorsque l'algorithme DES-CBC est utilisé, le champ charge utile com-
mence par un vecteur d'initialisation (multiple de 4 octets), vient ensuite la charge utile,
puis le tout est complété avec des zéros pour obtenir un multiple de 8 octets. Si le
chiffrement et l'authentification sont souhaités, les deux en-têtes de chiffrement sont
nécessaires.
L'en-tête Option de destination est utilisé pour des champs qui n'ont besoin d'être
interprétés et compris que par l'ordinateur destinataire. Dans la version originale d'IPv6,
la seule option de destination qui a été définie est l'option nulle. Elle permet de compléter
cet en-tête par des zéros pour obtenir un multiple de 8 octets. Cet entête ne sera pas utilisé
dans un premier temps. Il a été défini pour s'assurer que les nouveaux logiciels de routage
pourront le prendre en compte, au cas où quelqu'un envisagerait un jour une option de
destination.
Controverses
Le processus de conception d'IPv6 ayant impliqué de nombreuses personnes, chacune
affichant de solides opinions, il n'est pas surprenant de voir que parmi les choix faits
certains sont très controversés. Nous résumons ci-après quelques-unes de ces con-
troverses. Pour tous les détails « sanglants », reportez-vous à (Huitema 1996).
Nous avons déjà mentionné la discussion sur la longueur des adresses qui a donné lieu
a un compromis des adresses, d'une longueur fixe de 16 octets.
Une bataille fut également engagée sur la longueur du champ Nombre max. de sauts.
Certaines personnes affirmèrent durement que la limitation maximale à 255 sauts (ce qui
est implicite si on utilise un champ de 8 bits) était une grossière erreur. Après tout, des

10
chemins de 32 sauts sont très courants de nos jours, et dans 10 ans des chemins beaucoup
plus longs seront fréquents. Ces personnes arguèrent qu'utiliser une taille d’adresse
importante était très prévoyant, mais se doter d'un minuscule nombre de sauts passibles
relevait de la myopie. De leur point de vue, le plus grand péché qu'un ordinateur
scientifique puisse commettre c'est de fournir trop peu de bits quelque part. La réponse
formulée à ces personnes fut que la prise en compte de leurs arguments entraîneraient une
augmentation de la taille de tous les champs du datagramme, à commencer par l'en-tête.
La fonction du champ Nombre max. de sauts consiste à empêcher les datagrammes de
vagabonder trop longtemps dans le réseau. Si le nombre maximum de sauts avait été de
65 536 (avec un champ Nombre max. de sauts sur 16 bits), cela aurait été beaucoup trop
long. La croissance importante du réseau Internet entraîne une augmentation du nombre
de liaisons longue distance intégrées dans le réseau, ce qui rend possible d'aller d'un pays
à un autre en une demi-douzaine de sauts au plus. Si cela devait prendre plus de 125 sauts
pour aller d'une source (ou d'une destination) vers le routeur international d'un pays,
quelque chose serait mauvais dans le routage du réseau national concerné.
Une autre source de conflit fut la longueur maximale du datagramme. Les
scientifiques utilisant des superordinateurs souhaitaient des datagrammes géants, bien
supérieurs à 64 Ko, arguant du fait qu'une fois un transfert initialisé il était hors de
question d'interrompre un superordinateur tous les 64 Ko. L'argument contre les
datagrammes géants était que, si un datagramme de 1 Mo arrivait sur une artère de
communication à longue distance et à haut débit (1,5 Mbit/s pour une liaison T1), le
datagramme occuperait la liaison pendant plus de 5 secondes, ce qui produirait alors un
délai d'attente insupportable pour les utilisateurs interactifs qui partageaient la même
ligne. Un compromis a été trouvé : les datagrammes normaux sont limités à 64 Ko, mais
l'entête d'extension Pas-après-pas, s’il est utilisé, autorise de manipuler de grands
datagrammes, les jumbogrammes.
Encore un sujet chaud : la suppression du total de contrôle du datagramme. Quelques
personnes ont comparé cette suppression à celle des freins d'une automobile. Faire cela
rendait la voiture plus légère, certes elle pouvait aller plus vite, mais si un événement
imprévu arrivait, vous risquiez d'avoir de sérieux problèmes. L'argument contre le total
de contrôle fut que toute application se préoccupant réellement de l'intégrité des données
devait avoir dans tous les cas un total de contrôle au sein de sa couche transport. Avoir un
total de contrôle supplémentaire dans la couche réseau, alors qu'il y en a aussi un (le plus
souvent) dans la couche liaison de données, est exagéré. En outre, l'expérience a montré
que le calcul du total de contrôle dans la couche réseau entraînait un surcoût majeur pour
le protocole IPv4. Le camp anti total de contrôle gagna la manche. et IPv6 n'a pas de total
de contrôle.
Les ordinateurs mobiles sont aussi l'objet de discorde. Si un ordinateur mobile est
déplacé autour du monde, peut-il continuer à dialoguer avec un destinataire en utilisant
son adresse IPv6, ou doit-il utiliser un schéma d'adressage particulier avec agent
domestique et agent extérieur ? Les mobiles introduisent aussi des asymétries dans les
routines systèmes. Il est sûr qu'un modeste ordinateur mobile (un radio ordinateur)
peut recevoir le puissant signal délivré par un gros routeur fixe (une station radio BSC),
mais ce routeur fixe peut ne pas entendre le faible signal émis par l'ordinateur mobile. En
conséquence, quelques personnes ont voulu concevoir un support radio spécifique pour
les ordinateurs mobiles dans IPv6. Cet effort a échoué, aucun consensus n'ayant pu être

11
trouvé autour des propositions présentées.
La plus importante bataille a été probablement celle portant sur la sécurité. Tout le
monde a admis qu'elle était nécessaire. La bataille a porté sur : « où et comment ».
Premièrement, où ? L'argument pour introduire la sécurité au sein de la couche réseau fut
qu'elle deviendrait alors un service standard que toutes les applications pourrait utiliser,
sans le planifier à l'avance. L'argument contre fut que les applications nécessitant une
sûreté absolue admettent uniquement un chiffrement de bout en bout, l'application source
chiffrant l'information, et l'application destinataire la déchiffrant. Avec le schéma
précédent l'utilisateur serait à la merci d'une couche réseau potentiellement corrompue,
sur laquelle il ne pourrait avoir aucun contrôle. La réponse à cet argument fut que ces
applications pouvaient s'abstenir d'utiliser les fonctions de sécurité intégrées à IPv6 et
faire le travail elles-mêmes, à l'extérieur. La réplique des personnes qui n'avaient pas
confiance en ce qui se faisait dans la couche réseau fut qu'elles ne voulaient pas payer le
prix fort d'une mise en oeuvre d'IPv6 encombrante et lente, qui aurait des capacités de
sécurité qui seraient inhibées.
L'autre aspect de « où mettre la sécurité » est relatif à la réglementation concernant
l'usage de la cryptographie. Elle diffère d'un pays à l'autre ; en France notamment jusqu'à
présent le chiffrement est considéré comme une arme de guerre, et de ce fait il est soumis
à un certain nombre de contraintes de défense nationale. II en résulte qu'aucune mise en
œuvre utilisant un système de chiffrement assez solide pour apporter une grande garantie
de sûreté n'est permise sans autorisation.
La controverse finale concernant la sécurité est relative au choix de l'algorithme par
défaut que toute implémentation doit supporter. Le choix s'est porté sur l'algorithme MD5
qui fut jugé suffisamment sûr, mais les récentes avancées en cryptographie pourraient
l'affaiblir. Il pourrait en être de même de l'algorithme DES.
Un point sur lequel il n'y a pas de controverse, c'est que personne n'imagine le protocole
IPv4 s'éteindre un dimanche soir et se rallumer en protocole IPv6 le lundi matin. A
contrario, des îlots IPv6 isolés seront mis en place et communiqueront au début via des
tunnels IPv4. Lorsque ces îlots lPv6 grandiront, ils pourront être agrégés en îles plus
grandes. Finalement, toutes les îles pourront être réunies, et le réseau Internet sera ainsi
complètement converti. Étant donné les investissements colossaux nécessaires dans les
routeurs IPv4 actuels pour assurer cette migration, celle-ci prendra au moins une
décennie. Pour cette raison, de nombreux efforts ont été entrepris pour s'assurer que cette
migration puisse se faire avec un minimum de douleur possible.

12