Académique Documents
Professionnel Documents
Culture Documents
L'ADRESSAGE IPV6 1
1 GENERALITES 2
1.1 STRUCTURATION DES ADRESSES ET AGREGATION 2
2 PLANS D'ADRESSAGE 3
2.1 REPRESENTATION DES ADRESSES IPV6 3
2.2 LES 3 TYPES D’ADRESSES IPV6 3
2.2.1 ADRESSES UNICAST GLOBALES – 2000::/3 4
2.2.2 IDENTIFIANT D’INTERFACE 6
2.2.3 ADRESSES LIEN LOCAL – FE80::/10 8
2.2.4 ADRESSES UNIQUES LOCALES (UNIQUE LOCAL UNICAST, EX SITE LOCAL ADDRESS) - FC00::/7 9
2.2.5 ADRESSES PARTICULIERES QUI N’UTILISENT PAS L’INTERFACE ID 10
2.2.6 ADRESSES MULTICAST - FF00::/8 11
2.2.7 ADRESSES ANYCAST 12
2.3 DUREE DE VIE DES ADRESSES 13
2.3.1 ÉTATS DES ADRESSES AUTOMATIQUEMENT CONFIGUREES 14
2.3.2 TYPES DE CONFIGURATION AUTOMATIQUE 14
2.3.3 PROCESSUS DE CONFIGURATION AUTOMATIQUE 15
3 PROTOCOLES RESEAUX EN V6 15
3.1 LE PROTOCOLE IPV6 15
3.1.1 EN-TETE IPV6 16
3.1.2 EN-TETE D'EXTENSION (NEXT HEADER DE TYPE OPTION) 19
4 LE PROTOCOLE ICMPV6 19
4.1 CONFIGURATION AUTOMATIQUE D’IPV6 21
4.1.1 DECOUVERTE DE SES VOISINS (NEIGHBORS DISCOVERY PROTOCOL - NDP) 21
4.1.2 LES MESSAGES ICMPV6 DE DECOUVERTE DE SES VOISINS 22
4.2 CONFIGURATION AUTOMATIQUE 26
4.2.1 PROCEDURE D’AUTO-CONFIGURATION D’ADRESSE 26
4.2.2 PROCEDURE DE DETECTION D’ADRESSE DUPLIQUEE (ALGORITHME DAD) 26
1 Généralités
Le format et la représentation des adresses sont les modifications les plus visibles pour l'utilisateur
dans cette nouvelle version du protocole. Même si les principes sont fortement similaires à ceux
employés dans IPv4, cet adressage apparaît beaucoup plus complexe. Il est intéressant d'en
comprendre le principe et les règles d'attribution avant d'aborder les aspects protocolaires.
Une adresse IPv6 est un mot de 128 bits. La taille d'une adresse IPv6 est le quadruple de celle
d'une adresse IPv4. Certains calculs indiquent que l'on pourrait potentiellement attribuer 667 millions
de milliards d'adresses par mm2 de surface terrestre.
La figure suivante donne l'évolution moyenne de la table de routage d’un routeur situé dans le
cœur de l'Internet, c'est-à-dire dans les réseaux des opérateurs où aucune route par défaut n'est définie.
(la référence 00 correspond à l’année 2000- source Association G61).
1
http://g6.asso.fr/
Adressage IPv6 – Référence http://livre.g6asso.fr Page n° 2
Michel MARIE
2 Plans d'adressage
2.1 Représentation des adresses IPv6
La représentation d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de
16 bits (4 quartets hexadécimaux) ou blocs séparés par le caractère :
Par exemple :
FE00:CD66:0000:0000:0000:0AAA:5678:1234
Dans un champ, il n'est pas nécessaire d'écrire les zéros placés en tête, l’adresse précédente peut donc
s’écrire :
FE00:CD66:0:0:0:AAA:5678:1234
Les ensembles de blocs de 4 quartets entièrement à 0 peuvent-être remplacés par :: mais une seule fois
par adresse pour lever toute ambiguïté. L’adresse précédente peut donc s’écrire :
FE00:CD66::AAA:5678:1234
La notation du préfixe IPv6 est calquée sur la notation CIDR définie pour IPv4 dans la RFC 1519 :
<préfixe-ipv6> / <longueur du préfixe>
Le caractère : utilisé pour séparer les mots peut créer des ambiguïtés. C'est le cas avec les URL où il est aussi
utilisé pour indiquer le numéro de port. Ainsi l'URL suivante est un point de communication visant le port 80
ou le port 8000 ?
http://2001:1234:12::1:8000/
Pour lever cette ambiguïté, le RFC 2732 propose d'inclure l'adresse IPv6 entre crochets "[ ]". L'URL
précédente visant le port 8000 s'écrirait :
http://[2001:1234:12::1]:8000/
Le premier de ces types, le type unicast, est le plus simple. Une adresse de ce type désigne une interface
unique. Parmi les adresses unicast, on peut distinguer celles qui auront une portée globale, c'est-à-dire
désignant sans ambiguïté une machine sur le réseau Internet « Adresse Unicast Globale » et celles qui auront
une portée locale (lien ou site « Adresse Lien Locale »). Ces dernières ne pourront pas être routées sur
l'Internet.
Une adresse de type multicast désigne un groupe d'interfaces qui en général appartiennent à des nœuds
différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une adresse de
type multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.
Il faut noter qu'il n'y a plus d'adresses de type broadcast comme sous IPv4 ; elles sont remplacées
par des adresses de type multicast qui "saturent" moins un réseau local constitué de commutateurs.
Le dernier type, anycast, est une officialisation de propositions faites pour IPv4 RFC 1546. Comme
dans le cas du multicast, une adresse de type anycast désigne un groupe d'interfaces, la différence étant que
lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des éléments du groupe et non pas à
tous. C'est, par exemple, le plus proche au sens de la métrique des protocoles de routage. Cet adressage est
encore aujourd’hui principalement expérimental.
Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source IANA)
donne la liste de ces préfixes. La plage «réservée» du préfixe 0::/8 est utilisée pour les adresses spéciales. On
3 45 16 64
Cet espace est géré hiérarchiquement comme pour IPv4 par L'IANA (ICANN).
L'IANA délègue aux 5 autorités régionales « RIR (Regional Internet Registries)» des préfixes
plus ou moins longs /23 à /12 qui les redistribuent aux opérateurs régionaux ou fournisseurs
d’accès « LIR (Local Internet Registries) ».
Pour l’Europe la distribution est à la charge du RIPE - NCC « Réseaux IP Européens - Network
Coordination Center ».
le premier niveau de hiérarchisation, champ pTLA (pseudo Top Level Aggregator) sur x bits (8
ou 12) correspond à l’identification du fournisseur d’accès de transit à Internet,
le deuxième niveau de hiérarchisation, champ pNLA (pseudo Next Level Aggregator) sur 32-X
bits est défini et découpé par l’autorité désignée dans le champ précédent,
le troisième niveau de hiérarchisation, champ SLA (Site Level Aggregator) sur 16 bits désigne le
site local connecté au fournisseur d'accès et permet à l'administrateur de ce site de hiérarchiser son
plan d'adressage (sous-réseaux).
Les pseudo-TLA ont été alloués jusqu'en décembre 2003 aux opérateurs qui en faisaient la demande. Ces
adresses ont été restituées et ne sont plus utilisable depuis juin 2006.
Les types d'adresses globales ou lien-local utilisent un identifiant sur 64 bits pour désigner une
interface connectée sur un lien.
Plusieurs techniques ont été élaborées à l'IETF pour calculer cet identifiant d’interface :
la plus répandue est basée sur l'utilisation d'une valeur unique qu’est l'adresse MAC de la carte
réseau,
mais l'on peut également choisir une valeur aléatoire pour garantir plus de confidentialité,
ou au contraire la dériver d'une clé publique pour mieux authentifier l'émetteur du message,
enfin dans certains cas l'affectation manuelle de cette valeur peut se justifier (serveurs).
La taille de 64 bits permet de réduire à une valeur proche de zéro la probabilité de conflits.
Si une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite ci-dessous.
Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et
les 40 autres bits identifient le numéro de série. Les 2 bits U (septième bit du premier octet) et G
(huitième bit du premier octet) ont une signification spéciale :
U (Universel) vaut 0 si l'identifiant EUI-64 est universel, (U=0 Global Scope ; U=1 Local Scope)
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.
IEEE EUI64
24 bits 40 bits
Constructeur (6 bits) U G Constructeur (16 bits) Numéro de série
Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle, cette adresse est utilisée pour
construire des identifiants d'interface sur 64 bits, comme indiqué sur la figure ci-dessous. On remarquera
que l'identifiant d'interface à 64 bits (IID) est dérivé de l'EUI-64 en inversant le bit U, il a été préféré
utiliser un 1 pour marquer l’unicité mondiale de l’identifiant. L’identifiant d’interface IPv6 présentera
donc le bit U à 1 et le bit G à 0.
24 bits
Constructeur
(6 bits) U G Constructeur (16 bits) 0xFF 0xFE Numéro de série (24 bits) EUI64
U G
Constructeur identifiant
(6 bits) 1 0 Constructeur (16 bits) 0xFF 0xFE Numéro de série (24 bits) IPv6
L'utilisation de l'adresse MAC pour construire l'adresse IP de la machine peut conduire dans certains
cas à des problèmes de configuration, en particulier si la machine est un serveur. En effet, s'il l'on change
la carte Ethernet de l'équipement (voire l'équipement) l'adresse IPv6 qui en dépend change également et
tous les applicatifs clients utilisant cette adresse seraient à reconfigurer.
Il est donc possible d’attribuer un identifiant « manuellement ».
L'identifiant d'interface tel qu'il a été défini précédemment pourrait poser des problèmes pour la vie
privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau
garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au
bureau, lors de ses déplacements.
Pour couper court à toute menace qui «menacerait la vie privée», il a été proposé d'autres algorithmes
de construction d'un identifiant d'interface basé sur des tirages aléatoires (RFC 3041). Un utilisateur
particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi
aléatoirement, soit construit par un algorithme comme MD5. Périodiquement l'adresse est mise dans l'état
«déprécié» et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser
l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.
Contrairement à Linux ou Mac OS-X cette solution est utilisée par défaut sur les OS Microsoft depuis
Windows 7. Par exemple chaque interface IPv6 dispose de deux adresses IPv6 globales, une préférée
(stable) qui peut être diffusée par un DNS et qui sert pour les connexions entrantes et une temporaire
(durée de vie = 1 jour) qui sert pour les connexions sortantes.
C:\Users\Michel>ipconfig /all
Carte réseau sans fil Connexion réseau sans fil :
Adresse physique . . . . . . . . . . . : 00-25-00-46-7B-B9
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a01:e34:ef48:20:ad93:ef4b:7794:727a (préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e34:ef48:20:5919:4c3f:dffb:1a3a(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::ad93:ef4b:7794:727a%12(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.50(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : vendredi 27 novembre 2015 12:03:08
Bail expirant. . . . . . . . . . . . . : samedi 28 novembre 2015 01:03:03
Passerelle par défaut. . . . . . . . . : fe80::160c:76ff:fe6d:bf09%12
192.168.1.254
Serveur DHCP . . . . . . . . . . . . . : 192.168.1.254
Serveurs DNS. . . . . . . . . . . . . : 192.168.1.254
Les adresses de type lien-local sont des adresses dont la validité est restreinte à un lien, c'est-à-dire
l'ensemble des interfaces directement connectées sans routeur intermédiaire. Les adresses lien-local sont
configurées automatiquement à l'initialisation de l'interface et permettent la communication uniquement
entre nœuds voisins (domaine de diffusion de couche 2).
10 54 64
FE80 0 Identifiant ou Interface ID
Ces adresses sont utilisées par les protocoles de découverte de voisins « Neighbor Discovery »
(qui remplace ARP) et de découverte de routeurs « Router Discovery ». Ces protocoles permettent à un
réseau local de s’auto-configurer.
Les adresses lien-local sont uniques à l'intérieur d'un lien. Un protocole de détection de
duplication d'adresse permet de s'en assurer (DAD).
Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination
une adresse de type lien-local.
Puisque toutes les interfaces disposant d’une adresse lien local partagent le même préfixe fe80::/10 rien
ne permet dans l’adresse de décider de l’interface de sortie associée. Il faut donc indiquer de manière
explicite sur quelle interface doivent être émis les paquets associés à une adresse lien local spécifique. Sur
certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la
fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument,
généralement -I permet de la désigner.
Les adresses de type site-local (initialement préfixe FEC0::/48) ayant été supprimées du standard
IPv6 (RFC 3879), la RFC 4193 définit un nouveau format d'adresse unicast, les adresses uniques locales
(ULA : Unique Local Address).
Ces adresses sont destinées à une utilisation locale (Equivalentes aux adresses de réseaux privés
IPv4). Elles ne sont pas définies pour être routées dans l'Internet, mais seulement au sein d'une zone
limitée telle qu'un site ou entre un nombre limité de sites. Les adresses uniques locales ont les
caractéristiques suivantes :
préfixe globalement unique,
préfixe clairement définit facilitant le filtrage sur les routeurs de bordure,
permet l'interconnexion de sites (via VPN) sans générer de conflit d'adresse et sans nécessiter de
renumérotation,
indépendantes des fournisseurs d'accès à l'Internet.
Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe
privé associé à la NAT permet de passer de l'adressage privé vers l'adressage public.
Avec les Adresses Uniques Locales, il est possible de reproduire ce comportement en IPv6 en
convertissant le préfixe privé en préfixe public. Ce mécanisme, initialement appelé NAT66, a été
renommé NPTv6 (Network Prefix Translation).
Aucune différence pour les applications, qui peuvent les considérer comme des adresses globales unicast
standard.
Les adresses uniques locales sont créées en utilisant un identifiant global (Global ID) généré pseudo-
aléatoirement à partir de l'heure et de l'adresse MAC. Ces adresses suivent le format suivant :
7 1 40 16 64
Préfixe (7 bits) : FC00::/7 préfixe identifiant les adresses IPv6 locales (ULA),
L (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une
utilisation future,
o en résumé, préfixe actuellement utilisable : FD00/8
Global ID (40 bits) : identifiant global utilisé pour la création d'un préfixe unique, d’après le
standard doit être généré par un générateur pseudo aléatoire respectant la description RFC4193.
Subnet ID (16 bits) : identifiant d'un sous réseau à l'intérieur du site.
a) Adresse indéterminée. ::
L'adresse indéterminée « Unspecified Address » est utilisée comme adresse source par un nœud du
réseau pendant son initialisation, avant d'acquérir une adresse.
Sa valeur est 0:0:0:0:0:0:0:0 (en abrégé ::).
Cette adresse est utilisée uniquement par des protocoles d'initialisation, elle ne doit jamais être attribuée à
un nœud et ne doit jamais apparaître comme adresse destination d'un paquet IPv6.
L'adresse de bouclage « Loopback Address » vaut 0:0:0:0:0:0:0:1 (en abrégé ::1). C'est l'équivalent
de l'adresse 127.0.0.1 d'IPv4. Elle est utilisée par un nœud pour s'envoyer à lui-même des paquets IPv6.
Un paquet IPv6 transitant sur le réseau ne peut avoir l'adresse de bouclage comme adresse source ni
comme adresse destination.
Ces adresses permettent à une machine IPv6 de communiquer en IPv4 avec une machine IPv4 tout en
restant dans la famille d'adresse AF_INET6.
Ces adresses servent à identifier pour la pile IPv6 des adresses destinataires IPv4. En fait, une adresse IPv6
de type IPv4 mappée n'apparaît jamais sur le réseau sous cette forme, mais bien sous sa forme IPv4.
En émission, la machine, voyant une adresse destination IPv4 mappée dans un datagramme IPv6, extrait
l'adresse IPv4, utilise la pile de communication IPv4 puis envoie des paquets IPv4 ; en réception, une requête
IPv4 est reçue par la pile IPv4 puis présentée aux applications sous la forme d'une requête IPv6 comportant
des adresses de type IPv4 mappées. Une adresse mappée n'est pas censée apparaître dans l'en-tête IPv6.
Une adresse de type Multicast désigne un groupe d'interfaces qui en général appartiennent à des
nœuds différents pouvant être situés n'importe où dans l'Internet. Lorsqu'un paquet a pour destination une
adresse de type Multicast, il est acheminé par le réseau à toutes les interfaces membres de ce groupe.
Rappelons qu’avec IPv6 il n'y a plus d'adresses de type Broadcast comme sous IPv4, elles sont
remplacées par des adresses de type Multicast.
Il existe deux modèles de communication multicast :
le modèle ASM (Any-Source Multicast), un récepteur s'abonne à un groupe, et reçoit les
données émises par n'importe quelle source de ce groupe (visioconférences),
le modèle SSM (Source-Specific Multicast), les sources sont connues à l'avance et les récepteurs
s'abonnent à un groupe associé à une source (TV ou radio sur Internet).
Certaines adresses de multicast sont prédéfinies et donc permanentes (T=0). Par exemple :
ff02::1 = groupe multicast de tous les nœuds du lien,
ff02::2 = groupe multicast de tous les routeurs du lien,
ff02::5 = tous les routeurs de l’aire OSPF (224.0.0.5 en IPv4) du lien,
ff02::6 = tous les routeurs désignés OSPF (224.0.0.6 en IPv4) du lien,
Remarque : l’adresse de sollicitation de nœud est utilisée par une station du réseau qui connaît l'adresse
IPv6 d'une station à joindre mais en ignore son adresse physique (Mac). Elle est utilisée par ICMPv6,
entre autre, pour assurer la même fonction que le protocole ARP en IPv4.
L’adresse Mac associée au multicast IPv6 est constituée de 33-33 suivis des 4 octets LSB de l’adresse
IPv6.
Exemple :
Soit le nœud d’adresse MAC : 00-BB-00-BB-BB-BB
et d’adresse lien local : FE80::2BB:FF:FEBB:BBBB
L’adresse multicast de sollicitation de ce nœud sera : FF02::1:FFBB:BBBB
Et l’adresse MAC multicast associée sera : 33-33-FF-BB-BB-BB
Remarque : une étude sérieuse des adresses et protocoles associés aux échanges multicast (MLD
Multicast Listener Discovery), D-PIM(Domaine Protocol Independant Multicast) sort du cadre fixé par
ce document et nécessiterait une formation à elle seule, elle ne sera donc pas traitée ici…
Une adresse de type Anycast désigne un groupe d'interfaces, la différence avec l’adresse Multicast
réside dans le fait que lorsqu'un paquet a pour destination une telle adresse, il est acheminé à un des
éléments du groupe et non pas à tous. Les adresses Anycast utilisent le plan d'adressage des adresses
unicast. Une adresse Anycast est simplement une adresse unicast affectée à plus d'une interface…
Les nœuds auxquels l'adresse Anycast est affectée doivent être explicitement configurés pour reconnaître
que l'adresse est une adresse Anycast.
Une adresse Anycast ne doit jamais être utilisée comme adresse source d'un paquet IPv6.
Exemple : Adresse du serveur DNS racine le plus proche parmi les 13 serveurs racine mondiaux.
f.root-servers.net : 2001:500:2f::f
Certaines adresses anycast sont réservées pour désigner un service spécifique, ce même service
pouvant se trouver sur différents réseaux tels des réseaux d'opérateurs (exemple le service "Home Agent"
permettant la mobilité entre opérateurs de téléphonie mobile).
Une adresse Anycast réservée est constituée d'une partie préfixe de réseau identique à celle utilisée pour
les adresses Unicast et d'une partie Identifiant Anycast spécifique du service.
Contrairement aux structures d'adresses vues précédemment, la longueur de ce préfixe n'est pas
spécifiée afin de pouvoir s’adapter aux futurs plans.
Exemple : recherche du serveur « Home Agent » utilisé pour la gestion de la mobilité au sein des réseaux
d’opérateurs.
Id Anycast réservé = 7E
Exemple, Préfix réseau /64 = 2A01:E34:EF48:20
Adresse Anycast : 2A01:E34:EF48:20:FDFF:FFFF:FFFF:FF7E
Les adresses automatiquement configurées présentent au moins l'un des états suivants :
Tentative : l'adresse se trouve dans le processus de vérification de son unicité. La vérification
repose sur la détection des adresses en double DAD (Duplicate Address Detection).
Préféré : adresse dont l'unicité a été vérifiée. Un nœud peut envoyer et recevoir un trafic
monodiffusion en direction et en provenance d'une adresse préférée.
Déprécié : adresse toujours valide, mais dont l'utilisation n'est pas recommandée. Seules les
sessions de communication existantes peuvent continuer à utiliser une adresse désapprouvée.
Valide : adresse pouvant recevoir et émettre du trafic monodiffusion. L'état Valide couvre les
deux états "Préféré" et "Désapprouvé". La durée pendant laquelle une adresse demeure dans les
états "Tentative" et "Valide" figure dans le message d'annonce de routeur. La durée de vie valide
doit être supérieure ou égale à la durée de vie préférée.
Non valide : adresse pour laquelle un nœud ne peut plus envoyer ou recevoir de trafic
monodiffusion. Une adresse entre dans l'état "Non valide" lorsque la durée de vie valide arrive à
expiration.
Pour tous les types de configuration automatique, une adresse lien-local est toujours configurée.
5. Si cela est spécifié dans le message d'annonce de routeur, l'hôte utilise un protocole de
configuration d'adresse avec état pour obtenir des adresses ou des paramètres de configuration
supplémentaires.
3 Protocoles réseaux en v6
3.1 Le protocole IPv6
Le protocole IP a subi un toilettage reprenant l'expérience acquise au fil des ans avec IPv4. Le format
des en-têtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements.
Les principales modifications apportées sont :
l'en-tête ne contient plus le champ checksum, (recalculé par chaque routeur à cause du TTL),
celui-ci est à la charge des protocoles de niveau supérieur,
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 sur les nouvelles
architectures 64 bits,
la taille minimale des MTU (Maximum Transmission Unit) est de 1 280 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. 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.
0 15 16 31
Ver = 4 LET Type de service Longueur totale
(4bits) (4bits) (8bits)
Identification Flags Fragment Offset
Durée de vie (TTL) Protocole Contrôle
Adresse source (4 octets)
Adresse de destination (4 octets)
Options + Bourrage
Data
En tête IPv6
0 15 16 31
Ver= 6 Classe de trafic Identificateur de flux (Flow Label)
(4bits) (8 bits)
DSCP (6bits)+ECN(2bits)
Taille (Payload length) Prochain en-tête Nbr sauts maxi
(Hop limit)
Les champs ayant disparus de l'en-tête IPv4 sont représentés en italique, ils sont :
le champ LET (Longueur En-Tête) qui n'a plus d'intérêt puisque la longueur est fixe,
les champs Identification, Flags et Fragment Offset qui servaient lors de la fragmentation
disparaissent puisque la fragmentation ne devrait plus avoir lieu au sein du réseau, si elle est
nécessaire elle sera gérée dans un en-tête optionnel spécifique,
le champ de Contrôle, le contrôle de TCP ou UDP (qui devient obligatoire) étant suffisant,
le champ des Options, les options étant à présent gérées par des en-têtes additionnels.
Les champs ayant été modifiés mais gardant leur objectif initial sont :
la version, qui laisse encore de la marge de manœuvre !
le type de service est remplacé par les champs "Classe de trafic" qui permet de différentier les
services et de signaler un risque de congestion, en correspondante avec l’"Identificateur de flux"
utilisé par une source pour nommer des séquences de paquets pour lesquels un traitement spécial
de la part des routeurs IPv6 est demandé,
o DSCP « DiffServ Code Point » valeurs des comportements souhaités quant au type de
service,
o ECN « Explicit Congestion Notification » gestion de la congestion.
le champ longueur totale est remplacé par la taille des données transportées "Payload length",
le champ "Next Header" joue le rôle du champ protocole d’IPv4, il contient l’identification du
protocole transporté si aucune option n'est ajoutée, sinon il contient une indication sur le type de
l’en-tête suivant. Le tableau ci-dessous donne quelques valeurs possibles pour ce champ,
le compteur de saut remplace le champ durée de vie, il est toujours décrémenté d'une unité par
chaque routeur traversé et vaut 64 par défaut.
Le comportement Voice Admit a été proposé dans le RFC 5865 pour affiner le traitement de flux temps
réels de différentes natures (Voix, Vidéo, Signalisation Temps réel…).
Si le récepteur reçoit la combinaison CE, il le signale à l’émetteur via la réponse TCP en marquant le flag
TCP ECE, l’émetteur diminuera ainsi la taille de ses paquets et signalera cette réduction dans son
prochain paquet TCP en marquant à son tour le flag TCP CWR. Ce mécanisme d’aller-retour est
poursuivi tant que la congestion est signalée.
L'utilisation de ECN sur une connexion TCP est optionnelle : pour qu'elle soit utilisée, cela doit avoir été
négocié lors de l'établissement de la connexion en marquant les flags ECN et CWR dans les segments
SYN et SYN-ACK.
0 15 16 31
Ver= 6 Classe de trafic Identificateur de flux
(4bits) (8 bits)
Taille (Payload length) Prochain en-tête Nbr sauts maxi
= 0 (Hop by Hop)
Adresse source
Adresse destination
4 Le protocole ICMPv6
Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol)
sert :
à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...),
au test (par exemple ping),
à la configuration automatique des équipements (redirection ICMP, découverte des routeurs).
Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions
de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le
protocole IGMP (Internet Group Message Protocol) dans IPv4.
ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.
0 7 8 15 16 31
Type (8bits) Code (8 bits) Checksum
Options
Les messages ICMPv6 de compte rendu d'erreur contiennent le paquet IPv6 ayant provoqué l'erreur.
Pour éviter des problèmes de fragmentation, la longueur du message ICMPv6 est limitée à 1 280 octets et
par conséquent le contenu du paquet IPv6 peut être tronqué.
Information
Type Code
128 Demande d'écho
129 Réponse d'écho
Comme précisé au paragraphe ICMPv6, le protocole utilise cinq types de messages ICMPv6.
Le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255, 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é.
Avec IPv6, Il est possible qu'un matériel ne connaisse pas tous les préfixes de son réseau local (si
celui-ci est partagé par plusieurs préfixes), ou qu'un préfixe soit partagé entre plusieurs liens.
Dans certaines configurations, la machine émettra ses paquets au routeur alors que le destinataire se
trouve sur le même segment que l'émetteur. Si c'est le cas, le routeur émettra un message de redirection
pour que la suite du dialogue se fasse directement.
Dans le cas le plus extrême, on peut imaginer en IPv6 qu'un équipement puisse être configuré pour
dialoguer uniquement avec son routeur par défaut. ICMPv6 «redirect» est alors utilisé pour informer
l'équipement des destinataires sur le même lien.
Ce message permet d'obtenir des informations d'un équipement voisin, c'est-à-dire situé sur le même
lien physique. Le message peut lui être explicitement envoyé ou émis sur une adresse de groupe multicast
de sollicitation de nœud FF02::1:FF00:0/104 (si multidiffusion, équivaut à la requête ARP du protocole
IPv4).
Le champ adresse IPv6 source contient soit l'adresse locale au lien adresse lien-local, soit une adresse
globale, soit l'adresse non spécifiée. Le champ adresse IPv6 destination contient soit l'adresse de multicast
sollicitée, soit l'adresse de l'équipement dans le cas d’une détection d’inaccessibilité (NUD). La détection
NUD (Neighbor Unreachability Detection) permet d'effacer dans le cache des voisins les entrées
correspondantes aux voisins inaccessibles.
0 7 8 15 16 31
Type = 135 Code =0 Checksum
Réservé
Cible = Adresse IPv6 du voisin recherché
Option = Adresse physique de l'émetteur
Ce message est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour
propager une information de changement d'adresse physique, ou de statut «routeur».
0 7 8 15 16 31
Type = 136 Code =0 Checksum
Flags :RSOxxxxx Réservé
Cible = (S=1)Adresse IPv6 du voisin sollicité OU (S=0) Adresse lien local émetteur
Option = Adresse physique de l'émetteur
Ce message est émis à l'adresse IPv6 de multicast groupe 2, portée lien local (scope = 2) FF02::2
« tous les routeurs du lien » par un équipement au démarrage pour recevoir plus rapidement des
informations du routeur. Si l'équipement ne connaît pas encore son adresse IPv6 source, l'adresse IPv6
non spécifiée est utilisée.
0 7 8 15 16 31
Type = 133 Code =0 Checksum
Réservé
Options = Adresse physique de l'émetteur
Ce message est émis périodiquement par les routeurs ou en réponse à un message de sollicitation. Le
champ adresse IPv6 source contient l'adresse locale au lien du routeur, le champ IPv6 destination contient
soit l'adresse de l'équipement qui a émis la sollicitation, soit l'adresse groupe 1, portée lien local (scope =
2) FF02::01 « tous les nœuds du lien ».
0 7 8 15 16 31
Type = 134 Code =0 Checksum
Nbr Saut max Flags : MOHxxxxx Durée de vie du routeur
Durée d’accessibilité
Temporisation de retransmission
Options = Adresse physique de l'émetteur, préfixe(s), MTU, serveur DNS
Les flags M et O sont importants, en ce sens qu'ils déterminent le mode d'attribution des adresses IPv6
des hôtes recevant les annonces du routeur. En résumé, les 3 modes suivants sont envisageables :
M = 0 et O = 0 => Mode SLAAC (Stateless Address Autoconfiguration). La
configuration IPv6 de l'hôte est auto-configurée à l'aide de l'annonce du routeur et de ses
options. Aucun serveur DHCPv6 n'est nécessaire.
M = 0 et O = 1 => Mode DHCPv6 Stateless. La configuration IPv6 de l'hôte est auto-
configurée à l'aide de l'annonce du routeur puis interroge un serveur DHCPv6 pour obtenir
des paramètres complémentaires autres que l'adresse IPv6 telles que les adresses de
serveurs DNS par exemple.
M = 1 et O = X => Mode DHCPv6 Statefull. La configuration IPv6 de l'hôte est
fournie par un serveur DHCPv6.
0 7 8 15 16 31
Type = 3 Length = 4 Longueur préfixe L A Réservé
Durée de vie valide
Durée de vie préférée
Réservé
Préfixe
En général, 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,
celui-ci les avertissant par redirection qu'une route directe existe.
0 7 8 15 16 31
Type = 137 Code =0 Checksum
Réservé
Adresse IPv6 de la cible (nouveau routeur)
Adresse IPv6 de destination
Options : Adresse physique du nouveau routeur, En-tête redirigé
Le rôle du routeur est important dans l'auto-configuration. Il dicte à la machine à l’aide des flags M et O
de l'en-tête du message d'annonce de routeurs la méthode à retenir et fournit éventuellement les
informations nécessaires à sa configuration.
Plusieurs itérations peuvent être nécessaires avant d'obtenir un PMTU (1280 mini en IPv6)
permettant au paquet d'arriver à destination. La détermination du PMTU se fait essentiellement lors des
premiers échanges mais peut également être revue en cours de transfert, suite par exemple à un
changement de route.
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.
Le préfixe 2002::/16 est réservé aux adresses de tunnel 6to4. Tout paquet IPv6 dont l'adresse de
destination commence par 2002: doit passer par le tunnel 6to4. A ce préfixe sont ajoutés les 32 bits de
l’adresse IPv4 en notation hexadécimale pour former l’adresse IPv6 associée. Cette adresse est
généralement celle d'un routeur 6to4.
Exemple 2 :
Si la destination d'un paquet IPv6 est 2002:8ac3:802d:1242:20d:60ff:fe38:6d16, le paquet sera
encapsulé puis transmis par IPv4 au routeur 6to4 dont l'adresse IP est 138.195.128.45. C'est ensuite au
routeur 6to4 après extraction du paquet IPv6 de transmettre celui-ci à sa destination finale.
Dans ce cas le champ (16bits) 1242 hexadécimal représente le sous réseau de destination et le champ
(64 bits) 20d:60ff:fe38:6d16 l’identificateur d’interface du poste de destination.
6to4 encapsule un paquet IPv6 dans la zone de données (payload) d'un paquet IPv4 avec protocole de
type 41 (6in4 encapsulation).
Dans le RFC 3068, il a été proposé d'utiliser une adresse anycast qui soit commune à tous ces relais à
travers le monde, l’adresse 192.88.99.1.
2002:500A:0001::/48 Relai 6to4
80.10.0.1 2001:DDEE:0002::/48
192.88.99.1
Routeur 6to4 Routeur 6to4
Relai 6to4
Relai 6to4
Serveur IPv6
L'opérateur ayant ses propres relais et contrôlant donc les tunnels il peut s’assurer que les échanges
soient symétriques. De plus, ces tunnels internes à l’infrastructure IPv4 de l’opérateur sont
nécessairement plus courts et introduisent donc des délais de transit plus faibles.
Infrastructure IPv4
Opérateur
Réseau Privé I Pv6
R1
6rd BR
R2
Transfert inter-sites :
Le poste situé dans le réseau R1 envoie un paquet IPv6 à destination du poste situé dans le réseau R2.
Le paquet IPv6 arrive en mode natif au 6rd CE de la source. Si l’adresse IPv6 de destination est
incluse dans le préfixe du domaine 6rd configuré localement, le paquet est directement transmis au
routeur 6rd CE du destinataire. Les adresses IPv4 des 6rd CE sont extraites des adresses IPv6 pour
constituer le tunnel.
Routeur
NAT64 statefull
=>@source Postev6
=> => @source Routeurv4
=>
@dest Prefix64:Postev4 @dest Postev4
Postev6 Postev4
Prefix64 RouteurV4
Adresse « IPv4 converted »
DNS64 Routeur
DNSv4v6
Prefix64 = 2A01::/96 NAT64
Postev6 = 2001:DB8::1 Postev4.fr = 80.80.80.1
Prefix64 = 2A01::/96 66.66.66.1
DNS requête AAAA
Postev4.fr DNS requête AAAA
Postev4.fr
DNS répons e
(vide)
DNS requête A
Postev4.fr
DNS répons e
80.80.80.1
DNS répons e AAAA
2A01::80.80.80.1
TCP/IPv6
@Source = [2001:DB8::1]:1024
@Destination = [2A01::80.80.80.1]:80 TCP/IPv4
@Source = 66.66.66.1:1024
@Destination = 80.80.80.1:80
ISATAP utilise un format d’identificateur de machine qui inclut l’adresse IPv4. Les 64 premiers bits
de l'adresse IPv6 sont choisis dans les adresses IPv6 standards. Les 32 bits suivants sont égaux à
0000:5EFE. Enfin, les 32 bits restants représentent l'adresse IPv4 de destination en hexadécimal
(extrémité du tunnel).
64 bits 16 bits 16 bits 32 bits
Préfixe IPv6 Standard 0000 5EFE @ IPv4
Pour la configuration de l’interface ISATAP les postes clients interrogent le serveur DNS afin de résoudre
le nom d’hôte réservé ISATAP. Celui-ci doit être associé à l’adresse du routeur ISATAP à utiliser pour
monter le tunnel ISATAP leur permettant de joindre le monde IPv6 depuis leur réseau IPv4. A partir de
cette réponse il monte l’interface ISATAP avec l’adresse ISATAP « ad hoc ».
L'algorithme de configuration d'un équipement isolé qui utilise ISATAP est le suivant :
dans un premier temps, l'équipement doit connaître l'adresse IPv4 du routeur gérant ISATAP, cette
adresse est obtenue par résolution DNS ou configurée par une commande netsh,
l'équipement envoie un message IPv6 Router Sollicitation au routeur en utilisant comme adresse
de la source, son adresse lien-local (fe80::5efe:IPv4) et comme adresse de destination l'adresse de
multicast des routeurs du lien (FF02::2). Ce message est encapsulé dans un paquet IPv4 dont
l'adresse destination est l'adresse IPv4 du routeur obtenue précédemment,
le routeur répond au message IPv6 Router Sollicitation en renvoyant en point-à-point, toujours
encapsulé dans un paquet IPv4, la liste des préfixes IPv6 utilisés pour joindre les équipements
isolés (Router Advertisement),
à partir du préfixe IPv6, l’équipement peut calculer son adresse IPv6 ISATAP
prefixeIPv6:0:5efe:IPv4.
Les stations terminales et les routeurs ISATAP transmettent les paquets IPv6 via un tunnel automatique
IPv6 dans IPv4 à l’intérieur du site, quel que soit le type d’adresse IPv4 utilisé (adresse privée ou adresse
globale). L’encapsulation IPv4 se fait également avec le protocole de type 41 (6in4 encapsulation).
Le procédé 6to4, protocole d'encapsulation IPv6 sur IPv4 le plus courant, nécessite que le
matériel au bout du tunnel d'encapsulation ait une adresse IPv4 publique. Pourtant actuellement et
pour combler l'épuisement des adresses IPv4, la plupart de ses hôtes sont reliés au réseau IPv4 par un
périphérique faisant du NAT. Ainsi, l'adresse publique est assignée à ce périphérique NAT et c'est
donc lui qui doit implémenter le protocole 6to4. Malheureusement, une grande partie de ces
équipements ne peuvent pas être mis à jour pour fournir le support de 6to4 pour des raisons techniques
ou économiques.
Teredo permet de résoudre ce problème en encapsulant les paquets IPv6 dans des datagrammes
UDP/IPv4, que la plupart des NAT peuvent transmettre correctement. Ainsi, les hôtes IPv6 derrière
des NAT peuvent être utilisés comme points de terminaison du tunnel Teredo, même quand ils n'ont
pas une adresse IPv4 publique dédiée. En effet, un hôte implémentant le protocole Teredo peut
acquérir une connectivité IPv6 sans la coopération de l'environnement du reste du réseau local.
La plage d’adresses IPv6 réservée au protocole Teredo débute par le préfixe Teredo 2001::/32.
Le serveur et le relai TEREDO écoutent en UDP sur le port 3544.
teredo.ipv6.microsoft.com
Serveur Teredo
Client Teredo teredo.remlab.net
Le client Teredo reçoit une adresse IPv6 qui commence par le préfixe Teredo 2001::/32,
le serveur Teredo est un hôte connu qui est utilisé pour la configuration initiale d'un tunnel Teredo
(détermination de l’adresse publique, du port UDP, adresse du serveur relai). Il ne transmet pas le
trafic client ce qui permet à un serveur unique de subvenir à un grand nombre de clients,
le relai Teredo est un hôte connecté à la fois en IPv4 et en IPv6 et par lequel passe tout le trafic
destiné à l'Internet IPv6.
Le champ flags est formé des bits CRAAAAUG AAAAAAAA pour lesquels :
o C =1 (cone NAT ) pour signaler que le client est situé derrière une NAT,
o R = réservé,
Principe :
Hôte IPv6
6 public
5
3
4
Réseau Privé I Pv4
Réseau Public IPv4 Réseau Public IPv6
2
1
Client Teredo
Serveur Teredo
teredo.remlab.net
Pour initialiser une communication entre un client Teredo et un terminal IPv6, les échanges suivants sont
mis en œuvre.
1. Le client Teredo doit tout d’abord déterminer l’adresse IPv4 et le port UDP du relai Teredo le plus
proche du terminal IPv6 à atteindre. Pour ce faire, le client Teredo envoie un message de demande
d’écho ICMPv6 encapsulé dans IPv4/UDP port 3544 au terminal IPv6 via le serveur Teredo.
2. Le serveur Teredo qui reçoit le message ICMPv6 le décapsule puis le retransmet au terminal IPv6
sur le réseau IPv6.
3. Le terminal IPv6 répond par un message d’écho ICMPv6 envoyé au client Teredo en utilisant
l’adresse Teredo de ce client. Ce message au format IPv6 est routé vers le relai Teredo le plus
proche du terminal IPv6.
4. Le relai Teredo encapsule le message d’écho ICMPv6 dans un paquet UDP et l’envoie au client
Teredo.
5. Le client Teredo détermine l’adresse IPv4 et le port UDP du relai Teredo à partir du message
ICMPv6 reçu. Un premier message UDP est alors envoyé du client Teredo à l’adresse IPv4 du
relai Teredo.
6. Le relai Teredo retransmet le paquet en IPv6 vers le terminal IPv6 après en avoir retiré l’en-tête
UDP/IPv4.
Tous les paquets suivants passent directement par le relai Teredo.
Les différentes commandes relatives à IPv6 sont accessibles à partir de la commande générale netsh et
plus particulièrement la commande netsh interface ipv6
>netsh interface
netsh interface>?
L’obtention d’une adresse « Unicast Lien Local » avec un identificateur d’interface calculé avec l’adresse
physique nécessite de désactiver le paramètre global randomizeidentifiers.
On obtient bien cette fois ci l’adresse obtenue selon le mode de calcul présenté au paragraphe
« Identifiant d’interface ».
IPv4
172.19.32.0/24 172.19.32.254
WWW
IPv6
FD00:0:1:11:172:19:32:254
FD00:0:1:11:/64 routeur2801
Configuration de l’interface IPv4 et IPv6 du routeur – Mode IPv6 non managé (sans état)
interface FastEthernet0/1.3
description **** Sortie Vlan11 ****
encapsulation dot1Q 11
ip address 172.19.32.254 255.255.255.0
ip nat inside
ipv6 address FD00:0:1:11:172:19:32:254/64
ipv6 enable
ipv6 nd prefix FD00:0:1:11::/64 36000 35000
>ipconfig /release6
>ipconfig /renew6
La machine connait le routeur, le préfixe à utiliser pour calculer son IPv6, elle sait également qu’elle doit
définir son identifiant d’interface en mode non managé (automatique sans serveur DHCP).
Configuration de l’interface IPv4 et IPv6 du routeur – Mode IPv6 managé (avec état)
interface FastEthernet0/1.3
description **** Sortie Vlan11 ****
encapsulation dot1Q 11
ip address 172.19.32.254 255.255.255.0
ip nat inside
ipv6 address FD00:0:1:11:172:19:32:254/64
ipv6 enable
ipv6 nd prefix FD00:0:1:11::/64 no-advertise OU ipv6 nd prefix FD00:0:1:11::/64 1800 1200 no-autoconfig
ipv6 nd managed-config-flag
>ipconfig /release6
>ipconfig /renew6
Désactiver, activer une interface (par exemple pour une réinitialisation DHCP) :
>sudo ifconfig nomInterface down
>sudo ifconfig nomInterface up
Désactiver, activer une interface (par exemple pour une réinitialisation DHCP) :
>sudo ifconfig nomInterface down
>sudo ifconfig nomInterface up