Cet article présente IPv6 et les problématiques d'intégration d'IPv6 dans IPv4.

 

IPv4

Adresse IPv4 sur 32 bits (4 octets), soit 2^32 adresses, soit 4,3 milliards

2^32 = (1,024 * 2^10) * (1,024 * 2^10) * ( 1,024 * 2^10) * (2^2) = 1,024^3 * 2^10^3 * 4 =  1,024^3 * 4  2^10^3 = 4,3 * 2^10^3 = 4,3 * 10^3^3 = 4,3 10^9

L'adressage IPv4 ne répond donc plus aux besoins :  pas assez au vue du nombre d'humain, pas assez avec l'arrivée des objets connectés.

Cette pénurie d'adresse a été résolue par l'utilisation d'adresses privées et du NAT. Le NAT a été créé pour pallier à cet insuffisance. Le bout en bout, qui était la philosophie d'IPv4 a alors disparu.

 

IPv6

Adresse IPv6 sur 128 bits (16 octets), soit 2^128 adresses, soit 3,4 10^38 adresses

2^128 = (2^10) ^12 * (2^8) =  (2^10) ^12 * (2^10)  / 4 = (1,024*10^3)^12 * (1,024*10^3)/4 =  1,024^12 * 10^36 * (1,024*10^2)*10/4 = 1,024^13 * 10^38 * 2,5

= 3,4 10^38

La pénurie d'adresse IPv6 n'est donc pas pour demain. La notion de NAT ne sera plus nécessaire avec IPv6.

 

Notation des adresses IPv6

Les 128 bits de l'adresse IPv6 sont présentées sous la forme de 8 blocs de 16 bits. Chaque bloc de 16 bits est alors noté sous forme hexadécimal et non décimal comme en IPv4.

Exemple :

En binaire, les 128 bits

00100000 00000001 00001101 10111000 00000000 00000000 00000000 00000000 00000000

00001000 00001000 00000000 00100000 00001100 01000001 01111010

En notation hexadécimal IPv6 :

2001:0db8:0000:0000:0008:0800:200c:417a

En notation compacte :

2001:db8::8:800:200c:417a

 

Notation des préfixes IPv6

Comme en IPv4, la longueur du préfixe d'une adresse IPv6 permet de connaitre le nombre de bits qui représentent la partie réseau.

Exemple, une adresse IPv6 avec 60 bits pour la partie réseau 2001:db8:24:a1a1:8:800:200C:417a/60

Le réseau correspondant est 

2001:db8:24:a1a0::/60

Attention, le dernier 0 de a1a0 ne fait pas partie du réseau, mais il faut le mettre car sinon on pourrait croire que le réseau est 2001:db8:24:0a1a::/60 .

Dans l'exemple, l'adresse IP avait pour ce bit une valeur de 1. On a mis un 0 pour exprimer le réseau d'appartenance de cet IP.

 

Les différents types d'adresse IPv6

Il existe différents types d'adresse et de portée différente.

Adresse unicast : adresse unique qui définit une interface.

Mais la portée peut être :

globale, on parle d'adresse GUA (global unicast address); cette adresse est donc unique sur tout l'internet v6.

locale, on parle d'adresse ULA (unicast local address); cette adresse est privée, donc non accessible depuis internet v6, mais routable dans le réseau interne de l'entreprise.

lien local, on parle d'adresse link local addrress : cette adresse est restreinte à un lien ou domaine de diffusion de type VLAN

Adresse multicast : permet de désigner un groupe d'interface. Ce groupe d'interface peut être par exemple le groupe des interfaces de type routeur, le groupe des interfaces de type "serveur DHCP" par exemple, ou par exemple un certain nombre de PC souhaitant recevoir un flux multicast. Ainsi, il existe des adresses multicast réservées pour les usages courant, comme par exemple les routeurs.

Adresse anicast : type d'adresse au stade expérimental. Comme multicast, désigne un groupe d'adresse, mais la datagramme à destination d'une adresse anycast ne sera pas remis à tous ces membres, mais seulement à un seul.

 

Toutes ces différents type d'adresse / portée sont identifiables par des préfixes réservés.

Type	Bit de poids forts	Notation hexadécimale	Commentaire
Non spécifié	0...0	::/128
Adresse de bouclage (loopback)	0...1	::1/128
Multicast	1111 1111	ff00::/8
Unique local (ULA)	1111 1101	fd00::/8	Ces adresses ne peuvent sortir sur internet, les fournisseurs d'accès ne doivent pas les router. En principe, c'est fc00::/7 (1111 110). En prenant 1111 1101, on aboutit à fd00::/8 qui est bien un sous ensemble de fc00::/7.
Globale unique (GUA)	001	2000::/3	Comprend donc les adresses commençant par 2 ou 3 : 0011 = 0x3
Adresse 6to4		2002::/16	Adresse utilisée pour des sites IPv6 isolés interconnectés par un réseau IPv4.
Unique lien local (link local address)	1111 1110 10	fe80::/10

 

Les adresses unicast globales

Ces adresses sont donc publiques et routables sur internet. La plage de ces adresses a été définie dans la RFC 3587 et 3513.

Ainsi, la topologie réseau de ces adresses est la suivante :

les n premiers bits sont alloués par le fournisseur d'accès et constitue le Global Prefix; cette valeur oscille entre 48 à 64 suivant les fournisseurs d'accès à internet (FAI), 48 était la recommandation initiale

les 16 bits suivants permet de structurer la topologie du site (SID pour subnet id)

les 64 derniers bits suivants permettent de définir l'identifiant de l'interface (IID : interface id)

Le plan agrégé 2000::/3 a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (Registres Internet Régionaux). Les RIR gèrent les ressourcesd'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille/23 à /12 dans l'espace unicast global ( 2000::/3 ) aux cinq RIR. Ces derniers les allouent à eur tour aux LIR (fournisseur d'accès à internet) sous forme de blocs de taille minimale de /48.Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de65536 réseaux /64.

L'identifiant d'interface

Cet identifiant doit être unique sur le lien ou sur le domaine de diffusion.

Pour déterminer cette valeur, il existe 4 méthodes possibles :

adresse saisie manuellement,

adresse dérivée de l'adresse MAC. C'est la méthode la plus courante, tout spécialement pour l'adresse link local

aléatoire,

cryptographique.

 

L'adresse saisie manuellement est utilisé dans le cas des serveurs afin d'assurer une stabilité.

L'adresse dérivée de l'adresse MAC est le cas courant pour l'adresse de type lien local. La critique de cette méthode concerne la confidentialité. Une personne changeant de réseau aura une nouvelle adresse, mais la partie identifiant d'interface sera la même. Il est alors possible de tracer les individus et de connaitre la marque de la carte réseau.

L'adresse aléatoire permet de rendre les utilisateurs anonymes.

 

Comment spécifier la méthode choisi pour calculer l'interface identifer?

En fait, chaque OS a sa méthode pour définir l'IID. Une interface peut même avoir par exemple deux adresses globales, une avec  un iid calculé sur l'adresse MAC et une autre calculé de façon aléatoire avec une durée de vie limitée.

 

Les adresses multicast

Il s'agit des adresses de la forme ff00::/8.

Les bits drapeaux 0RPT ont le rôle suivant :

le premier bit vaut 0 car son usage est pas encore défini

le bit R sert à la notion de rendez-vous (RFC 3956)

le bit P indique la méthode de création (RFC 3306)

le bit T (transient) permet de savoir s'il s'agit d'une adresse multicast bien connue. Vaudra alors 0.

 

Le champ scope a pour but de définir la portée du datagramme. En IPv4, la notion de saut permettait de répondre à ce besoin. En IPv6, une autre stratégie a donc été définie (on peut toujours en plus utiliser la notion de hop limit).

Ci-dessous la codification des différentes portées :

Code	Portée
0	reserved
1	node-local
2	link-local
3	realm-local
4	admin-local
5	site-local
8	organisation-local
e	global
f	reserved

 

Listes des adresses multicast bien connues

Adresse de multicast	Population concernée
ff01::101	Tous les serveurs NTP de la même interface (c.à.d. le même noeud) que l'émetteur
ff02::101	Tous les serveurs NTP du même lien que l'émetteur
ff05::101	Tous les serveurs NTP du même site que l'émetteur
ff0e::101	Tous les serveurs NTP de l'Internet
ff01::1	Toutes les interfaces du noeud
ff02::1	Toutes les noeuds sur le même lien que l'interface émettrice (correspond au broadcast 255.255.255.225 d'IPv4)
ff01::2	Tous les routeurs du noeud
ff02::2	Tous les routeurs du lien
ff05::2	Tous les routeurs du site
ff02::1:2	Tous les serveurs DHCPv6 et relais DHCPv6

 

Adresses IPv6 multicast sollicitées

Ce type d'adresse IPv6 sert aux mécanisme suivant :

lors de la phase de Détection de la duplication des adresses (DAD)

lors de la phase de Sollicitation des voisins (Neighbor Sollicitation)

L'adresse de "multicast sollicité" se construit automatiquement à partir d'une adresse IPv6 unicast (ou anycast) en concaténant le préfixe réservé ff02::1:ff00:0 /104 aux 24 bits de poids faible de l'adresse unicast ou anycast.

 

Adresses MAC associées aux adresses IPv6 multicast sollicitées

L'adresse MAC de multicast est déduite de l'adresse multicast IPv6 en concaténant les 32 derniers bits (4 octets) de l'adresse multicast IPv6 au préfixe MAC prédéfini 33-33
Par exemple, à l'adresse multicast IPv6 ff0e:30:2001:660:3001:4002:ae45:2C56 correspondra l'adresse MAC 33-33-AE-45-2C-56.

 

En-tête IPv6

Ci-dessous la structure de l'en-tête IPv6 :

 

L'en-tête IPv6 a une taille de 40 octets contre 20 en IPv4.

Version (sur 4 bits) : contient la version d'IP, donc 6.

Classe de trafic /  Traffic Class (sur 8 bits) :

Les 6 premiers bits représentent le champ DSCP.

Les 2 bits suivants représentent le champ ECN (Explicit Congestion Notification) qui permet au routeur de signaler des problèmes de congestion du réseau.

Identificateur de flux /  Flow Label (sur 16 bits) :  ce champ sert au routeur à identifier un même flux (au lieu de lire l'IP source et dest, les ports sources et destination); c'est donc l'application émettrice qui définit cette valeur pour un flux donné.

Actuellement, ce champ est peu utilisé.

Longueur des données /  Payload Length (sur 16 bits) :

définit le nombre d'octets qui suivent après l'en-tête IP. Si une extension IP est présente, sa taille est inclue dans le calcul de la longueur des données.

En-tête suivant / Next Header (sur 8 bits) :

permet d'indiquer le contenu du paquet IP : un flux TCP, un flux UDP, ...

Ainsi les valeurs des en-têtes les plus utilisés sont les suivants :

Valeur décimale	Valeur hexadécimale	Protocole
0	0x00	Proche en proche
4	0x04	IPv4
6	0x06	TCP
17	0x11	UDP
41	0x29	IPv6
43	0x2b	Routage
44	0x2c	Fragmentation
50	0x32	Confidentialité
51	0x33	Authentification
58	0x3a	ICMPv6

Nombre maximal de saut / Hop Limit (sur 8 bits) :

définit le nombre maximal de routeur que peut traverser un datagramme. Ainsi, la valeur maximale est donc 255. Dans la pratique sur internet, on constate qu'un paquet traverse au maximum 40 routeurs, donc la taille de ce champ est suffisante.

Adresse source et adresse destination (sur 128 bits): l'adresse IPv6 sur 128 bits

Extension à l'en-tête IPv6 / IPv6 extension :

Ci-dessous la structure d'une extension d'en-tête IPv6 

 

 

Evolution de l'en-tête depuis IPv4

L'en-tête IPv6 ne contient plus de contrôle d'erreur (checksum). Avec IPv4, à chaque traversée de routeur, comme le champ TTL est décrémenté, le routeur doit calculer à nouveau le checksum. Tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-entête
qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire.

La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent ( identification, drapeau, place du fragment ) ont été supprimés.

Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ Internet Header Length), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'entête IPv6 simplifient la mise en oeuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.

 

Les extensions IPv6

Le mécanisme d'extension permet de traiter les cas particuliers sans changer la taille de l'en-tête IPv6 que chaque routeur doit lire.

L'ordre des extensions est décrit dans la section 4.1 du RFC 2460. La classification des extensions est fonction de la portée de celles-ci:
• extension impliquant le destinataire: Destination, ESP, AH, Fragmentation;
• extensions impliquant tous les routeurs intermédiaires: Hop-by-Hop ;
• extensions impliquant seulement certains routeurs désignés: Routing.

L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin ( Hop-by-Hop ) devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension Destination, elle ne pourrait être lue, l'extension Destination n'étant interprétée que par le destinataire du paquet.

 

Ci-dessous divers cas d'extensions IPv6 :

 

Encapsulation

Ci-dessous un schéma de l'encapsulation :

DOD : Department Of Defense, qui est à l'origine de TCP/IP.

 

Traitement des couches basses

La couche physique est fréquemment soumise à différentes perturbations issues d’un monde extérieur au canal de transmission: radiations électromagnétiques, micro-coupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseau réalisent les fonctions nécessaires et utiles au niveau physique , et on dispose d’un indicateur de qualité de la transmission avec le calcul de CRC (Contrôle de Redondance Cyclique).

Ci-dessous la trame Ethernet :

Une fois que l’arrivée d’une trame Ethernet est détectée par le coupleur, les premiers champs immédiatement accessibles correspondent aux adresses MAC Destination et Source puis, soit au champ Longueur dans le cas d’une encapsulation au standard 802.3, ou bien au champ EtherType dans le cas d’une encapsulation avec le standard Ethernet original. Ensuite, l’enveloppe de la trame transporte les données, qui correspondent aux paquets IPv6 dès lors que le champ EtherType = 0x86dd . Vient ensuite le champ CRC codé sur 32 bits. Dans le cas d’une encapsulation au standard 802.1Q, d’autres champs permettent la reconnaissance du numéro de VLAN ( Virtual Local Access Network ) et du niveau de priorité défini dans le standard 802.1p. Un des éléments particulièrement importants est la capacité de transport de la trame. Dans l’exemple ci-dessus, nous voyons que la trame Ethernet traditionnelle dispose d’une enveloppe qui autorise le transport de 1500 octets maximum: MTU = 1500 (MTU = Maximum Transmit Unit).

En IPv6, une taille minimale de 1280 octets est imposée.

 

Contrôler le fonctionnement du réseau par ICMPv6

Terminologie

Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.

Les fonctions assurées par ICMPv6

ICMPv6 intègre plus de fonctionnalités qu'ICMPv4 :

• message d'erreur au cours de l'acheminement d'un paquet
• test d'accessibilité d'un noeud
• configuration automatique des équipements
• gestion des groupes multicast (MLD : multicast Listener Discovery)
• résolution d'adresse IP en adresse MAC (équivalent du protocole ARP) à l'aide de NDP (Neighbor Discovery Protocol).

 

Format général d'un message ICMPv6

Champ Type :

De 0 à 127, il s'agit de message d'erreur

De 128 à 255, il s'agit de message d'information

Champ Code :

Ce champ précise le champ Type

Ci-dessous les principaux Type / Code de message ICMP :

Ces numéros sont gérés par l'IANA (Internet Assigned Number Authority).

Type	Code	Signification
1		Destination inaccessible
1	0	Aucune route vers la destination
1	1	La communication avec la destination est administrativement interdite
1	2	Hors portée de l'adresse source
1	3	L'adresse est inaccessible
1	4	Le numéro de port est inaccessible
1	5	L'adresse source est filtré par un firewall
1	6	L'adresse destination est rejetée
2		Paquet trop grand
3		Délai expiré
3	0	Limite du nombre de sauts atteinte
3	1	Temps de réassemblage dépassé
4		Erreur de paramètre
4	0	Champ d'en-tête erroné
4	1	Champ d'en-tête suivant non reconnu
4	2	Option non reconnue
128		Demande d'ECHO
129		Réponse d'ECHO

 

Détail du message d'ECHO

L'identifiant permet d'identifier le ping. Si on lance 2 ping en parallèle depuis le même PC vers la même IP, on aura ainsi 2 identifiants distincts. Le numéro de séquence est incrémenté par la commande ping à chaque envoi de paquet. Le PC répondant au ping répond avec le même identifiant et le même numéro de séquence.

Le champ "Données" permet d'envoyer un ping avec des données pour simuler l'envoi d'un paquet plus lourd. Ceci est utile pour réaliser des mesures.

 

Découverte des voisins (NDP, Neigbor Discovery Protocol)

Il s'agit de messages encapsulés dans IPv6 de la même manière qu'ICMPv6. Ces messages concernent le voisinage d'un nœud :

• résolution d'adresse IP en adresse MAC
• détection d'adresses IP dupliquées
• auto-configuration d'un équipement à l'aide des messages émis par les routeurs

Message de sollicitation d'un voisin (NS Neighbor Sollicitation)

Ci-dessous le format de ce message.

 

Message d'annonce d'un voisin (NA Neighbor Advertisement)

Ci-dessous le format de ce message.

 

Le bit R est mis a 1 si l'émetteur est un routeur.

Le bit S est mis à 1 si l'annonce est émise suite à une sollicitation

Le bit O mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.

Le champ adresse de la cible reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit S vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse "lien-local". Le champ adresse de la cible contient alors cette nouvelle adresse "lien-local".

L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

 

Exemple de NS / NA pour résoudre une adresse MAC

On considère le cas d'un PC ayant une adresse lien-local ainsi qu'une adresse globale.

Ce PC veut connaître l'adresse MAC associé à une adresse globale

Le PC va émettre un message Neighbor Sollicitation avec le contenu suivant :

En-tête IP, adresse source : l'adresse IPv6 globale de la source

En-tête IP, adresse de destination : l'adresse de multicast sollicitée associée à l'adresse recherchée, et l'adresse Ethernet de destination est l'adresse associée à cette adresse multicast. ATTENTION, l'IP destination n'est pas égale à l'IP destination pour laquelle on recherche l'adresse MAC (car comme l'adresse MAC destination est de type multicast, il faut que l'IP destination soit aussi de type multicast.

Le champ "adresse de la cible" sera valorisé avec l'adresse IP pour laquelle on recherche l'adresse IPv6.

Le PC concerné qui répondra par un message Neighbor Advertisement au message NA répond avec les données suivantes :

En-tête IP source : son adresse lien local (peut paraitre étrange que IP source et destination ne soit pas dans le même scope)

En tête IP destination : l'adresse globale de l'appelant

Adresse cible : l'adresse globale du répondant

Option : l'adresse physique recherchée

 

Cette correspondance adresse IP/adresse MAC est mise en cache par le PC.

Le PC va vérifier régulièrement ce cache par une procédure de détection d'injoignabilité ( Neighbor Unreachability Detection (NUD)).

Dans le cas du NUD, le message NS émis utilisera dans l'en-tête IP l'adresse de destination de type unicast et non plus multicast. C'est un moyen de reconnaître les messages NUD.

 

Auto-configuration des interfaces 

Le but de l'auto-configuration est de simplifier le processus de configuration de l'interface réseau en limitant les actions manuelles. Le but est d'avoir un équipement près à fonctionner sur le réseau et sur internet. Pour permettre aux interfaces réseaux de se configurer automatiquement, la solution s'appuie sur les routeurs et optionnellement sur les serveurs DHCP. Le routeur est donc l'élément central, que l'administrateur configure, qui par la suite diffuse les informations de connectivité aux postes clients.

Les informations minimales pour permettre à une interface réseau d'être opérationnelles sont les suivantes :

• méthode à utiliser pour déterminer son adresse IP (via les messages d'annonce de routeur ou via DHCPv6)
• préfixe de réseau : on peut avoir plusieurs préfixes, le client peut avoir une adresses IPv6 locale à l'entreprise (adresse dite ULA Unicast Local Address) et une adresse IPv6 globale à l'entreprise (adresse dite GLA Global Unicast Address). 
• routeur par défaut
• serveur DNS.

 

Création de l'adresse lien-local

Pour cette adresse, l'interface n'a pas besoin des messages d'annonce de routeur. Pour ces adresses, le préfixe est imposé et vaut fe80::/64.

Pour calculer la partie "identifiant de l'interface", il existe plusieurs méthodes qui dépendent de l'OS.

Nous montrons ici la méthode de calcul basée sur l'adresse MAC de l'interface.

Ci-dessous le principe du calcul de l'identifiant d'interface à partir de l'adresse EUI-48 (adresse MAC)

Quelques explication sur ces champs :

u (Universel) vaut 0 si l'identifiant EUI-64 est universel,
g (Groupe) indique si l'adresse est individuelle (g = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (g = 1), par exemple une adresse de multicast.

Pour le calcul de l'identifiant d'interface, on a préféré valoriser le bit u à 1 pour indiquer que cette adresse est unique. Ainsi, pour le calcul, ce la revient à faire + 2.

Une fois l'adresse lien-local calculée, l'interface vérifie par un DAD que celle-ci est bien unique.

Exemple :

Adresse MAC : 6c-62-cd-9d-08-d7

Calcul : 6c+2=6e

Adresse IPv6 lien-local : fe80::6e62:cdff:fe9d:08d7

 

Auto-configuration sans état (SLAAC Stateless Address AutoConfiguration)

Il s'agit du cas où la configuration ne nécessite pas l'utilisation d'un serveur DHCPv6. Toute la configuration repose sur les messages d'annonce de routeur émis régulièrement. 

La procédure d'auto-configuration est la suivante :

• création de l'adresse lien-local et vérification de son unicité via le mécanisme DAD (Detection Address Duplication). La méthode choise pour déterminer l'adresse lien local dépend des OS. Certains calculent cette adresse en fonction de l'adresse MAC, d'autres par des mécanismes aléatoires.
• envoi d'un message RS (Router Sollicitation) et écoute des messages d'annonce de routeur (message RA Router Advertisement) pour configurer son IP. Le message dira s'il faut passer par un DHCP. Le message RA peut être une réponse au RS ou simplement un RA envoyé périodiquement par le routeur.
• configuration de l'adresse IP en fonction des préfixes réseaux annoncés dans les messages RA
• configuration des routes dont la route par défaut en fonction des messages RA
• configuration du serveur de nom (via RA ou via DHCPv6 si cas de la configuration avec état)
• s'il n'y a pas de message RA, l'interface client cherchera à trouver un serveur DHCPv6 pour obtenir ces informations.

Ci-dessous le format du message d'annonce de routeur RA (Router Advertisement) émis périodiquement par les routeurs :

Il s'agit donc d'un message ICMPv6 de type 134 et de code 0. Ce message contient les champs suivants :

• durée de vie du routeur : indique la durée en seconde pendant laquelle le routeur aura le rôle de routeur par défaut
• durée d'accessibilité : durée, en millisecondes, pendant laquelle une information de ce message contenue dans le cache d'un noeud peut être considérée comme valide; par exemple, la durée de validité d'une entrée dans la table de correspondance entre adresse IPv6 et adresse physique. Au bout de cette période, la procédure de découverte de non-joignabilité (NUD) est entreprise pour vérifier la pertinence de l'information
• temporisation de retransmission : indique en millisecondes la fréquence à laquelle le routeur émet les messages RA. Les nœuds peuvent ainsi en déduire une inaccessibilité du routeur
• le bit M (pour Managed Address Configuration) à 1 indique que la configuration est gérée par DHCPv6, donc l'auto-configuration est dite "avec état". Si ce bit est à 0, l'auto-configuration est de type "sans état" et se réalise avec les informations contenues dans le message RA
• le bit O (pour Other stateful configuration) à 1 indique que le nœud doit interroger le serveur DHCPv6 pour obtenir des informations supplémentaires. Si vaut 0, toutes les informations supplémentaires sont précisées dans le champ "option" du message RA. 

 Ci-dessous le détail du champ Options du message RA quand celle-ci correspond au préfixe à utiliser :

La durée de validité en secondes indique la durée de validité du préfixe. La durée infinie correspond à 0xffffffff.

La durée préférable indique la durée préférée de l'adresse ainsi construite. Au delà, une nouvelle adresse devra être définie. La durée infinie correspond à 0xffffffff.

En IPv6, une adresse IP a en effet les états suivants :

état provisoire : l'adresse IP va être validée via DAD pour vérifier son unicité

état préféré : l'adresse IP est valide

état déprécié : l'adresse IP n'est plus valide pour les nouvelles communications. Elle peut encore servir pour répondre à des répondre à des sessions, mais pas pour en ouvrir de nouvelles; une nouvelle IP a dû être générée.

 

 

Configuration de la table de routage

Le routeur qui a émis les RA avec le préfixe du réseau devient le routeur de la route par défaut.

Il peut cependant y avoir d'autres routes que l'interface doit connaître. Ces routes supplémentaires sont indiquées dans le message RA avec l'option d'information de route.

 

Découverte des serveurs DNS

Dans le cas de l'auto-configuration de l'interface via serveur DHCPv6 (donc auto-configuration avec état), c'est le serveur DHCP qui fournit le ou les serveurs DNS à utiliser. A noter que les spécifications du protocole DHCPv6 avec état (RFC 3315) ont pris 6 ans.

Dans le cas de l'auto-configuration de l'interface sans serveur DHCPv6 (donc auto-configuration sans état), deux solutions sont possibles pour découvrir le DNS.

Ainsi, une des méthodes est de solliciter un serveur DHCPv6 dit "sans état" qui doit fournir en réponse les DNS à utiliser (option DHCPv6 DNS Recursive Name Server).

L'autre méthode repose sur la présence dans le message RA d'une option nommée ND RDNSS (Neighbor Discovery Recursive DNS Server) qui indique les DNS à utiliser.

 

Contrôler la configuration réseau par DHCPv6

Un serveur DHCPv6 peut à la fois servir pour les interfaces en mode auto-configuration avec état mais aussi pour les interfaces en mode auto-configuration avec état.

L'architecture DHCPv6 repose sur les éléments suivants :

le client DHCPv6

le serveur DHCPv6 que le client pourra joindre s'ils se trouvent dans le même réseau

le relai DHCPv6 que le client pourra joindre, qui se chargera de transmettre la demande au serveur DHCPv6 ou à un autre relai DHCPv6.

L'interface (le client DHCPv6), pour joindre le serveur DHCPv6 (ou le relai, mais le client ne le sait pas), celui-ci utilisera l'adresse IPv6 multicast suivante : ff02::1:2 qui identifie le groupe ALL_DHCP_Relay_Agents_And_Servers.

 

Déployer IPv6

La pénurie d'adresse IPv4 est atteinte. Cette pénurie a été compensée par l'utilisation d'adresse IPv4 privées et par l'utilisation du NAT. Le bout en bout initial d'IP n'est plus respecté avec le NAT. 

Certains opérateurs, à cours d'adresses IPv4 publiques dans leur infrastructure, utilisent des adresses IPv4 privées. Ils pratiquent alors un double NAT nommé NAT444. Avec IPv6, plus de problème de pénurie, le NAT n'est plus nécessaire, IPv6 apporte des solutions d'auto-configuration centralisée à partir des routeurs et gère le problème de la mobilité des clients.

Le NAT est vu par certains comme un élément important de sécurité permettant de masquer les utilisateurs et de bloquer les paquets entrants. Mais de nos jours les attaques se font surtout par du contenu malveillant.

Note :

Ci-dessous les préfixes privés en IPv4 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Ces préfixes sont non routables sur l'Internet public, mais les réseaux issus de ces préfixes peuvent être routés sur des topologies privatives (réseaux de campus, réseaux d'entreprise, réseaux domestiques...) .

Déployer IPv6 pose plusieurs problèmes et il existe plusieurs méthodes pour mener à bien cette transition.

Déployer IPv6 ne se fera pas du jour au lendemain, les deux vont cohabiter. On parle alors plus d'intégration d'IPv6 au sein  d'IPv4. 

 

Ci-dessous un graphique qui montre si les serveurs Google sont sollicités en IPv6 ou en IPv4 (IPv6 vu par les serveurs Google) ; en juin 2016, 12% du trafic est en IPv6 :

 

Cette intégration d'IPv6 dans IPv4 nécessite de considérer 6 cas différents :

1. Un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv4;
2. un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv6;
3. un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv4;
4. un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv6;
5. un client IPv4 qui communique avec un serveur IPv6;
6. un client IPv6 qui communique avec un serveur IPv4.

 

Le cas 1 est le point de départ IPv4, le cas 2 est le point d'arrivée IPv6.

Pour faire cohabiter le cas 1 et 2 pour un même hôte travaillant soit en IPv4, soit en IPv6 suivant les applications, cette hôte doit utiliser la technique de la double pile.

Pour le cas 3, on utilise la technique du tunnel IPv6 dans IPv4; il faut que ces tunnels traversent le moins de routeurs IPv4 possibles.

Pour le cas 4, on utilise la technique du tunnel IPv4 dans IPv6.

Pour le cas 5, il faut mettre en place des techniques de traduction.

La démarche de déploiement d'IPv6 est décrite dans la RFC 7381.

 

Technique de la double pile

C'est la technique indispensable qui nécessite un double paramétrage , celui des hôtes et celui des routeurs. Cette solution ne résoud pas les problème de la pénurie des adresses IPv4. Mais il noter que le client utilisera en premier l'adresse IPv6. Il faudra progressivement que tout passe par IPv6.

Les applications "métiers", développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits.

 

Déploiement d'IPv6 pour les services

Il faut donc que les applications puissent fonctionnel à la fois en IPv4 ou en IPv6 suivant que la destination soit en IPv4 ou en IPv6. L'application doit donc admettre une adresse sur 128 bits.  Une adresse IPv6 incluant IPv4 a été définie pour cette problématique, la couche réseau en double pile étant alors capable de comprendre s'il faut utiliser IPv4 ou IPv6. Ces adresses sont dites "IPv4 mapped IPv6 address" et ont la forme suivante :

::ffff:ipv4 address

Ci-dessous l'application Telnet qui utilise IPv4 ou IPv6 suivant l'adresse à atteindre :

 

Problèmes liés à la double pile

Le problème sont les suivants :

temps trop long pour établir la connexion IPv6 et échec de celle-ci. Ceci peut arriver, car il se peut que le paquet emprunte des chemins en IPv4 (tunnel), donc la charge utile est plus faible, le routeur doit envoyer des messages ICMP "paquet trop gros" et les routeurs bloquent ces paquets. Si le serveur à joindre possède aussi une adresse IPv4, la connexion se fera en IPv4, mais tout ceci aura pris du temps, l'utilisateur trouvera que le service est très dégradé. A noter que les clients qui demande la résolution d'un nom obtient en réponse l'adresse IPv6 et IPv4, il utilisera en premier l'adresse IPv6. Le temps de réponse en IPv6 peut être d'autant plus long si on utilise des tunnels IPv4 trop éloignés du point d'arrivée.

 

Pour pallier à ce temps de connexion trop long, la RFC 6555 propose d'établir simultanément une connexion en IPv4 et en IPv6, puis de garder la première connexion établie. Ainsi, les navigateurs web utilisent diverses stratégies comme expliqué ci-dessous.

- Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.
- Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports "source" différents. Si aucun segment SYN + ACK n’est  reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés.
- Le navigateur Firefox implémente strictement les recommandations du RFC 6555 et essaye les deux protocoles en parallèle.

Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (e.g. mail, VoIP, chat...). Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.
Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources.  

 

Tunnel IPv6 sur IPv4 

Comme le montre le schéma ci-dessous, il faut que le tunnel soit le plus court possible pour obtenir de bonnes performances. Les tunneliers sont, dans cet exemple, des routeurs en double pile.

 

Ceci nécessite de configurer des tunnels, ce qui prend du temps, d'où la notion de tunnel automatique exprimée ci-après.

 

Tunnel automatique

Des solutions d'automatisation ont été étudiées, qui ont comme principe de contenir l'adresse IPv4 du tunnelier de destination dans l'adresse IPv6. La technique de transition 6to4 décrite par le RFC 3056 suit ce principe. Elle vise à interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données. La figure ci-dessous montre 2 réseaux IPv6 communiquant entre eux via un tunnel automatique 6to4. Le point fort du mécanisme présenté ici est l'automatisation, où l'intervention de l'administrateur est réduite à une phase de "configuration/initialisation" du service, et non à une phase de configuration des tunnels. 

Pour que ce mécanisme soit automatique, il faut que les adresses globales ait un format particulier dit 6to4. Cette adresse contient l'adresse IPv4 du routeur 6to4 permettant d'accéder à l'hôte.

Ainsi, une adresse 6to4 a le format suivant :

Le préfixe est de la forme  2002::/16.

Suit ensuite l'adresse IPv4 du routeur 6to4 qui gère la zone de l'hôte

Ci-dessous l'exemple d'un hôte A IPv6 voulant joindre un hôte B IPv6 via un tunnel IPv4. Ces deux hôtes ont de adresses 6to4, les pattes IPv4 des routeurs 6to4 sont donc connues.

Au niveau du routage, la figure ci-dessous présente l'envoi d'un paquet IPv6 de l'hôte A vers l'hôte B. Il est important de noter ici que A et B sont des hôtes ayant une adresse IPv6 prise dans le plan d'adressage 6to4 . Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. Dans notre exemple, la réponse est 2002:c000:301:1::8051 . Dans un second temps, l'hôte A émet le paquet vers cette destination. Ce paquet IPv6, dont l'adresse de destination commence par le préfixe 2002::/16 , doit passer par un tunnel 6to4 . C'est au routeur 6to4 du site de A qu'il revient d'effectuer cette opération. Ainsi, le paquet doit suivre la route IPv6 2002::/16 pour atteindre ce routeur 6to4 . Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel ( 192.0.3.1 dans l'exemple). Il pourra alors effectuer la transmission en encapsulant le paquet IPv6 dans un paquet IPv4. C'est cette encapsulation qui forme le tunnel. Le routeur 6to4 du coté de B désencapsule le paquet  Pv6 et  le route normalement vers sa destination finale B en utilisant le routage interne.

Cette technique est adaptée à des sites IPv6 isolés non connectés à l'Internet v4.

Cette technique n'est pas adapté si l'adresse IPv6 est prise dans le plan d'adressage globale. De plus, la route aller n'est pas forcément égale à la route retour. Cette technique est déprécié et est remplacé par une technique similaire dite 6rd.

 

Connectivité d'un site isolé via un tunnel broker

Un intermédiaire, le tunnel broker, crée le tunnel à la demande. Ce mécanisme s'appuie sur un protocole nommé TSP ( Tunnel Set Up Protocol ).

 

Tunnel 6rd

Cette solution (imaginée par Free) est destiné à un opérateur pour offrir une connectivité IPv6 alors que son infrastructure repose sur IPv4. Cet opérateur peut être aussi bien public, comme un FAI, ou privé, comme une entreprise ou une administration. Cette solution reprend le principe du 6to4 en ayant supprimé les défauts.

La différence majeure se situe sur l'utilisation du préfixe IPv6 propre à l'opérateur plutôt que le préfixe commun à tous, employé par 6to4 ( 2002::/16 ). Il s'ensuit que l'opérateur doit installer ses propres relais pour offrir la connectivité avec l'Internet v6. Le relais est un routeur de bordure équipé en "double pile". Dans la figure 12, qui schématise l'architecture de 6rd , le routeur de bordure est noté, selon la terminologie du RFC 5969 , " 6rd BR"( Border Relays ). Le préfixe IPv6 propre à cet opérateur est noté "pref6rd". En contrepartie de l'installation des relais, l'opérateur contrôle les tunnels. Il peut ainsi garantir que la voie "retour" est symétrique à la voie "aller". Autre conséquence, les tunnels sont plus courts: ils servent à passer la section IPv4 de l'opérateur. En contrôlant les tunnels, les principaux défauts du déploiement de 6to4 , comme des délais importants ou l'asymétrie, sont corrigés. Avec 6rd , on se retrouve dans le cas classique où les routeurs internes (dont les relais) traitent le trafic des noeuds internes. Ainsi, ces relais ne servent que les clients de l'opérateur (contrairement à 6to4 où les relais étaient mutualisés et publics).

 

 

Bibliographie

Ces notes sur IPv6 sont fortement tirées du MOOC "Objectifs IPv6" (excellent MOOC) de Bruno Stévant, Jacques Landru, Jean-Pierre Rioual, Pascal Anelli, Bruno Joachim, Joël Grouffaud, Pierre Ugo TOURNOUX. Merci aux auteurs pour la qualité du cours.

Ci-dessous un lien vers un aide-mémoire tenant sur une seule page pdf : Mémo en-tête IPv6