Cours

Support de cours
TECHNOLOGIES INTERNET
AVANCEES: IPv6
Dr Lambert KADJO 1
www.kadjo-lambert.c4.fr
AVANCEES: IPv6
6DISS (http://www.6diss.org)
Bibliographie 6Bone(http://www.6bone.net)
IPv6 Forum (http://www.ipv6forum.com) 6NET (http://www.6net.org)
IPv6 Task Force (http://www.ipv6tf.org) Euro6IX (http://www.euro6ix.org)
Moonv6 (http://moonv6.sr.unh.edu)
Caida (http://www.caida.org)
Network exchange points for IPv6 (http://www.napv6.net)
IPv6.org (http://www.ipv6.org)
IPv6 Style (http://www.ipv6style.jp/en/index.shtml) IANA http://www.iana.org/assignments/ipv6-address-space
Sixxs (http://www.sixxs.net) AFRINIC http://www.afrinic.net
G6 (http://www.point6.net) APNIC http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html
ARIN http://www.arin.net/registration/ipv6/
Apple Mac OS http://developer.apple.com/macosx/
LACNIC http://www.lacnic.net
BSD http://www.kame.net
RIPE http://www.ripe.net/ripe/docs/ipv6-policy.html
IBM http://www-306.ibm.com/software/os/zseries/ipv6/
Linux http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html
Microsoft http://www.microsoft.com/ipv6 Cours de Réseaux, Bernard COUSIN, Université de Rennes 1
Novell http://www.sun.com/software/solaris
Gaël Beauquin, IPv6 : sécurité - La sécurité dans une transition vers IPv6, CNRS UREC ,
Symbian http://www.symbian.com http://www.urec.cnrs.fr/IMG/pdf/secu.articles.Archi.Securite.IPv6.pdf
BORTZMAYER, http://www.bortzmeyer.org/3971.html
AFRINIC Stats http://www.afrinic.net/statistics/index.htm
IANA Stat http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml
ICANN Stats and docs http://aso.icann.org/category/documents/
OUI Numbers http://standards.ieee.org/regauth/oui/oui.txt
SIXXS Stats http://www.sixxs.net/tools/grh/dfp/all/?sort=country
http://www.sixxs.net/misc/coolstuff/
V6FICATIONS http://www.deepspace6.net/docs/ipv6_status_page_apps.html
Dr Lambert KADJO 2
AVANCEES: IPv6
Chapitre I. Protocoles
Chapitre II. PLAN D’ADRESSAGE IPv6
Chapitre III. MECANISMES DE CONFIGURATION DES HOTES ET
CONTROLE
Chapitre V. ROUTAGE DYNAMIQUE EN IPv6
Chapitre IV. SUPPORT DNS EN IPv6
Chapitre VI. MÉCANISMES DE TRANSITION/ INTÉGRATION/
MIGRATION
3
AVANCEES: IPv6
Dr Lambert KADJO 4
Chapitre I. PROTOCOLES I.1 Problèmes d’IPv4 et tentatives
de résolution (7/8)
Quelques problèmes
Avec l’explosion de l’Internet, l’adressage IPv4 est confronté à plusieurs problèmes :
 épuisement des adresses IP publiques dû à la planification de l’adressage en classes a

insufflé des problèmes à IPv4
 Plus de la moitié des adresses non attribuables à des machines (adresses de diffusion
généralisée, adresses de diffusion restreinte, adresses particulières, adresses privées, blocs
réservés inutilisables, etc.)
 Gaspillage d’adresses dans les classes A et B dans des réseaux peu volumineux
- une adresse réseau de la classe A  224-2= 16 777 216 -2 adresses d’hôte
- une adresse réseau de la classe B  216-2= 65 536 -2 adresses d’hôte
 pas de sécurisation native des données pour IPv4 exemples de problèmes de sécurité ?
 faible disposition pour la gestion de la QoS

 8% seulement des en-têtes réservés (1 seul champ sur au moins 12)
 mauvaise gestion de la mobilité IP
- routage triangulaire entre HA (Home Agent) et le MN (Mobile Node)
5
www.kadjo-lambert.c4.fr Dr Lambert KADJO ****** 2010-2011
Tentatives de résolution
 Notion de sous-réseau
- utilisation du CIDR (Classless Inter-Domain Routing) : Allocation sur la base du besoin réel!
Adressage privé (RFC 1918) & NAT (Network Address Translation)

- Une seule adresse publique suffit pour plusieurs machines connectées à l’Internet
10.0.0.0 à 10.255.255.255 ou (10.0.0.0/8),
172.16.0.0 à 172.31.255.255 ou (172.16.0.0/12)
192.168.0.0 à 192.168.255.255 ou (192.168.0.0/16)
 Appel à la restitution de blocs d’adresses inutilisés à l’IANA (RFC 1917)

- bloc 36.0.0.0/8 (Université Stanford) en 2000
- bloc 45.0.0.0/8 (Interop) en 2010
 DHCP et ses différentes variantes
 IPsec (IP Security) (RFC 1825) Cela a-t-il pu tout résoudre ?
6
Problèmes persistants
 explosion des tables de routage (plus de 150 000 routes dans l’Internet IPv4)
 lourdeur dans la gestion des adresses : pas d’auto configuration, tenir à jour
une base d’adresses IP attribuées
 Gestion toujours inefficace et difficile de la mobilité IP
 Impossibilité de réutilisation du bloc réservé

240.0.0.0/4 (classe E)
 Derniers blocs distribués le 3 Février 2011 aux RIR
7
8
9
10
RIR Espace disponible Date d'épuisement

(/8) estimée
APNIC 0.3640 19-Avr-2011
RIPENCC 0.6796 14-Sept-2012
LACNIC 0.2000 10-Juin-2014
ARIN 24-Sept-2015
AFRINIC 0.8101 07-Aout-2018
11
Comment nous consommons le reste
http://www.potaroo.net/tools/ipv4/index.html
12
Conséquences
la demande en adresse IPv4 peut faire augmenter son prix
Les adresses IPv4 deviennent plus chères
Un marché noir d’adresse IPv4 voit le jour
Quelles sont les solutions trouvées aux problèmes persistants ?

IPv6
13
Ultime solution de l’IETF
IPv6
L'IETF a proposé cette nouvelle version du protocole IP en 1995 (RFC
1883) puis le standard IPv6 en 1998 (ou IPng - ng pour "Next Generation",
RFC 2460) en prenant en compte de nouveaux besoins tels que :
 la voiture, le frigo, la cafetière, etc.
 la sécurité,
 le multicast,
 les classes de service
14
Ultime solution de l’IETF

RFCs de 2014 (13 RFCs)
7225 7222 7217 7161 7157
RFCs de 2013 (24 RFCs)
7156 7148 7136 7123 7113
7083 7077 7066 7059 7050
7112 7109 7098
7045 7040 7028 7010 6992
6980 6964 6948 6946 6936
6935 6930 6911 6909 6883
RFCs de 2012 (32 RFCs) 6879 6874 6866 6829
6782 6775 6757 6751 6744
6743 6724 6705 6666 6654
6629 6620 6618 6612 6611
6610 6606 6602 6589 6586
6572 6568 6564 6554 6550
6543 6540 6516 6515 6475 RFCs de 2011 (37 RFCs)
6463 6459 6438 6437 6436 6434 6384
6342 6334 6324 6312 6296
RFCs de 2010 (24 RFCs) 6294 6282 6279 6275 6264
6058 6052 6036 6018 5969 6224 6219 6214 6204 6180
5963 5954 5952 5949 5942 6177 6164 6157 6156 6147
5902 5881 5871 5855 5847 6146 6144 6127 6119 6106
5846 5845 5844 5798 5779 6105 6104 6097 6092 6089
15
5778 5757
5739 5726 6085 6059 Dr Lambert KADJO ****** 2010-2011
Chapitre I. PROTOCOLES I.2 Fonctionnalités d’IPv6
(1/3)
Principales modifications d’IP

 Espace d’adressage élargi
- on passe de 32 bits à 128 bits (32 chiffres hexadecimaux)
 beaucoup plus de nœuds adressables (plus de 3,4x1038 combinaisons possibles, soit 296
fois le total d’adresses IPv4)
- nouveau type d'adresse (cluster address)
?
 anycast (+ unicast + multicast)
- NAT plus nécessaire (retour du point-à-point) pourquoi le NAT n'est pas nécessaire ?
 Infrastructure d'adressage et de routage efficace et hiérarchique

?
- adresses globales IPv6 utilisées sur la partie IPv6 d'Internet conçues pour créer une infrastructure
de routage efficace, hiérarchique et concise, basée sur l'occurrence commune de niveaux multiples
de fournisseurs de services Internet.
- Sur Internet IPv6, les routeurs de réseau principal possèdent des tables de routage beaucoup plus
petites correspondant à l'infrastructure de routage des assembleurs de niveau supérieur.
 Simplification de l'entête :
- transfert des champs non essentiels et facultatifs dans des en-têtes d'extension placés après l'en-
tête IPv6
 diminue le surcoût (“overhead”) : temps de traitement et quantité de données 16
(2/3)

 Configuration d'adresses avec et sans état avec état et sans état ?
- Pour simplifier la configuration d'hôtes, IPv6 prend en charge la configuration d'adresses avec état,
telle que la configuration d'adresses en présence d'un serveur DHCP, et la configuration d'adresses
sans état (configuration d'adresses en l'absence d'un serveur DHCP).
- Avec la configuration d'adresses sans état, les hôtes sur une liaison se configurent automatiquement
avec des adresses IPv6 pour la liaison (adresses lien-local) et avec des adresses dérivées de préfixes
annoncés par des routeurs locaux.
 Meilleur support pour QoS

- Etiquetage des flots de données permettant aux routeurs d'identifier et de traiter spécifiquement les
paquets appartenant à un flux, série de paquets entre une source et une destination.
- Puisque le trafic est identifié dans l'en-tête IPv6, la prise en charge de QoS peut être assurée même
lorsque les données utiles du paquet sont cryptées au moyen d'IPSec.
17
(3/3)
 Sécurité intégrée : IPSec est une exigence Un résumé sur le fonctionnement de IPSec (mode transport et mode tunnel ?)
- Authentification + Confidentialité des données
 Nouveau protocole pour l'interaction de nœuds voisins

- protocole Neighbor Discovery de IPv6 pour la gestion de l'interaction entre nœuds voisins (nœuds
figurant sur la même liaison).
- remplace les messages ARP, ICMPv4 Router Discovery par des messages multicast et unicast
Neighbor Discovery.
 Gestion aisée et efficace de la mobilité IP

- extensions dédiées à la mobilité
 Capacités d’extension
18
Chapitre I. PROTOCOLES I.3 Paquets IPv6 sur support de
réseau local
 Fonctionne sur la même infrastructure physique
 Une trame de couche liaison contenant un paquet IPv6 présente :

-en-tête et fin de couche liaison : encapsulation placée sur le paquet IPv6 sur la
couche liaison.
- En-tête IPv6: nouvel en-tête IPv6.
- Données utiles: données utiles du paquet IPv6
19
réseau local
Encapsulation Ethernet II
- les paquets IPv6 sont indiqués en attribuant au champ EtherType de l'en-tête Ethernet II, la valeur
0x86DD (IPv4 est indiqué en attribuant au champ EtherType la valeur 0x800).
- les paquets IPv6 peuvent avoir une taille minimale de 46 octets et une taille maximale de 1 500
octets.
20
réseau local
I.4.2 Encapsulation IEEE 802.3, IEEE 802.5 et FDDI
- Sur les réseaux IEEE 802.3
(Ethernet), IEEE 802.5 (Token
Ring) et FDDI, l'en-tête SNAP
(Sub-Network Access
Protocol) est utilisé et le
champ EtherType prend la
valeur 0x86DD pour indiquer
IPv6.
- Pour l'encapsulation IEEE

802.3 utilisant l'en-tête SNAP,
les paquets IPv6 peuvent avoir
une taille minimale de 38
octets et une taille maximale
de 1 492 octets.
- Pour l'encapsulation FDDI
utilisant l'en-tête SNAP, les
paquets IPv6 peuvent avoir
une taille maximale de 4 352
octets.
21
réseau local
I.4.3 Encapsulation IEEE 802.11 utilisant SNAP
FC (Frame Control) : Version de protocole (2), Type
(2 ), Sous-type (4 ), To DS (1), From DS (1), More
Fragments (1), Retry (1), Power Management (1),
More Data (1), WEP (1), Order (1)
 Duration/ID indique la durée d'utilisation du canal

 Address 1 , Address 2 et Address 3 dependent des
valeurs de ToDS/ FromDS
22
Chapitre I. PROTOCOLES I.4 Etat de l’implémentation
I.5.1 Au niveau des applications et des systèmes d’exploitation

Constructeurs Systèmes d’exploitations
Free BSD 4.0 et supérieures
Open BSD 2.7 et supérieures
BSD
Net BSD 1.5 et supérieures
BSD/OS 4.2 et supérieures
HP-UX 11i et supérieures
HP Tru64 UNIX V5.1 et supérieures
Open VMS V5.1 et supérieures
AIX 4.3 et supérieures
IBM OS/390 V2R6 Encs et supérieures
z/OS Rel 1.4 et supérieures
Rel 6.2 et supérieures
Mandrake 8.0 et supérieures
LINUX
SuSE 7.1 et supérieures
23
www.kadjo-lambert.c4.fr Debian 2.2 et supérieures Dr Lambert KADJO ****** 2010-2011

Constructeurs Systèmes d’exploitations
Windows 8 (Pile unifiée, Activé par défaut+mode graphique)
Windows 7 (Pile unifiée, Activé par défaut+mode graphique)
Windows Server 2008 R2, (Pile unifiée, Activé par défaut+graphique)
Windows Vista (Pile unifiée, Activé par défaut+mode graphique)
Windows Server 2008 (double pile, non activé par défaut)
WINDOWS
Windows Server 2003 (double pile, non activé par défaut)
Windows XP (double pile, non activé par défaut)
Windows XP Embedded SP1 (double pile, non activé par défaut)
Windows CE .NET (double pile, non activé par défaut)
Windows 2000 (mettre à jour la pile)
Novell Netware 6.1 et supérieures
SUN Solaris 8 et supérieures
Symbian Symbian 7.0 et supérieures
24
 De nombreuses applications supportent IPv6:

- Apache, serveur Web,
- Wireshark,
-postfix
etc.
25
I.5.2 Au niveau des routeurs
 CISCO
 JUNIPER
 OmnisSwitch ALCATEL
26
Quelques stats
http://ipv6-test.com/stats/
27
Quelques stats
28
Quelques stats
29
Quelques stats
30
Chapitre I. PROTOCOLES I.5 Format général du paquet
IPv6
Principales modifications au niveau de l’en-tête IP
31
IPv6
Principales modifications au niveau de l’en-tête IP
32
IPv6
Description des champs de l’en-tête IPv6
Le champ VERSION
- Représenté sur 4 bits

- Compatible avec IPv4 assure la transition :
 Les stations ou routeurs recevant un datagramme d'une version qu'ils ne décodent pas,
doivent l'écarter;
 Une même station ou routeur peut être capable de traiter plusieurs versions : (“dual
stack station”).
- Code:
 4 : “Internet Protocol” - IPv4 (rfc 781) : septembre 1981.
 5 : “Stream Protocol” ST-II, ST2+ (RFC 1190, RFC 1819)
 6 : “Internet Protocol new Generation”(RFC 1883) - IPv6 (RFC2460) : décembre 1995.
33
IPv6
Le champ TRAFFIC CLASS
Champ représenté sur 8 bits
 identifie les différents types de trafics.

 Les six bits de poids forts portent les valeurs dites DSCP (Differentiated Services Code Point). En
configurant des files d'attente et des valeurs DSCP, le trafic marqué DSCP peut présenter des niveaux de
service différenciés.
 On nomme Per Hop Behavior (PHB), le comportement d'un nœud relatif à un Code Point donné.
 Un « Domaine DS » est un ensemble de nœuds contigus ayant le même ensemble de PHB définis.
 Une « Région DS » est un ensemble de domaines DS contigus, chaque domaine établissant des
Spécifications de Niveau de Service avec ses voisins.
 Le champ Currently Unused (CU) devient ECN (Explicit Congestion Notification) dans le RFC 3168
 permet à un routeur de signaler explicitement un début de congestion avant de commencer à perdre
des paquets.
 négocié pour chaque connexion et utilisé que lorsque les deux hôtes échangeant des données
signalent leur intention de l'utiliser. 34
IPv6
– La valeur DSCP 0 est associée au PHB Best Effort (BE) ou Default. Le PHB BE correspond au
comportement par défaut réservé à la grande majorité des paquets. Il s'agit d'un acheminement sans
garantie en termes de variation de délai ou de pertes.
– Les Class Selector Code Point (CS) sont les valeurs numériques du champ DSCP ayant une représentation
binaire de la forme xxx000. Il y a donc 8 CS différents. La RFC 3662 [5] suggère que le Class Selector 1
(001000) soit utilisé pour marquer des paquets devant recevoir une priorité plus basse que la normale
(LE : Lower Effort). Le PHB associé à cette valeur DSCP est le suivant : un paquet LE ne devrait être
transmis sur un lien que s'il est inutilisé.
Niveau de Description Niveau de
priorité priorité
7 trafic de contrôle du réseau Internet 3 Class 3 ou CS3 (compatibilité
(par ex. protocoles de routage, SNMP) avec IPv4)
6 trafic interactif (par ex. Telnet, X) 2 Class 2 ou CS2 (compatibilité
avec IPv4)
5 Express Forwarding (EF): faible latence, 1 Class 1 ou CS1 (compatibilité
faible taux de pertes (pour trafics avec IPv4)
temps réel)
4 Class 4 ou CS4 (compatibilité avec IPv4) 0 Best effort
35
IPv6
– La RFC 2597 [7] standardise les PHB Assured Forwarding (AF). Ces PHB correspondent à la définition de 4
classes AFi où 1 ≤ i ≤ 4, classées par ordre de priorité croissante. Chaque classe dispose de 3 niveaux de
drop precedence ou probabilité de suppression. On note un PHB AF sous la forme AFij où 1 ≤ j ≤ 3. Pour
une classe i donnée, plus la valeur de j est grande, plus la probabilité que le paquet soit détruit, en cas
de congestion, est élevée. Les nœuds qui supportent les classes AF doivent limiter la congestion sur le
long terme en détruisant des paquets mais autorisent des congestions de courte durée provenant de
bursts en retardant des paquets.
– Le code DSCP EF (pour Expedited Forwarding), défini dans la RFC 3246 [8], correspond au PHB attendu
pour le traitement de paquets nécessitant un service de bout en bout avec peu de pertes, de latence et
de gigue. Un paquet marqué avec la valeur EF doit être expédié le plus rapidement possible. Il ne doit
être retardé que par l'acheminement d'autres paquets EF qui le précédent.
36
IPv6
-Les classes sont utilisées en premier pour déterminer la priorité
- Le RFC 2597 définie la valeur Assured forwarding (AF) et le mécanisme de gestion des classes
 les bits DS5, DS4 et DS3 définissent la Classe de trafic : les 3 bits codent le 1er chiffre du n° AF
 les bites DS2 et DS1 définissent la probabilité de suppression: les 2 bits codent le 2ème chiffre du n° AF
 le bit DS0 est mis à 0
Probabilité de Suppression Class 1 Class 2 Class 3 Class 4
Low 001 010 010 010 011 010 100 010
AF11 AF21 AF31 AF41
DSCP 10 DSCP 18 DSCP 26 DSCP 34
Medium 001 100 010 100 011 100 100 100
AF12 AF 22 AF32 AF42
High 001 110 010 110 011 110 100 110
AF13 AF23 AF33 AF43
Le RFC 2474 ne spécifie pas le message d’erreurs envoyé par les routeurs pour les trois derniers bits de
DSCP 37
IPv6
 iptables -t mangle -A FORWARD -p tcp --dport 80 -j DSCP --set-dscp 1
 iptables -t mangle -A FORWARD -p tcp --dport 80 -j DSCP --set-dscp-class EF
Classe de Service DSCP
RFC 4594 définit Network Control CS6
Telephony EF
Signaling CS5
Multimedia Conferencing AF41, AF42, AF43
Real-Time Interactive CS4
Multimedia Streaming AF31, AF32, AF33
Broadcast Video CS3
Low-Latency Data AF21, AF22, AF23
OAM (Operation Administration and Maintenance) CS2
High-Throughput Data AF11, AF12, AF13
Standard DF (CS0)
Low-Priority Data CS1 38
IPv6
Le champ FLOW LABEL
champ de 20 bits :
Un flot  l'ensemble des paquets équi-étiquetés en provenance d'un même nœud.
 L'utilisation du champ “Flow label” peut être d'utilisation plus souple que le
champ “Class of service”
Mais :
 Dépendant de l'implémentation dans les routeurs.
 Dépendant de l'utilisation de protocoles supplémentaires (RSVP) ou d'options
d‘IPv6 pour établir les flots.
 L'interprétation du champ Flow label est optionnelle.
 Flow label + @IP source + @IP Destination = 1 flot
39
IPv6
Le champ FLOW LABEL
- Tous les paquets d'un même flot doivent subir les mêmes traitements au sein des routeurs :
 les paramètres des paquets d'un même flot doivent être identiques (adresses, Class, options
de l'entête Hop-by-hop, champs de l'entête Routing)
- Ces traitements peuvent être optimisés en utilisant le Flow Label et l'adresse source comme une
clef d'accès à un descripteur :
 accès rapide, pré-traitement, etc.
- La nature du traitement spécifique doit être transmise aux routeurs à l'aide :

 d'un protocole spécifique de réservation de ressources (par ex. RSVP).
 des paquets eux-mêmes (par ex. à l'aide des options de l'entête Hop-by-hop)
- Un paquet ayant un champ Flow Label=0 n'est associé à aucun flot.

- L'optimisation des traitements donc l'utilisation du Flow Label est laissé libre (le paquet est alors
considéré comme n'appartenant à aucun flot).
- Pour maintenir un flot en vie, un paquet de ce flot doit être périodiquement envoyé (Toutes les 6
secondes au moins). 40
IPv6
Le champ PAYLOAD LENGTH
Sur 2 octets :
- longueur en octets de la charge utile du paquet (ce qui suit l'entête IPv6).
- 0 : indique que la longueur doit être trouvée dans l'option Jumbo Payload
de l'entête Hop-by-hop.
 similaire à l'option “Total length” d'IPv4.
Le champ HOP LIMIT

Le champ sur 1 octet :
- durée limite de vie du paquet :
 les paquets fantômes qui errent sans fin : erreur de routage
 limitation (grossière) du domaine atteignable par un paquet
- décrémenté à chaque routeur.
- si la valeur atteint 0, le paquet est détruit.
 similaire au champ “Time To Live” d'IPv4 (dont l'unité était la seconde). 41
IPv6
Le champ NEXT HEADER
Le champ sur 1 octet :
 Identifie le type de la prochaine entête.
 Chaînage des entêtes optionnelles.
 Le champ de données est considéré comme une entête optionnelle !
 Optimisation de la taille de l'entête et du temps de traitement :
 les options non utilisées ne sont pas présentes.
Valeurs Headers Valeurs Headers
0 Hop-by-Hop Options header 50 Encapsulting Security Payload
1 ICMPv4 51 Authentication Header
4 IPv4 58 ICMPv6
6 TCP 59 No Next Header
17 UDP 60 Destination Options Header
41 Encapsulated IPv6 Header 88 IGRP
43 Routing header 89 OSPF
44 Fragment Header 135 Mobilité 42

IPv6
Les champs ADDRESS
Les champs Source and Destination Address (16 octets)

-la longueur du champ d'adresse passe de 32 bits à 128
- Les 128 bits (32 chiffres hexadécimaux) de l'adresse sont divisés en 8 groupes de 16 bits (4
chiffres hexadécimaux ). Les groupes sont séparés par le caractère ":"
43
IPv6
Les champs ADDRESS
Exp :
0010 0000 0000 0001 0001 0000 1100 0011 1110 0011 1100 0011 1111 0001 1010 1010
2001:10c3:e3c3:f1aa:48e3:d923:d494:aaff
0100 1000 1110 0011 1101 1001 0010 0011 1101 0100 1001 0100 1010 1010 1111 1111
 Plusieurs façons de représenter les adresses IPv6

- forme préférée
- forme abrégée
- forme mixte
44
IPv6
Les champs ADDRESS
 Représentation des adresses IPv6 : forme préférée
- Cette forme exige les 32 chiffres hexadécimaux dans l’écriture de l’adresse
- Les lettres peuvent être écrites aussi bien en majuscules qu'en minuscules. Cependant
l’écriture en minuscule est conventionnellement utilisée.
Exemples:
a) 2001:4318:0002:0000:0000:0000:0ef0:bdd7
b) 3ffe:0104:0103:00a0:0a00:20ff:fe0a:3ff7
 Représentation des adresses IPv6 : forme abrégée

- les zéros de poids fort (zéros à gauche, juste après le caractère « : ») de chaque groupe peuvent
être omis,
- deux ou plusieurs groupes de zéros consécutifs sont substitués par "::". Cependant, ceci ne devrait
être fait qu’une seule fois dans l’écriture d’une adresse IPv6 pour éviter toute ambiguïté;
- Si plus d’une substitution est possible, faire celle qui remplace le plus de groupes
- Pour un cas de deux substitutions égales possibles, faire celle qui est le plus à gauche.
Exemple: L'adresse donnée en exemple-a) peut donc s'écrire :
45
2001:4318:2::ef0:bdd7
IPv6
Les champs ADDRESS
 Représentation des adresses IPv6 : forme mixte
- L'adresse IPv6 compatible IPv4

Elle est utilisée dans un contexte particulier : les tunnels 6to4 permettant de relier des réseaux IPv4 à
des réseaux IPv6. Soit une adresse IPv4 notée a.b.c.d , son équivalent IPv6 se notera :
0000:0000:0000:0000:0000:0000:a.b.c.d/96 ou ::a.b.c.d/96
Exemple : ::132.64.16.25/96
- L'adresse IPv4 mappée

Un hôte IPv6 étant capable de communiquer aussi bien avec un hôte IPv4 qu'avec un hôte IPv6, il
utilise des adresses IPv4 mappées pour communiquer avec les autres machines IPv4 et utilise des
adresses IPv6 normale pour communiquer avec les autres machines IPv6. Ces adresses sont de la forme
0000:0000:0000:0000:0000:ffff:a.b.c.d où a.b.c.d est une adresse IPv4
Exemple : :: ffff : 132.64.16.25
NB: Jamais utilisé comme adresse IPv6 de source ou de destination
46
IPv6
En-tête d’extension
Définition
 La partie fixe de l'en-tête peut être suivie par un nombre quelconque d'en-têtes
optionnels.
 Chaque en-tête (optionnel ou fixe) contient un champ “Next header”.
 Un chaînage entre les en-têtes est établi à travers le champ “Next header”.
 Le dernier en-tête décrit le type de protocole chargé du champ de données qui le
suit. Dans ce cas, le champ “Next Header” correspond exactement au champ
“Protocol Type” de IPv4.
47
IPv6
Définition
 L’en-tête d’extension de proche en proche (Hop-by-Hop), code 0

 L’en-tête d’extension de routage par la source, code 43
 L’en-tête d’extension de fragmentation, code 44
 L’en-tête d’extension d’option de destination, code 60
 Les en-têtes d’extension de sécurité
 ESP: Encapsulation Security Payload, code 50
 AH: Authentication header, code 51
 L’en-tete d’extension No Next Header header, code 59
48
IPv6
Ordonnancement des en-tetes
 Les options peuvent être traitées :

- (a) soit par tous les nœuds intermédiaires et le(s) destinataire(s) final,
- (a') soit par tous les destinataires intermédiaires et le(s) destinataire(s) final,
- (b) soit uniquement par le(s) destinataire(s) final.
 L'exploitation d'un en-tête dépend du traitement de l'en-tête qui le précède :
- le résultats des traitements peuvent dépendre de leur ordre.
 Ordre :
. IPv6 header (a)
. Hop-by-hop options header (a)
. Destination options header (a')
. Routing header (a')
. Fragmentation header (b)
. Authentication header (b)
. Encapsulated security payload header (b)
. Destination options header (b)
. Upper layer header and data (b)
ou No next header (b)
49
IPv6
Ordonnancement des en-tetes
50
IPv6
Traitement des en-tetes
 La taille des en-têtes optionnels est exprimée en unités de 8 octets.

 parallélisation des accès aux données
 Lorsqu'un nœud doit traiter l'en-tête suivant et que la valeur de son Next Header est non
reconnue
 le nœud émet un paquet ICMP vers la source.
- ICMP code = 2 (“unrecognized Next header type encountered”)
- ICMP pointer = la valeur non-reconnue.
51
IPv6
Description des en-tetes d’extension
L'en-tête “Hop-by-hop options”
 Next Header = 0.
Informations examinées par chaque nœud situé sur le chemin du paquet.
 Next Header (1 octet) : identifie le prochain en-tête.

 Hdr Ext Len (1 octet) : longueur totale de l'en-tête optionnel Hop-by-hop (moins les 8 premiers
octets) en multiples de 8 octets.
 nécessite un bourrage (padding option)
 Options list (variable) : champ contenant une ou plusieurs options.
52
IPv6
Les options de l'en-tête “Hop-by-hop options”

 Chaque option est codée suivant le format TLV (type, longueur, valeur)
- Option Type (1 octet) : identifie le type de l'option

- Opt Data Len (1 octet) : longueur en octets du champ Option Data.
- Option Data (variable) : les informations spécifiques de l'option.
 Les options se succèdent toutes dans le champ Options de l'en-tête optionnel Hop-by-hop.
53
IPv6

 Le sous-champ “Option Type”
- Si l'option n'est pas reconnue (2 bits) :
. Option type == 00xxxxxx : passer à l'option suivante.
. Option type == 01xxxxxx : détruire le paquet.
. Option type == 10xxxxxx : détruire le paquet, envoyer un message ICMP type 4 code 2.
. Option type == 11xxxxxx : détruire le paquet, envoyer un message ICMP type 4 code 2.
si l'adresse de destination n'est pas une adresse multicast.
- Modification du champ Option Data au cours de la transmission du paquet :
. Option type == xx0xxxxx : pas de modification.
. Option type == xx1xxxxx : modification possible.
utilisé lorsque l'en-tête d’extension d'authentification est présent: les en-têtes
susceptibles d'être modifiés sont considérés comme ayant des octets nuls.
54
IPv6

 Les options d’alignements
- les options d'alignements : Pad1 et Padn.
- communes aux en-têtes ayant des options (en-tête Hop-by-hop, en-tête Destination)
 Pad1 : option type =0

- alignement d'1 octet.
- cas spécial sans champ de longueur ni de valeur. N-2 octets
 Padn : option type =1

- alignement de 2 octets ou plus .
- Opt Data Len (1 octet) :
. bourrage de N octets  Opt Data len = N-2
- Null Option Data (variable) : N-2 octets nuls. 55
IPv6

 L'option “Jumbo payload”
 Option type =194
- Pour des paquets de données dont la taille dépasse 65535 octets (et < 4 Go !).
- Requiert un alignement en frontière de 4n+2.
- Jumbo Payload Length = longueur du paquet en octets à l'exclusion de l'entête IPv6
mais en incluant les entêtes optionnelles y compris l'entête Hop-by-hop.
- Le champ Payload Length de l'entête IPv6 est mise à zéro.
- La présence de l'option Jumbo Payload de l'en-tête Hop-by-hop exclut celle d'un
en-tête Fragmentation.
 Option invalide (longueur) ou incompatible (en-tête Fragment) :
 message ICMP code 0 (Parameter problem) 56
IPv6
L'entête Routing
 Next header = 43.
 informations examinées par chaque destinataires intermédiaires.
. Next Header (1 octet) : identifie la prochaine entête.

. Hdr Ext Len (1 octet) : longueur totale de l'entête optionnelles Routing (moins les 8 premiers octets)
en multiples de 8 octets.
. Routing Type (1 octet) : identifie un format spécifique pour les données.
. Segment Left : nombre de destinataires intermédiaires restant à atteindre pour parvenir au
destinataire final.
. type-specific data (variable) : champ contenant la liste des destinataires intermédiaires, c-à-d la
route à suivre par le paquet. 57
IPv6
L'entête Routing
 L'entête Routing de type 0
. Le champ Routing Type = 0
. Similaire à l'option Source Routing de IPv4.
. Hdr Ext Len (1 octet) : 2 fois le nombre de champs Address ( 46)

. Segments left (1 octet) : nombre de noeuds intermédiaires restant à visiter (≤ 23 : ceci est
controversé).
. Strict/loose bit map (3 octets) :
- à chaque bit correspond l'adresse de même numéro.
- précise si l'adresse est celle d'une station qui doit être adjacente à la station précédente
(1 : strict routing) ou non (0 : loose routing). 58
IPv6
L'en-tête Routing

. Pas d'adresse multicast.
. Le bit de poids faible du champ Bit Map précise le routage vers le nœud correspondant au champ
Destination Address de l'entête IPv6.
. Plusieurs entêtes Routing peuvent se suivre :
 spécification de chemins aussi longs que voulu.
59
IPv6
L'en-tête Routing
Ex,
60
IPv6
L'en-tête Routing
L’option de routage de type 2 (Routing Header Type 2) de l’extension de routage permet de

spécifier l’adresse IPv6 du vrai destinataire du paquet IP. Le nœud ayant son adresse
spécifiée dans le champ destinataire de l’en-tête IPv6 initial devra remplacer son adresse
par l’adresse IPv6 contenue dans cet en-tête d’extension.
Par exemple, dans la mobilité IPv6, le nœud correspondant peut spécifier dans cet en-tête
d’extension, la HoA du nœud mobile et insérer dans le champ Destination Address de l’en-
tête IPv6, la CoA de ce même nœud mobile. A la réception, ce dernier substitue son
adresse CoA par sa HoA contenue dans l’extension. Cela permet d’éviter les conséquences
de l’encapsulation.
61
IPv6
L'entête Fragment
 Next header = 44.
 Transmettre des paquets plus grands que le MTU du chemin.
 La segmentation n'a lieu qu'à l’émetteur et le réassemblage n'a lieu qu'au récepteur.

. Reserved (1 octet) : initialisé à 0, ignoré au récepteur.
. Fragment Offset (13 bits) : le déplacement (en unités de 8 octets) des données suivant cette entête
relativement au début de la partie fragmentable du paquet initial.
. Res (2 bits) : 00.
. M (1 bit) :
- 0 = dernier fragment,
- 1 = il existe des fragments du même paquet qui suivent.
. Identification (4 octets) : identifie tous les fragments appartenant au même paquet initial. Similaire au
même champ (de 16 bits) d'IPv4. 62
IPv6
L'entête Fragment
 Constitution des fragments
 Au sein du paquet initial, on distingue 2 parties :
- celle non-fragmentable, contient tous les en-têtes précédant l'en-tête Routing (y compris ce
dernier, si il existe), à savoir les extensions Hop-By-Hop, de destination pour les nœuds
intermédiaires, de routage de type 0.
- celle fragmentable, le reste du
paquet initial (les autres en-têtes
et les données).
 Procédé assez proche d'IPv4.

63
IPv6
L'entête Fragment
 Constitution des fragments

- Tous les fragments d'un même paquet initial ont les mêmes entêtes issues de la partie non-
fragmentable de ce paquet,
- Sauf pour l'entête IPv6 :
. elle conserve tous ses champs,
. sauf le champ Payload length qui contient la longueur utile de son fragment.
- Un entête Fragment est ajoutée à tous les fragments :
. en assurant le chaînage des champs Next Header avec les entêtes précédentes et suivantes.
. en mettant à jour les champs Fragments Offset, M.
. leur champ Identification contiennent tous la même valeur.
. placé entre la partie non-fragmentable et la portion fragmentée.
64
IPv6
L'entête Fragment
 Réassemblage des fragments

 Le réassemblage n'a lieu qu'au destinataire final.
. Le premier fragment :
- contient un champ Fragment Offset =0.
- permet la restitution de la suite d'entêtes du paquet initial
. Le dernier fragment :
- contient un bit M = 0.
- permet de recalculer la taille utile du paquet initial.
. Calcul de la longueur utile du paquet initial.
. Calcul et vérification que tous les fragments sont présents.
. Reconstitution du paquet initial.
 la longueur utile du paquet initial < 65535 octets.
65
IPv6
L'entête Fragment
Taille des paquets

- Le MTU des liaisons IPv6 576 octets :
 la couche inférieure doit posséder une fonction de fragmentation /réassemblage
spécifique pour assurer ce service, si nécessaire.
- Si un nœud veut utiliser une longueur supérieure à 1500 octets, il doit auparavant
s'être assurer que le destinataire le tolère.
- Les nœuds IPv6 doivent utiliser la technique de recherche du MTU de chemin :

 rfc 1191 : technique par essai/erreur
 utilisée par IPv4.
 le Do Not Fragment bit est implicite dans IPv6.
 Pour IPv6 le message ICMP "Datagram too big" indique la valeur exacte du MTU.
66
IPv6
L'entête Fragment
 Exemple : Envoi de 3400 octets de données ICMPv6 + 8 octets d’en-tête ICMPv6 Echo
Request (soit 3408 octets après l’en-tête IPv6)
67
IPv6
L'entête Fragment
Exemple 1456 = 8 octets (en-tête de fragmentation + 1448 octets de fragment des 3408 octets)
1er fragment  offset = 0
Car ce n’est pas le dernier

fragment
68
IPv6
L'entête Fragment Description des en-tetes d’extension
Exemple 1456 = 8 octets (en-tête de fragmentation + 1448 octets de fragment des 3408 octets)
2ème fragment  offset = 181

181 = 1448/8
Car ce n’est pas le dernier

fragment
69
IPv6
L'entête Fragment
Exemple
3ème fragment  offset =

362 = 0 + 181 + 181
c’est le dernier fragment
520 = 3408 – 2 x 1448 +8 = 8 octets (en-tête de fragmentation + 512 octets de fragment restant 70
IPv6
L'entête Destination Options
 Next header = 60.

 contient les informations qui doivent être analysées par le (ou les) destinataires final(aux).
. l'inverse de l'entête Hop-by-hop Options, mais le format est similaire.
. Permet de minimiser le nombre d'en-têtes optionnels.

. Hdr Ext Len (1 octet) : longueur totale de l'entête optionnelles Routing (moins les 8 premiers
octets) en multiples de 8 octets.
. Options (variable) : contient une ou plusieurs options.
- les seules options actuellement normalisées sont Pad1 et Padn.
- celles qui sont utilisées par l'en-tête Hop-by-hop Options.
71
IPv6
L'entête Destination Options
L’option Home Address

Cette option permet de spécifier au destinataire d’un paquet IPv6, l’adresse du véritable
émetteur de ce paquet reçu.
Par exemple, dans la mobilité IPv6, cette option peut contenir la HoA du mobile lorsque le
mobile s’adresse directement à un correspondant. Ce dernier devra substituer la CoA
contenue dans le champ Source Address de l’en-tête du paquet IPv6 par l’adresse HoA du
mobile afin de maintenir les sessions précédentes.
Next Header Hdr Ext. Len Option Type Option Length

0x3C 0xC9 0x10
Home Address (HoA)
72
IPv6
 En-têtes de sécurité
IPv6 introduit deux services de sécurité :
- L'authentification (rfc 1826)
- La confidentialité (rfc 1827)
 L'authentification permet de certifier :

- l'émetteur du message, et autres infos générales,
- le contenu du message (son intégrité).
La confidentialité assure que les infos protégées ne seront pas lus par des tiers.
Ces deux services sont basés sur des techniques cryptographiques.

L'émetteur et le(s) récepteur(s) partagent une association de sécurité :
- contexte de sécurité (l'algorithme, les paramètres, la clef)
- un identificateur de ce contexte (Security Association identifier)
Ces services ne sont mis en œuvre que par les nœuds d'extrémité (surcoût).
73
IPv6
 L'en-tête Authentification
 Next Header = 61
 Principe :
- une signature est calculée à partir des infos
grâce à un procédé secret.
- l'émetteur place cette signature dans le
paquet avec les infos.
- le récepteur vérifie que la signature reçue
correspond à la signature re-calculée.
 Le mode de hachage est basé sur la
cryptographie à clé symétrique (la clé est
partagée aux deux interlocuteurs). Il permet de
rendre possible l'intégrité et l'authentification des datagrammes IPv6
 Attention aux champs qui sont modifiées par les routeurs.
 Next header (1 octet): le code du prochain header
(normalement TCP).
 Hdr length : la longueur du champ Authentification
data en mots de 32 bits. L'entête s'adapte à toutes
les longueurs de signature.
 Security parameters index : identifie le contexte.
 Authentification data : la signature (clef d'authentification). 74
IPv6
 L'en-tête Authentification
L’utilisation de l’en-tête d’extension de sécurité AH se fait selon deux modes :
le mode Transport
le mode tunnel
AH en mode Transport
AH en mode Tunnel
NB: L’ancien et le nouvel en-tête peuvent contenir des en-têtes d’extension

75
IPv6
L’en-tête de chiffrement ESP
ESP (ou Encapsulating Security Payload) pour IPv6 permet d'apporter l'intégrité, l'authentification et la
confidentialité dans les datagrammes IPv6. Les données sont chiffrées et le chiffrement est basé sur la
cryptographie à clé symétrique .
Next Header = 62
 Le procédé d'encodage peut être :

- un procédé de chiffrement (RC2, MD5, PGP, DES, RSA, ITU X.509, etc.),
- une compression (LZ77, LZS, etc.).
 Security Association Identifier : identifie le contexte de sécurité (idem SPI)

 Opaque transform data : ce sont les données encodées. Le format dépend de l'encodeur choisi.
76
IPv6
Exemple l’entête ESP et le chiffrement DES
Exemple : DES-CBC (Data Encryption Standard) par défaut.
. Synchronization data :
- données initiales pour le procédé de calcul
- par un générateur aléatoire
- rendre + difficile le décodage
. Payload data : les données chiffrées
. Padding : le bourrage
. Payload type : précise le type des données (par ex. TCP)
77
IPv6
L’en-tête de chiffrement ESP
ESP en mode transport
ESP en mode tunnel
78
Chapitre I. PROTOCOLES I.6 Nouveaux protocoles:
ICMPv6, NDP, MLD
ICMPv6
• Couvertures de dispositifs ICMP (v4):
Contrôle d’erreurs, Administration, …
• messages de transports ND:

NS, NA, RS, RA Nouvelles
• messages de transports MLD: caractéristiques
Requêtes, Rapports, …
Deux classes de messages (suivant le champs « type »):

• de 0 à 127 Messages d'erreur
• de 128 à 255 Messages d'information
Messages d'erreur les plus courants:
• Destination inaccessible (1)
• Paquet trop grand (2)
• Temps dépassé (3)
• Paramètre non reconnu (4)
79
ICMPv6, NDP, MLD
ICMPv6
- Message type : type de message code sur 8 bits

- Code : code pour les messages d'erreur
- Donnees ICMP : Selon le type de message
80
ICMPv6, NDP, MLD
ICMPv6
81
ICMPv6, NDP, MLD
ICMPv6
82
ICMPv6, NDP, MLD
ICMPv6
Exemple d’utilisation ICMP : Problèmes avec le MTU
• Le MTU de lien minimum pour IPv6 est de 1280 octets

(contre 68 octets pour IPv4)
 Sur les liens de MTU < 1280, la fragmentation sur ces liens spécifiques doit être
effectuée
• On s’attend à effectuer la découverte du MTU de chemin (pMTU) pour envoyer des paquets de
taille supérieure à 1280
• L’exécution minimale peut omettre la découverte de pMTU tant que tous les paquets ont
gardés une taille ≤ 1280 octets
83
ICMPv6
Avec IPv6 les routeurs ne doivent plus fragmenter les
Découverte du Path MTU paquets qui sont transmis. Le MTU minimum doit être
de 1280 pour un lien souhaitant supporter IPv6
La nécessité d’adapter la taille des paquets à transmettre pour un flot important de
données existe quand même. Si elle n’est pas réalisée par les routeurs, la fragmentation
doit donc se faire à la source.
Un algorithme de découverte permet de connaître la taille optimale des paquets à
transmettre est appelé Path MTU Discovery et est décrit dans le [RFC1981]:
1. Le nœud source considère que le MTU du chemin considéré est égal au MTU du
premier saut de ce chemin.
2. Envoi d’un paquet à la destination.
3. Si réception d’un message ICMPv6 de type Packet To Big, la source réduit le MTU
courant. Retour à l’étape 2.
4. Si pas de réponse de la destination, retourne à l’étape 2.
5. Si réponse de la destination, le MTU du chemin est le MTU courant.
Sur certains liens, le MTU peut varier au cours de la communication. S’il diminue, la
détection de la variation sera détectée par la réception d’un message ICMPv6 de type
Packet To Big. Afin de tirer partie d’une augmentation de MTU, la source réeffectuera
l’algorithme à intervalles réguliers. 84

ICMPv6, NDP, MLD
ICMPv6
Découverte du Path MTU
D:\>ping -l 1500 pc-ipv6
Pinging pc-ipv6 [3ffe:c15:c003:1114:210:a4ff:fec7:5fcf] 1

Request timed out. 2
Reply from 3ffe:c15:c003:1114:210:a4ff:fec7:5fcf : time=3ms
Reply from 3ffe:c15:c003:1114:210:a4ff:fec7:5fcf : time=3ms 3
Reply from 3ffe:c15:c003:1114:210:a4ff:fec7:5fcf : time=3ms
Too 2 1500
netsh interface ipv6>show destinationcache
Interface 6: LAN Big 3
PMTU Destination Address Next Hop Address 1480 1 1480
---- --------------------------------------------- --------------------------
1480 3ffe:c15:c003:1112::1 3ffe:c15:c003:1112::1
85

ICMPv6, NDP, MLD
Neighbor Discovery (RFC 4861)
• Remplace ARP IPv4
• Ajoute en plus une fonctionnalité (ex. recherche de routeur, adressage Stateless,
etc.)
• Nœud IPv6 qui partage le même médium physique(lien) utilisant la recherche du
voisin (ND) pour:
- découvrir leur présence mutuelle
- déterminer les adresses de la couche liaison de leur voisin
- rechercher des routeurs
-Maintenir la portabilité de l’information des voisins (NUD)
• => pas applicable aux réseaux NBMA (ATM, Frame Relay, ..) car ND utilise le
multicast
86
ICMPv6, NDP, MLD
ND définit 5 types de paquets ICMP:
● Router Advertisement (RA): annonce périodique qui contient:
- Liste des préfixes utilisés sur le lien
- Valeur possible du « nombre de sauts »
- Valeur du MTU
● Router Solicitation (RS)
- l'hôte veut un RA immédiatement
● Neighbor Solicitation (NS)

- pour déterminer l'adresse MAC d’un voisin ou vérifier sa présence
- utiliser pour tester duplication d'adresse (DAD)
● Neighbor Advertisement (NA)
- réponse à un paquet NS
- avertir le changement d'une adresse MAC
● Redirect: utilisé par un routeur
- pour informer un hôte d'une meilleure route
- équivalent de l’ICMP redirect
87
Router Solicitation (RS)
Type=133 Code=0 Checksum

Réservé ou
Option
(Adresse physique de la source)
• Au moment du démarrage, les nœuds envoient des sollicitations de routeur pour recevoir
promptement des annonces de routeur
RS
1
88
ICMPv6, NDP, MLD
• Les routeurs envoient périodiquement des RA à l'addresse
Router Advertisement (RA) multicast ''tous les noeuds‘’
RA
RS
1 2

Saut max. MOH ----- Durée de vie du routeur
- Src = Link-local du routeur
Durée d’accessibilité
- Dst = Multicast: “tous les nœuds”
Temporisation de retransmission
ou Adresse IPv6 unicast de l’émetteur du RS
Option
(Adresse physique de la source, Information
-champ saut max. non nul
sur le préfixe (un ou plusieurs), MTU) - M indique qu'une adresse de l'équipement doit être obtenue
avec un protocole de configuration
- O indique aussi la présence d'un service de configuration mais
pour la récupération d'informations autres que l'adresse.
- H indique que le routeur peut être utilisé comme «agent mère»
pour un nœud mobile
89
Router Advertisement (RA)

Saut max. MOH ----- Durée de vie du routeur
Durée d’accessibilité
Temporisation de retransmission
Option
(Adresse physique de la source, Information
sur le préfixe (un ou plusieurs), MTU)
90
ICMPv6, NDP, MLD
Neighbor Solicitation (NS)
 Repose sur un cache associant une adresse IPv6 et une adresse MAC
- rafraichissement automatique des informations en sollicitant les voisins
(s'il y a des données a envoyer)
- type : routeur ou machine
- temps écoulé depuis le dernier NA ou RA
- état : incomplète (pas de réponse), reachable (joignable), stale (perime), probe (sonde),...
Comment solliciter un voisin ?

 Objectif : joindre un nœud dont on connait l'adresse IPv6 mais pas l'adresse MAC
 Groupe multicast sollicite (node solicited multicast)
 Portée : locale
 Intérêt : évite l'envoi de « broadcast »
 Construction :
- Préfixe FF02::
- Séquence ::1:FF
- les 24 derniers bits de l'adresse IPv6
91
Neighbor Solicitation (NS)
Exemple: A veut envoyer un

paquet IPv6 à B

Réservé
Adresse IPv6 de la cible
Option
- L'adresse MAC de B est absente A B

de son cache
- A envoie un NS en multicast
@IPv6 = FE80::E860:6E48:DCBB:5218 @IPv6 = FE80::C800:8FF:FEEC:0
@MAC = 00:1F:E1:D8:05:1A @MAC = CA:00:08:EC:00:00

Neighbor Advertisement (NA)
Exemple: B répond au NS envoyé par A

RSO Réservé
Option
A B
- B reçoit la sollicitation
- B envoie un Neighbor Advertisement
en unicast
@IPv6 = FE80::E860:6E48:DCBB:5218 @IPv6 = FE80::C800:8FF:FEEC:0
- A met à jour son cache
@MAC = 00:1F:E1:D8:05:1A @MAC = CA:00:08:EC:00:00
C
93
ICMPv6, NDP, MLD
Redirection A B
• La Redirection est utilisée par un R2 2001:4318:2:1::1

routeur pour signaler le
2001:4318:2:1::/64
reroutage d’un paquet à un R1
meilleur routeur
Src. Ether= 08:00:20:0a:aa:6d (@MAC de A)
Dst Ether = @MAC de R2 (routeur par défaut) 2001:4318:2:2::/64
Code=0
Src. IP = 2001:4318:2:1::1
Type=137 Checksum
Dest. IP = 2001:4318:2:2::1 C
Réservé
2001:4318:2:2::1
Redirect:
Src = @LL de R2
Dst = @A
Data = meilleur routeur = @R1
Adresse IPv6 de destination Destination IP: 2001:4318:2:2::1 (pc-C)
Option (Type 2): Cible =@MAC de R1
Option
(Adresse physique de la cible, En-tête rédirigé)
94
ICMPv6, NDP, MLD
MLD
 Protocole d’interaction entre le(s) routeur(s)
multicast du LAN et les hôtes multicast du
LAN
 Equivalent à IGMPv2 …. APPLICATION ..….
Permet à un hôte de s'abonner (désabonner)

TCP UDP
à un groupe et dire au routeur:
«Je veux m’abonner au groupe multicast ….. TRANSPORT ……
d’adresse ff0e::xxxx et recevoir les flux

correspondants» IGMP ICMP ICMPv6
• Deux versions : MLDv1 et MLDv2 ND MLD
• Sous-ensemble de ICMPv6 IPv4 ……. RESEAU ……….

IPv6
• MLDv2
- recensement des récepteurs multicast (130) ARP
- rapport d’abonnement multicast (143)

Ethernet ….. LIAISON DE ……
Ethernet
• autorise l’écoute d’un ensemble défini de DONNEES
participants au groupe multicast (sélection de la

source) Pile IPv4 Pile IPv6
95
Exemple: Message MLDv2
TCP UDP
96

Cours

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cours

Загружено:

Авторское право:

Доступные форматы

Support de cours

 épuisement des adresses IP publiques dû à la planification de l’adressage en classes a

 faible disposition pour la gestion de la QoS

Adressage privé (RFC 1918) & NAT (Network Address Translation)

 Appel à la restitution de blocs d’adresses inutilisés à l’IANA (RFC 1917)

 Impossibilité de réutilisation du bloc réservé

 Derniers blocs distribués le 3 Février 2011 aux RIR

RIR Espace disponible Date d'épuisement

la demande en adresse IPv4 peut faire augmenter son prix

Les adresses IPv4 deviennent plus chères

Un marché noir d’adresse IPv4 voit le jour

Quelles sont les solutions trouvées aux problèmes persistants ?

Ultime solution de l’IETF

Ultime solution de l’IETF

Principales modifications d’IP

 Infrastructure d'adressage et de routage efficace et hiérarchique

Principales modifications d’IP

 Meilleur support pour QoS

Principales modifications d’IP

- Authentification + Confidentialité des données

 Nouveau protocole pour l'interaction de nœuds voisins

 Gestion aisée et efficace de la mobilité IP

 Fonctionne sur la même infrastructure physique

 Une trame de couche liaison contenant un paquet IPv6 présente :

- Pour l'encapsulation IEEE

 Duration/ID indique la durée d'utilisation du canal

I.5.1 Au niveau des applications et des systèmes d’exploitation

I.5.1 Au niveau des applications et des systèmes d’exploitation

I.5.1 Au niveau des applications et des systèmes d’exploitation

 De nombreuses applications supportent IPv6:

I.5.2 Au niveau des routeurs

- Représenté sur 4 bits

 identifie les différents types de trafics.

- La nature du traitement spécifique doit être transmise aux routeurs à l'aide :

- Un paquet ayant un champ Flow Label=0 n'est associé à aucun flot.

Le champ HOP LIMIT

1 ICMPv4 51 Authentication Header

6 TCP 59 No Next Header

17 UDP 60 Destination Options Header

41 Encapsulated IPv6 Header 88 IGRP

43 Routing header 89 OSPF

44 Fragment Header 135 Mobilité 42

Les champs Source and Destination Address (16 octets)

 Plusieurs façons de représenter les adresses IPv6

 Représentation des adresses IPv6 : forme abrégée

- L'adresse IPv6 compatible IPv4

- L'adresse IPv4 mappée

 L’en-tête d’extension de proche en proche (Hop-by-Hop), code 0

 Les options peuvent être traitées :

 La taille des en-têtes optionnels est exprimée en unités de 8 octets.

 Next Header (1 octet) : identifie le prochain en-tête.

Les options de l'en-tête “Hop-by-hop options”

- Option Type (1 octet) : identifie le type de l'option

Les options de l'en-tête “Hop-by-hop options”

Les options de l'en-tête “Hop-by-hop options”

 Pad1 : option type =0

 Padn : option type =1

Les options de l'en-tête “Hop-by-hop options”

. Next Header (1 octet) : identifie la prochaine entête.

. Hdr Ext Len (1 octet) : 2 fois le nombre de champs Address ( 46)

 L'entête Routing de type 0

L’option de routage de type 2 (Routing Header Type 2) de l’extension de routage permet de

. Next Header (1 octet) : identifie la prochaine entête.