L'adressage IPV6 - Michel MARIEsitemm.michel-marie.net/network/Docs/CoursIPv6.pdf · adressage ipv6...

Adressage IPv6 – Référence http://livre.g6asso.fr Page n° 1

Michel MARIE

L'adressage IPV6

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

5 MECANISME DE DECOUVERTE DU MTU (PATH MTU) 27

5.1 PRINCIPE DU MECANISME DE DECOUVERTE DU PMTU 27

6 LES MECANISMES DE TRANSITION 27

6.1 PROTOCOLE 6TO4 27 6.2 RELAIS 6TO4 28 6.3 PROTOCOLE 6RD (IPV6 RAPID DEPLOYMENT) 29 6.4 TRADUCTION NAT64 – DNS64 30 6.5 PROTOCOLE ISATAP 31 6.6 PROTOCOLE TEREDO 33

7 LES COMMANDES DE CONFIGURATION ET DE CONTROLE 34

7.1 SUR UN SWITCH CISCO 34 7.2 SUR UN ROUTEUR CISCO 35 7.3 SOUS WINDOWS 35 7.3.1 COMMANDE D’AFFICHAGE DES ADRESSES IPV6 DE LA MACHINE. 36


Michel MARIE

7.3.2 AUTOCONFIGURATION D’ADRESSE, ROLE DU ROUTEUR 37 7.3.3 COMMANDE D’AFFICHAGE ROUTES IPV6 DE LA MACHINE. 42 7.3.4 COMMANDE D’AFFICHAGE DES VOISINS IPV6 DE LA MACHINE. 42 7.4 SOUS LINUX 42 7.5 CHEZ APPLE 43

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.

1.1 Structuration des adresses et agrégation

Un des problèmes majeurs d'IPv4 est la croissance incontrôlée des tables de routage. Ce

phénomène est dû à une mauvaise agrégation des adresses dans les tables. Il faudrait être capable de

router des ensembles de réseaux identifiés par un seul descripteur. CIDR « Classless Inter-Domain

Routing » apporte une amélioration, mais celle-ci est insuffisante en pratique : les adresses IPv4 sont

trop courtes pour permettre une bonne structuration, et il faut surtout assumer le coût du passé avec

les adresses déjà allouées.

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/

http://g6.asso.fr/


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/

2.2 Les 3 types d’adresses IPv6

IPv6 reconnaît trois types d'adresses : unicast, multicast et anycast.

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


Michel MARIE

notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour

l'avenir.

Préfixe IPv6 Utilisation Référence

RFC3513

0000::/8 Réservé pour la transition et loopback

0100::/8 Réservé

0200::/7 Réservé (ex NSAP « Newtork Service Access Point »)

0400::/6 Réservé (ex IPX «Internetwork Packet Exchange » )

0800::/5 Réservé

1000::/4 Réservé

2000::/3 Unicast Global Address "UGA"

4000::/3 Réservé

6000::/3 Réservé

8000::/3 Réservé

A000::/3 Réservé

C000::/3 Réservé

E000::/4 Réservé

F000::/5 Réservé

F800::/6 Réservé

FC00::/7 Unique Local Unicast "ULA"

FE00::/9 Réservé

FE80::/10 Lien-local Unicast "LLA"

FEC0::/10 Réservé

FF00::/8 Multicast

Exemple d’adresses réservées, les adresses de serveur DNS par défaut :

FEC0 :0 :0 :FFFF ::1

FEC0 :0 :0 :FFFF ::2

FEC0 :0 :0 :FFFF ::3

2.2.1 Adresses unicast Globales – 2000::/3

a) Plan d'adressage agrégé ou "Aggregatable Global Unicast Address Format" (RFC3587).

00 SID Identifiant ou Interface ID (IID)

Topologie publique

1

Adresse du lien ou noeud

Global Prefix

Topologie locale

3 45 16 64

Ces adresses se décomposent en 3 champs :

un premier champ de 48 bits (Global Prefix), désigné sous le terme topologie publique, alloué par

le fournisseur d’accès,

un second champ de 16 bits (Subnet ID), décrit la topologie locale du site, il permet de coder les

sous-réseaux du site,

un dernier champ de 64 bits (Interface ID), identificateur unique d'interface, qui permet

d’identifier un nœud machine sur le réseau.

b) Gestion du préfixe global.

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) ».


Michel MARIE

Les « RIR » subdivisent généralement les blocs en /32 (un bloc de /23 sera subdivisé en 512

blocs de /32) puis distribués aux « LIR ».

Les LIR (opérateurs régionaux ou fournisseurs d’accès Internet) subdivisent à leur tour les blocs

/32 en blocs /48 pour les distribuer aux clients.

(cf. http://www.iana.org/assignments/ipv6-unicast-address-assignments)

Pour l’Europe la distribution est à la charge du RIPE - NCC « Réseaux IP Européens - Network

Coordination Center ».

Il existe plusieurs réservations dans ce plan d'adressage. En voici quelques exemples :

historiquement la première (préfixe 3FFE::/16) a servi aux réseaux expérimentaux,

une seconde (préfixe 2001::/16) est allouée par l’IANA aux RIR par blocs de /23 à /12, certains

blocs ont un usage particulier :

o 2001::/32 pour Teredo (Tunnel IPv6 Over UDP Through NAT),

o 2001:2::/48 pour des tests de performances,

o 2001:DB8::/32 : réservée « à la documentation », c’est-à-dire qu’elle est réservée à un

usage au sein des publications type documentations, articles techniques et exemples, les

adresses disposant de ce préfixe ne sont jamais routées sur Internet.

une troisième (préfixe 2002::/16) est dédiée au mécanisme de transition 6to4.

Une version des allocations est disponible sur le site de l’IANA.

http://www.iana.org/assignments/ipv6-unicast-address-assignments


Michel MARIE

c) Adresses de test.

La valeur 0x1FFE en tête du « Global Prefix » a été attribuée par l'IANA dans le plan d'adressage agrégé

pour les expérimentations (RFC 3701). Il correspond au préfixe 3FFE::/16.

00 SLA Identifiant ou Interface ID

Topologie publique

1

Adresse du lien ou noeudTopologie

locale

3 13 16 64

1FFE pTLA pNLA

X bits 32-X bits

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.

2.2.2 Identifiant d’interface

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.

a) Identifiant d’interface EUI-64 « Extended Unique Identifier – 64 bits ».

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.

U G Constructeur (16 bits)

40 bits24 bits

IEEE EUI64

Constructeur (6 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.


Michel MARIE

EUI64

U G

24 bits

Numéro de série (24 bits)

U G Constructeur (16 bits)

24 bits

0xFF 0xFE Numéro de série (24 bits)

identifiant

IPv61 0 Constructeur (16 bits) 0xFF 0xFE Numéro de série (24 bits)

Construction de l’identifiant IPv6 au format non canonique

IEEE EUI48

Constructeur (16 bits)Constructeur

(6 bits)

Constructeur (6 bits)

Constructeur (6 bits)

U G

b) Identifiant d’interface manuel.

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 ».

c) Identifiant d’interface aléatoire.

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


Michel MARIE

2.2.3 Adresses lien local – FE80::/10

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).

L'adresse est obtenue en concaténant FE80::/64 aux 64 bits de l'identifiant d'interface.

L'identifiant d'interface est généralement basé sur l'adresse MAC. Contrairement aux adresses globales,

les adresses lien-local ne sortent jamais du réseau local où elles sont utilisées.

0 Identifiant ou Interface ID

Adresse du lien ou noeud

10 54 64

FE80

Préfixe

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.

Portée de l’adresse lien local (Scoped Address)

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.

C:\Users\Michel>netsh interface ipv6 show interfaces

Idx Mét MTU État Nom

--- ---------- ---------- ------------ ---------------------------

1 50 4294967295 connected Loopback Pseudo-Interface 1

12 25 1500 connected Connexion réseau sans fil

19 25 1500 disconnected Connexion réseau sans fil 2

26 30 1280 connected isatap.ramses.ii

30 30 1280 connected isatap.{3055F1B9-92D4-448D-A6A1-FE8897423747}

11 10 1500 disconnected Connexion au réseau local

42 50 1280 disconnected isatap.{71C81183-6EF4-45E5-A1FF-8A4BBF3983C4}

21 50 1280 disconnected Teredo Tunneling Pseudo-Interface

C:\Users\Michel>netsh interface ipv6 show addresses

Interface 12 : Connexion réseau sans fil

Addr Type État DAD Vie valide Pers. Fav. Adresse

--------- ----------- - --------- ---------- ------------------------

Temporaire Préféré 23h54m36s 23h54m36s 2a01:e34:ef48:20:5919:4c3f:dffb:1a3a

Public Préféré 23h54m36s 23h54m36s 2a01:e34:ef48:20:ad93:ef4b:7794:727a

Autre Préféré infinite infinite fe80::ad93:ef4b:7794:727a%12


Michel MARIE

2.2.4 Adresses Uniques Locales (Unique Local Unicast, ex Site Local Address) - FC00::/7

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 :

Global ID Identifiant ou Interface ID

7 40 64

FC

Préfixe

Subnet ID

161

L=1

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.

Le site suivant http://www.sixxs.net/tools/grh/ula/ permet de créer et d’enregistrer une adresse ULA à

partir d'une adresse MAC.

http://www.sixxs.net/tools/grh/ula/


Michel MARIE

2.2.5 Adresses particulières qui n’utilisent pas l’interface ID

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.

b) Adresse de bouclage. ::1

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.

c) Adresses IPv4 mappées.

Elles sont représentées sous la forme ::FFFF:XXXX:YYYY où XXXXYYYY est la représentation

hexadécimale de l'adresse IPv4.

80 bits 32 bits

0xFFFF

Adresse IPv4 mappée

0 Adresse IPv4

16 bits

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.


Michel MARIE

Cela permet, entre autres, d'écrire des serveurs (au sens client/serveur) qui peuvent répondre à la fois à des

requêtes IPv4 et IPv6 dans le même programme. Cela nécessite bien sûr d'avoir une machine à double pile de

communication IPv4 et IPv6.

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.

2.2.6 Adresses Multicast - FF00::/8

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).

Les adresses Multicast sont caractérisées par le préfixe FF00::/8.

8 bits 112 bits4 bits 4 bits

FF Group_ID

Adresse multicast IPv6

0RPT scope

L’adresse Multicast est constituée de :

un premier champ de 8 bits qui identifie toute adresse multicast, FF00::/8,

un deuxième champ flags, constitué de 4 bits dont un réservé pour extensions futures (mis à 0).

o T (Transient) : T = 0 signale une adresse permanente, autrement c’est une adresse

multicast temporaire.

Les deux bits R et P sont décrits dans le RFC 3306 et RFC 3956.

o P (Prefix Base Address).

o R (Embedded RP Address).

le troisième champ scope, constitué de 4 bits indique le niveau de diffusion. Les différentes

valeurs de ce champ sont :

0 = réservé,

1 = portée interface local,

2 = portée lien local,

3 = portée subnet local,

4 = portée admin local,

5 = portée site local,

8 = portée organisation locale,

E = portée globale,

F = réservé.

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,


Michel MARIE

ff02::9 = tous les routeurs RIP (message RIP Update) du lien,

ff02::A = tous les routeurs EIGRP du lien,

ff02::FB = tous les DNSv6 du lien,

ff02::1:2 = (All-dhcp-agents), tous les agents serveur DHCPv6 du lien.

ff02::1:ff00:0/104 = groupe multicast de sollicitation de nœud. L’adresse de

sollicitation de nœud est composée de FF02::1:FF00:0/104 concaténé aux 24

derniers bits de l’adresse IPv6 du nœud.

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.

Autre exemple : Group ID 101 serveurs NTP

FF01::101 : tous les serveurs NTP sur le même nœud que l’émetteur,

FF02::101 : tous les serveurs NTP sur le même lien que l’émetteur,

FF05::101 : tous les serveurs NTP sur le même site que l’émetteur,

FF0E::101 : tous les serveurs NTP sur tout l’Internet.

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…

2.2.7 Adresses Anycast

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.

N bits 128 – N bits

Id Anycast

Adresse Anycast IPv6 « sous-réseau »

Préfixe réseau

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.


Michel MARIE

64 bits 57 bits

11111101………….11

Adresse Anycast IPv6 « spécifique d’un réseau /64 »

Préfixe réseau /64

7 bits

Id Anycast

N <64 bits 121-N bits

11111111………….11

Adresse Anycast IPv6 « spécifique d’un réseau < /64 »

Préfixe réseau < 64 bits

7 bits

Id Anycast

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

2.3 Durée de vie des adresses

IPv6 généralisant le plan d'adressage CIDR, les préfixes restent dans tous les cas la propriété des

opérateurs. Ils ne peuvent plus être attribués "à vie" aux équipements.

Pour faciliter la renumérotation d'une machine, l'attribution d'une adresse à une interface est faite

temporairement, les adresses IPv6 ne sont pas données mais prêtées.

Une durée de vie est associée à l'adresse qui indique le temps pendant lequel l'adresse appartient à

l'interface. Quand la durée de vie est épuisée, l'adresse devient invalide, elle est supprimée de l'interface et

devient potentiellement assignable à une autre interface. Une adresse invalide ne doit jamais être utilisée

comme adresse dans des communications. La valeur par défaut de la durée de vie d'une adresse est de 30

jours. L'adresse lien-local a une durée de vie illimitée.

La renumérotation d'une interface d'une machine consiste à passer d'une adresse à une autre. Lors

d'une renumérotation, il n'est pas souhaitable de changer brusquement d'adresse.

Pour faciliter cette transition, un mécanisme d'obsolescence est donc mis en place pour invalider

progressivement une adresse. Ce mécanisme s'appuie sur la capacité d'affectation de plusieurs adresses

valides à une même interface.

Ensuite pour effectuer le choix de l'adresse à utiliser, un état est associé. Il indique dans quelle phase

de sa durée de vie une adresse se situe vis-à-vis de l'interface. Le premier de ces états est qualifié de

préféré : l'utilisation n'est aucunement restreinte. Peu avant son invalidation l'adresse passe dans un état

de déprécié. Dans cet état, l'utilisation de l'adresse est déconseillée, mais pas interdite. L'adresse dépréciée

ne doit plus être utilisée comme adresse de source pour les nouvelles communications (comme

l'établissement de connexion TCP). Par contre l'adresse dépréciée peut encore servir d'adresse de source

dans le cas des communications établies. Les paquets reçus à une adresse dépréciée continuent à être

remis normalement. À la durée de vie de validité d'une adresse, il est également associé une durée de vie

pour son état préféré.


Michel MARIE

2.3.1 États des adresses automatiquement configurées

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.

2.3.2 Types de configuration automatique

Il existe trois types de configuration automatique :

Sans état : la configuration des adresses repose sur la réception de messages d'annonce de

routeurs. Avec état : la configuration repose sur l'utilisation d'un protocole de configuration d'adresse avec

état DHCPv6 pour obtenir des adresses et d'autres options de configuration. Un hôte utilise la

configuration d'adresse avec état lorsqu'il reçoit des messages d'annonce de routeurs qui ne

comprennent pas de préfixes d'adresse et dont la prise en charge suppose que l'hôte utilise un

protocole de configuration d'adresse avec état. Les deux : la configuration repose sur la réception de messages d'annonce de routeurs. Ces

messages comprennent des préfixes d'adresse sans état et supposent que les hôtes utilisent un

protocole de configuration d'adresse avec état pour les paramètres supplémentaires (Adresse de

serveur DNS, etc…).

Pour tous les types de configuration automatique, une adresse lien-local est toujours configurée.


Michel MARIE

2.3.3 Processus de configuration automatique

Le processus de configuration automatique d'adresse pour un nœud IPv6 est le suivant :

1. Une adresse lien-local en tentative est dérivée à partir du préfixe lien-local FE80::/64 et de

l'identificateur d'interface 64 bits.

2. La détection d'adresses en double est exécutée pour vérifier l'unicité de l'adresse lien-local en

tentative.

3. Si la détection révèle une adresse en double, une configuration manuelle doit être réalisée sur le

nœud.

4. Si la détection ne révèle aucune adresse en double, l'adresse lien-local en tentative est considérée

comme étant unique et valide. L'adresse lien-local est initialisée pour l'interface. L'adresse

multidiffusion de couche liaison du nœud sollicité correspondante est enregistrée avec la carte

réseau.

Pour un hôte IPv6, la configuration automatique d'adresse continue comme suit :

1. L'hôte envoie un message de sollicitation de routeur.

2. Si aucun message d'annonce de routeur n'est reçu, l'hôte utilise un protocole de configuration

d'adresse avec état pour obtenir des adresses et d'autres paramètres de configuration.

3. Si un message d'annonce de routeur est reçu, les informations de configuration comprises dans le

message sont définies sur l'hôte.

4. Pour chaque préfixe d'adresse à configuration automatique sans état :

1. Le préfixe d'adresse et l'identificateur d'interface 64 bits approprié sont utilisés pour dériver une

adresse en tentative.

2. La détection d'adresses en double est utilisée pour vérifier l'unicité de l'adresse en tentative.

3. Si l'adresse en tentative est en cours d'utilisation, elle n'est pas initialisée pour l'interface.

4. Si l'adresse en tentative n'est pas utilisée, elle est initialisée : les durées de vie valide et préférée

sont définies d'après les informations figurant dans le message d'annonce de routeur.

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.


Michel MARIE

3.1.1 En-tête IPv6

L'en-tête du datagramme IPv6 est de longueur constante (40 octets).

Comparaison des en-têtes IPv4 – IPv6

En tête IPv4

0 15 16 31

Ver = 4

(4bits)

LET

(4bits)

Type de service

(8bits)

Longueur totale

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

(4bits)

Classe de trafic

(8 bits) DSCP (6bits)+ECN(2bits)

Identificateur de flux (Flow Label)

Taille (Payload length) Prochain en-tête Nbr sauts maxi

(Hop limit)

Adresse source (16 octets)

Adresse destination (16 octets)

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,

Valeur

(Next Header)

Type

(Option ou

Protocole)

Signification


Michel MARIE

4

Protocole

IP V4

6 TCP

17 UDP

45 Protocole de routage inter domaines

46 Resource Reservation Protocol

58 ICMP v6

0

Option

Hop-by-hop (transport d’informations

examinées par chaque routeur le long du

chemin emprunté)

43 Routing (routage par la source, contient

au moins l’adresse d’un nœud

intermédiaire par lequel passer le long

du chemin emprunté)

44 Fragment (fragmentation des paquets

par le nœud source)

50 Encapsulation Security Payload (ESP)

(informations pour le transport de

données chiffrées)

51 Authentification Header (AH)

(informations nécessaires à

l’authentification de l’en-tête)

60 Destination Options Header (transport

d’informations examinées uniquement

par le nœud destination)

194 Jumbogramme. Paquet dont la taille

dépasse 64ko. La taille max est ainsi

portée à 4Go.

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.

Les différents codes DSCP :


Michel MARIE

Pour l'instant deux types de comportement sont standardisés :

AFxx « Assured Forwarding » : définit quatre classes de services et trois priorités suivant que

l'utilisateur respecte son contrat, le dépasse légèrement ou est largement en dehors.

Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le

réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du

respect ou non des contrats (plus le chiffre est élevé, plus la priorité est faible, donc plus le

risque que le paquet soit rejeté en cas de congestion est forte),

EFxx « Expedited Forwarding » : réservé aux flux "temps réel", comparable à un circuit à débit

constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant

l'émission des paquets qui sont hors contrat. Il est recommandé de ne pas dépasser un débit

réservé supérieur à 30% de la bande passante du lien.

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…).

Gestion de la congestion « ECN » :

Les 4 combinaisons du champ ECN sont :

00 (NON-ECT) : transport incapable de gérer l'ECN,

10 (ECT0) : transport capable de gérer l'ECN,

01 (ECT1) : transport capable de gérer l'ECN,

11 (CE) : congestion subie.

Quand les deux extrémités de la transmission prennent en charge ECN, ils marquent leurs paquets avec

ECT0 ou ECT1. Si le paquet traverse un routeur congestionné, il peut changer cette valeur en CE, celle-

ci sera prise en compte par le récepteur d’extrémité.

Retour d’information via TCP, flags ECE et CWR :

Le bit ECE (ECN Echo) sert à informer l'émetteur qu'un paquet IP marqué par un routeur a été

reçu.

Le bit CWR (Congestion Window Reduced) sert à informer le récepteur que des mesures ont été

prises par l'émetteur en réduisant la taille de ses paquets.

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.


Michel MARIE

3.1.2 En-tête d'extension (Next Header de type Option)

Les en-têtes d'option se cascadent selon le format classique TLV "Type-Longueur-Valeur". La

longueur de l'option est exprimée en mots de 64 bits (n-1).

En tête IPv6 avec options

0 15 16 31

Ver= 6

(4bits)

Classe de trafic

(8 bits)

Identificateur de flux

Taille (Payload length) Prochain en-tête

= 0 (Hop by Hop)

Nbr sauts maxi

Adresse source

Adresse destination

Prochain en-tête

T = 43 (Routing)

Longueur

V = Données de l'option Hop-by-hop

Prochain en-tête

T = 6 (TCP)

Longueur

V = Données de l'option Routing

En tête TCP et données applicatives

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.

Message ICMP v6 (protocole n° 58)

0 7 8 15 16 31

Type (8bits) Code (8 bits) Checksum

Options

Format générique d'un message ICMP :

le champ type précise la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne

suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les


Michel MARIE

autres valeurs sont réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés

par le protocole découverte des voisins (Neighbor Discovery) pour la configuration automatique

des équipements,

le champ code précise la cause du message ICMPv6,

le champ checksum permet de vérifier l'intégrité du paquet ICMP.

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é.

Quelques significations (type,code) :

Gestion des erreurs Type Code

1

Destination inaccessible :

0 * aucune route vers la destination

1 * la communication avec la destination est administrativement interdite

2 * hors de portée de l'adresse source

3 * l'adresse est inaccessible

4 * le numéro de port est inaccessible

5 * l’adresse source est filtrée par un firewall

6 * l’adresse destination est rejetée

2 Paquet trop grand 3

Temps dépassé :

0 * limite du nombre de sauts atteinte

1 * temps de réassemblage dépassé

4

Erreur de paramètre :

0 * champ d'en-tête erroné

1 * champ d'en-tête suivant non reconnu

2 * option non reconnue

Information Type Code

128 Demande d'écho

129 Réponse d'écho

Gestion des groupes multicast (RFC 2710)

Type Code 130 Requête d'abonnement

131 Rapport d'abonnement

132 Fin d'abonnement

Découverte de voisins (RFC 2461) Type Code

133 Sollicitation du routeur

134 Annonce du routeur

135 Sollicitation d'un voisin 136 Annonce d'un voisin

137 Redirection

Découverte de voisins inverse (RFC 3122)


Michel MARIE

Type Code 141 Sollicitation

142 Annonce

Gestion de groupes Multicast (RFC 3810)

Type Code

143 Rapport d’abonnement (MLDv2)

Mobilité (RFC 3775) Type Code

144 Découverte d’agent mère (requête)

145 Découverte d’agent mère (réponse) 146 Sollicitation de préfixe mobile

147 Annonce de préfixe mobile

Découverte de voisins sécurisée (RFC 3971)

Type Code

148 Sollicitation de chemin de certification

149 Annonce de chemin de certification

4.1 Configuration automatique d’IPv6

4.1.1 Découverte de ses voisins (Neighbors Discovery Protocol - NDP)

Le protocole de découverte des voisins permet à un équipement de s'intégrer dans l'environnement

local. Il permet de dialoguer avec les équipements connectés au même lien (stations et routeurs).

Il ne s'agit pas pour un équipement de connaître exactement la liste de tous les autres équipements

connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

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é.

Le protocole réalise les différentes fonctions :

Résolution d'adresses : le principe est proche d’ARP, la principale différence vient de l'emploi de

messages standards ICMPv6 à la place de la définition d'un autre protocole de niveau 3, et évite

l’utilisation de la diffusion. Comme pour IPv4, ce protocole construit des tables de mise en

correspondance entre les adresses IPv6 et physiques.

Détection d’adresses IP dupliquées ou DAD (Duplicated Address Detection).

Détection d'inaccessibilité des voisins ou NUD (Neighbor Unreachability Detection) : cette

fonction n'existe pas en IPv4. Elle permet d'effacer des tables de configuration d'un équipement

les voisins devenus inaccessibles. Si un routeur devient inaccessible, la table de routage peut être

modifiée pour prendre en compte une autre route.

Configuration : la configuration automatique des équipements est l'un des attraits principaux

d'IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en œuvre :

o Découverte des routeurs : ce protocole permet aux équipements de déterminer les

routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont assurées par le

protocole ICMP Router Discovery (protocole IDRP "ICMPv4 Discovery Routing

Protocol qui utilise l'adresse Multicast 224.0.0.1).


Michel MARIE

o Découverte des préfixes : l'équipement apprend le (ou les) préfixe(s) du réseau en

fonction des annonces faites par les routeurs. En y ajoutant l'identifiant d'interface de

l'équipement, celui-ci construit son (ou ses) adresse(s) IPv6 (à la condition que le flag A de

l’option préfixe soit positionné). Il n'existe pas d'équivalent pour le protocole IPv4.

Indication de redirection : ce message est utilisé quand un routeur connaît une route meilleure

(en nombre de sauts) pour aller à une destination.

Quelques précisions sur les redirections…

En IPv4 une indication de redirection ne peut servir qu'à corriger l'adresse du routeur utilisé pour

accéder à une machine hors du réseau local. Les machines doivent connaître toutes les adresses

correspondant aux réseaux locaux.

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.

4.1.2 Les messages ICMPv6 de découverte de ses voisins

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

2 pour le dialogue entre un équipement et un routeur,

2 pour le dialogue entre voisins,

et un dernier pour la redirection.

Chacun de ces messages peut contenir des options.


Michel MARIE

a) Message de sollicitation d’un voisin (Type = 135)

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.

Message ICMP v6 « Sollicitation d’un voisin »

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

b) Message d’annonce d’un voisin (Type = 136)

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».

Message ICMP v6 « Annonce d’un voisin »

0 7 8 15 16 31


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

Signification des flags du message ICMP :

R : 0 = équipement ordinaire, 1 = routeur. Utilisé pour signaler qu’un routeur redevient un

équipement ordinaire.

S : mis à 1 pour signaler que le message est une réponse à une sollicitation.

O : mis à 1 pour signaler que cette annonce doit remplacer (effacer) les annonces précédentes

stockées dans le cache des équipements.

c) Message de sollicitation du routeur (Type = 133)

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.

Le champ option contient normalement l'adresse physique de l'équipement.

Message ICMP v6 « Sollicitation du routeur »

0 7 8 15 16 31


Réservé

Options = Adresse physique de l'émetteur


Michel MARIE

d) Message d’annonce du routeur (Type = 134)

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 ».

Message ICMP v6 « Annonce du routeur »

0 7 8 15 16 31


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

Signification des champs du message ICMP :

Nbr Saut max : si non nul, donne la valeur qui pourrait être placée dans le champ nombre de

sauts des paquets émis.

Le flag M (Managed address configuration) : indique qu'une adresse de l'équipement doit être

obtenue avec un protocole de configuration (DHCPv6), configuration avec état.

Le flag O (Other statefull configuration) indique aussi la présence d'un service de configuration

mais pour la récupération d'informations autres que l'adresse.

Le flag H : indique que le routeur peut être utilisé comme «agent mère» ou « Home Agent » pour

un nœud mobile.

Durée de vie du routeur : donne, en secondes, la période pendant laquelle l'équipement

annonçant effectuera les fonctions de routeur par défaut :

o Dmax = 18 h 12 mn, message émis périodiquement donc sans limite théorique,

o une valeur de 0 indique que l'équipement ne remplit pas les fonctions de routeur par

défaut,

o cette durée de vie ne s'applique pas aux options que ce message véhicule.

Durée d'accessibilité : indique la durée en millisecondes pendant laquelle une information

contenue dans le cache de la machine peut être considérée comme valide (correspondance adresse

IPv6 et adresse physique). Au bout de cette période, un message de détection d'inaccessibilité

visant à redécouvrir le nœud voisin est émis pour vérifier la pertinence de l'information.

Temporisation de retransmission : donne en millisecondes la période entre deux émissions non

sollicitées de ce message. Il sert aux autres équipements pour détecter une inaccessibilité du

routeur.

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.


Michel MARIE

Optionnellement, ce message peut véhiculer les informations d’adresse physique de la source, de

préfixe(s) réseau(x) du lien et de MTU(s).

Exemple : L’option « prefix information » Option « Prefix Information »

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

Longueur préfixe : le nombre de bits du préfixe (0 à 128).

Flag L (On-link flag) : positionné à 1 pour indiquer que les adresses associées au préfixe sont sur

le même lien (les hôtes se contactent directement, cas général). Sinon les hôtes envoient d’abord

les paquets au routeur, s’il s’avère que les deux hôtes sont sur le même lien physique, le routeur

enverra alors à l’émetteur un paquet ICMP Redirect.

Flag A (Autonomous address-configuration) : positionné à 1 pour signaler que le préfixe sera

utilisé pour une auto-configuration d’adresse sans état. Autrement, le préfixe reçu par un hôte ne

donnera pas lieu à la construction d’une adresse.

Durée de vie valide : durée de validité en seconde pour les adresses auto-configurées via ce

préfixe. Si ce champ est entièrement à 1, 0xFFFFFFFF la valeur est alors infinie.

Durée de vie préférée : durée de vie préférée en seconde pour les adresses auto-configurées via

ce préfixe. Si ce champ est entièrement à 1, 0xFFFFFFFF la valeur est alors infinie.

e) Message de redirection (Type = 137)

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.

Message ICMP v6 « Redirection »

0 7 8 15 16 31


Réservé

Adresse IPv6 de la cible (nouveau routeur)

Adresse IPv6 de destination

Options : Adresse physique du nouveau routeur, En-tête redirigé

Signification des champs du message ICMP :

Adresse IPv6 cible : adresse IPv6 de l'équipement vers lequel les paquets doivent être redirigés

(nouveau routeur),

Adresse IPv6 destination : adresse IPv6 de l'équipement pour lequel la redirection s'applique

(destinataire final). Si la redirection porte sur un destinataire final se trouvant sur le même lien les

deux adresses précédentes sont identiques.

Options : contiennent l’adresse physique du nouveau routeur et l’en-tête du paquet redirigé.


Michel MARIE

4.2 Configuration automatique

En IPv4 la configuration d’une adresse est « manuelle », soit en définissant statiquement les paramètres

soit en spécifiant l’utilisation d’un serveur DHCPv4 sur le lien.

Avec IPv6, cette configuration est totalement automatisée, apparaît en particulier l'auto-configuration

d'adresses. Celle-ci a pour objectif :

l'acquisition d'une adresse quand une machine est connectée à un réseau pour la première fois,

l'obtention d’une nouvelle adresse suite à la renumérotation des machines du site après un

changement d'opérateur.

Le processus d'auto-configuration d'adresse d'IPv6 comprend la création d'une adresse lien-local, la

vérification de son unicité et la détermination d'adresses unicast globales. IPv6 spécifie deux méthodes d'auto-

configuration pour l'adresse unicast globale :

l'auto-configuration sans état (stateless auto-configuration, RFC 2462), elle est utilisée quand la

gestion administrative (par serveur DHCPv6) des adresses n'est pas nécessaire au sein d'un site,

l'auto-configuration avec état (stateful auto-configuration) ou attribution des adresses par serveur

DHCPv6.

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.

4.2.1 Procédure d’auto-configuration d’adresse

L'algorithme de la procédure d'auto-configuration d'adresse se décompose de la manière suivante :

la première étape consiste à créer l'adresse lien-local à l’aide d’un identifiant EUI-64,

une fois l'unicité de cette adresse vérifiée à l’aide du protocole de détection d’adresse dupliquée, la

machine est en mesure de communiquer avec les autres machines du lien,

ensuite la machine cherche à acquérir un message d'annonce du routeur pour déterminer la

méthode d'obtention de l'adresse unicast globale.

s'il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le message

d'annonce de routeurs, à savoir :

o l'auto-configuration sans état (M=0),

o l'auto-configuration avec état (M=1).

en l'absence de routeur sur le lien, la machine doit essayer d'acquérir l'adresse unicast globale par

la méthode d'auto-configuration avec état (FF02::1:2). Si la tentative échoue, c'est terminé. Les

communications se feront uniquement sur le lien avec l'adresse lien-local. La machine n'a pas une

adresse avec une portée qui l'autorise à communiquer avec des machines autres que celles du lien.

4.2.2 Procédure de détection d’adresse dupliquée (algorithme DAD)

Pour vérifier l'unicité des adresses, les machines doivent exécuter un algorithme de Détection

d'Adresse Dupliquée (DAD). L'algorithme utilise les messages ICMPv6 sollicitation et annonce d'un

voisin.

Pendant cette procédure, l’adresse est "provisoire" et ce jusqu'à la confirmation de son unicité. Elle ne

peut alors recevoir que les messages de sollicitation et d'annonce d'un voisin, les autres messages reçus

sont ignorés.

Cette procédure peut donner lieu à 3 situations :

un message annonce d'un voisin est reçu donc l’adresse provisoire est déjà utilisée comme adresse

valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue,

un message sollicitation d'un voisin est reçu dans le cadre d'une procédure DAD avec la même

adresse provisoire (peu probable mais possible), l'adresse provisoire ne peut être utilisée par

aucune des machines,

aucune réponse n’est reçue après un délai d’une seconde par défaut, l'adresse provisoire est

unique, elle passe de l'état de provisoire à l’état valide et elle est assignée à l'interface.


Michel MARIE

5 Mécanisme de découverte du MTU (Path MTU) Pour des considérations d'efficacité du transport il est généralement préférable que les datagrammes

soient de taille maximale. Cette taille nommée PMTU dépend du chemin suivi par les datagrammes et est

égale à la plus grande taille autorisée par l'ensemble des liens traversés.

La fragmentation n’étant plus autorisée avec IPv6 un mécanisme de découverte préalable du PMTU a

été élaboré.

5.1 Principe du mécanisme de découverte du PMTU

La fragmentation « en cours de route » ne devrait plus exister avec IPv6, le mécanisme utilisé est le

suivant :

initialement, l'équipement émetteur fait l'hypothèse que le PMTU est égal au MTU du lien auquel

il est directement attaché,

si un paquet transmis via le lien précédent excède la MTU d’un lien intermédiaire :

o le routeur associé au lien détruit le paquet et retourne un message d'erreur ICMPv6 de

type 2 (paquet trop grand) en y indiquant le MTU accepté

o l'équipement émetteur réduit le PMTU supposé pour ce chemin et émet à nouveau le

paquet origine.

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.

6 Les mécanismes de transition Le déploiement d'IPv6 se fait lentement, tout en continuant à utiliser IPv4. En particulier, de

nombreux routeurs ne supportent pas encore IPv6. Pour pouvoir connecter deux machines supportant

IPv6, mais reliées par une infrastructure réseau ne supportant que l'IPv4, il est nécessaire d'établir des

« tunnels ».

Il s'agit de mettre les paquets IPv6 dans des paquets IPv4, pour qu'ils puissent traverser le réseau

IPv4. Une fois arrivé au bout du tunnel, les paquets sont « désencapsulés ».

6.1 Protocole 6to4

Toute machine disposant d'une adresse IPv4 globale (publique) peut utiliser le 6to4. C'est une

sorte de tunnel IPv6 au sein de l’IPv4 applicable entre routeurs qui disposent d'une adresse IPv4 globale.

Cela permet d'accéder à l'Internet IPv6 au travers d’une connexion Internet IPv4 usuelle, telle que fournie

par un FAI.

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.


Michel MARIE

Réseau Public IPv480.10.0.0/24

Routeur 6to4double pile

Réseau Privé IPv6MTU <=1480

Réseau Privé IPv6MTU<=1480

Routeur 6to4double pile

2002:500A:0001::/48 2002:500A:0002::/48

.1 .2

IPv6 dans tunnel IPv4

Format des adresses 6to4 :

2002 @IPV4 SID Interface ID

16 bits 16 bits32 bits 64 bits

Adresse 6to4

Exemple 1 :

L’adresse IPv4 192.0.2.33 d’un routeur 6to4 sera transformée pour donner l’adresse IPv6 6to4

2002:C000:0221::/48

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).

6.2 Relais 6to4

Pour que les utilisateurs d'adresses IPv6 6to4 puissent communiquer avec des hôtes accessibles

au travers de l’Internet IPv6 (adresses globales), des relais entre le monde 6to4 et l'Internet-IPv6 ont

été mis en place sur Internet car un site utilisant 6to4 n’est pas connecté à l’Internet v6, ce sont les

relais 6to4.

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.

Routeur 6to4

Réseau Privé IPv6Réseau Public IPv4 Réseau Privé IPv6

Routeur 6to4

2002:500A:0001::/482001:DDEE:0002::/4880.10.0.1

192.88.99.1

Relai 6to4

Réseau Public IPv6

Serveur IPv6

Relai 6to4Relai 6to4


Michel MARIE

Comme il n'est pas possible de choisir le relais, que leur qualité varie fortement, que la probabilité de

routage asymétrique est élevée, tous ces critères rendent la communication passant par 6to4 très

imprévisible et en pratique peu fiable.

En mai 2015, par la publication du RFC 7526, l'IETF prône l'abandon de cette technique remplacée par

la technique 6rd.

6.3 Protocole 6rd (IPv6 Rapid Deployment)

Ce protocole a été tout d’abord déployé par l’opérateur Free avant de devenir un standard (RFC

5969). Il est principalement destiné aux opérateurs pour offrir une connectivité IPv6 lorsque leur

infrastructure repose sur IPv4.

Il reprend le principe des tunnels automatiques 6to4, mais a été modifié pour éviter les défauts

de performances et de fiabilité observés avec 6to4, mais en contrepartie il se restreint à un usage

interne et local à l’opérateur. 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. L'opérateur doit donc installer ses

propres relais pour offrir la connectivité avec l'Internet v6. Dans la terminologie 6rd on distingue les

éléments suivants :

Le routeur double pile permettant la connectivité du réseau privé IPv6 à l’Internet IPv6 au

travers d’une infrastructure IPv4, routeur 6rd CE pour « Customer Edge ».

Le routeur double pile de bordure qui assure la fonction de relai pour la connexion à l’Internet

IPv6, routeur 6rd BR pour « Border Relay ».

Le préfixe IPv6 propre à l’opérateur utilisé pour identifier les tunnels 6rd, notés pref6rd.

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.

Réseau Privé IPv6

R1

IPv4

Internet IPv6Poste IPv6

Réseau Privé IPv6

R2

Poste IPv6 Internet IPv4

6rd CE

6rd CE

6rd BR

Routeur IPv4

Infrastructure IPv4

Opérateur

Tun

ne

l 6rd

Construction de l’adresse IPv6 6rd

6rd prefix @IPV4 ->BRsuffix SID Interface ID

n1 bits n3 bitsn2 bits 64 bits

Adresse 6rd

Le préfixe est pris dans le plan d’adressage global de l’opérateur.

Du coté infrastructure IPv4 opérateur, les routeurs 6rd CE et 6rd BR ont des adresses IPv4 qui

peuvent être publiques mais ce n’est pas obligatoire. Ces adresses sont agrégées dans un même

réseau dont le suffixe servira à identifier chaque routeur BR ou CE.

Les bits restants pour le « subnet ID » (64-n1-n2) permettent de segmenter les réseaux privés

IPv6.


Michel MARIE

Exemple :

Soit un opérateur de préfixe global 2001:0::/32 et dont les adresses IPv4 des routeur 6rd BR et CE

s’agrègent sur le préfixe réseau IPv4 192.0.0.0/8.

La taille du SID sera de 64-32-24 = 8 bits pour la segmentation des réseaux privés des clients

de cet opérateur.

Si le client est connecté au réseau IPv4 opérateur via un routeur 6rd CE d’adresse IPv4 =

192.1.2.128, le préfixe 6rd pour ce réseau 6rd CE sera 2001:0:0102:8000::/56

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.

Transfert d’un site vers l'Internet IPv6 :

Le poste situé dans le réseau R1 envoie un paquet IPv6 à destination d’un nœud de l’Internet IPv6. Le

paquet IPv6 arrive en mode natif au 6rd CE de la source. L'adresse de destination IPv6 ne correspond

pas à un préfixe IPv6 du domaine 6rd, le paquet IPv6 est alors transmis à un routeur de bordure 6rd

BR après être encapsulé dans IPv4 comme précédemment.

6.4 Traduction NAT64 – DNS64

La traduction NAT64 – DNS64 a pour objectif de faire communiquer des postes exclusivement

IPv6 avec des postes exclusivement IPv4. NAT64 et DNS64 constituent ensemble une technique de

traduction de niveau réseau. Le fonctionnement du NAT64 fonctionne sans état ou avec état en

fonction du mode de traduction de l'adresse source et de l'adresse de destination du paquet reçu par le

traducteur.

La NAT64 sans état correspond à une translation one-to-one, la correspondance d’adresse IPv6

vers IPv4 et inversement est unique. Ce mode nécessite une configuration des correspondances

soit « manuelle » soit par l’intermédiaire d’un DHCPv6 configuré pour distribuer des adresses

IPv6 embarquant des adresses IPv4.

La NAT64 avec état partage une adresse IPv4 entre plusieurs adresses IPv6. Comme pour la

NAT44 c’est le numéro de port qui permettra d’assurer le multiplexage/démultiplexage des

flux.

Principe de NAT64 avec état

RouteurNAT64 statefull

@source

@dest

Postev6 Postev4

Postev6

Prefix64:Postev4

@source

@dest

Routeurv4

Postev4

Prefix64 RouteurV4Adresse « IPv4 converted »

=> => =>=>

Et le DNS64 dans tout cela ??

Le DNS64 a un rôle d’intermédiaire entre les postes IPv6 et le serveur DNS utilisé par le réseau afin

de constituer l’adresse de destination IPv6 à partir du prefix64 et de la résolution A du nœud

destination.


Michel MARIE

Pour résoudre les noms d’hôte des postes adressés, les postes IPv6 s’adressent au DNS64 qui lui-

même transmettra la requête au serveur DNS :

d’abord du type AAAA, si la résolution retourne une IPv6 celle-ci est retournée au client IPv6

qui peut l’adresser directement,

par contre si la résolution AAAA échoue, elle est renouvelée de type A, l’adresse IPv4

obtenue et retournée au serveur DNS64 sera transformée en IPv6 à l’aide du préfixe configuré

sur le routeur NAT64. Le poste IPv4 peut alors être adressé après translation NAT64.

L’exemple ci-après illustre ce principe.

Postev6 = 2001:DB8::1 Postev4.fr = 80.80.80.1

DNS64

Prefix64 = 2A01::/96DNSv4v6 Routeur

NAT64

DNS requête AAAA

Postev4.fr DNS requête AAAA

Postev4.fr

DNS réponse

(vide)

DNS réponse

80.80.80.1

DNS requête A

Postev4.fr

DNS réponse AAAA

2A01::80.80.80.1

TCP/IPv6

@Source = [2001:DB8::1]:1024

@Destination = [2A01::80.80.80.1]:80

66.66.66.1Prefix64 = 2A01::/96

TCP/IPv4

@Source = 66.66.66.1:1024

@Destination = 80.80.80.1:80

6.5 Protocole ISATAP

Le protocole ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) a été défini pour

fournir une connectivité IPv6 à des équipements terminaux IPv6 isolés dans un réseau IPv4. Il permet

à ces équipements de communiquer avec un réseau IPv6 distant via une passerelle supportant IPv6. Il

est réservé à une utilisation locale (réseau privé) alors que 6to4 est utilisé sur les réseaux publics.

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

Adresse IPv6 ISATAP

Préfixe IPv6 Standard

16 bits 32 bits

0000 5EFE @ IPv4


Michel MARIE

Routeur ISATAPPréfixe 2001:DB8:1234:1::/64

Réseau Privé IPv4 Réseau Public IPv6

Tunnel ISATAP

192.168.1.1

2001:DB8:1234:1:0:5EFE:C0A8:0101

192.168.1.0/24 .254

Serveur DNSISATAP = 192.168.1.254

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).


Michel MARIE

6.6 Protocole TEREDO

Le protocole Teredo, (Tunneling IPv6 over UDP through NAT) décrit par la RFC 4380, définit

une méthode permettant d'accéder à l'Internet IPv6 derrière un équipement réalisant du NAT. Il fait

partie des mécanismes de transition d'IPv4 vers IPv6 et consiste à encapsuler les paquets IPv6 dans

des datagrammes UDP sur IPv4 entre le client et le relais Teredo, avec l'aide d'un serveur Teredo.

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.

Schéma de l’architecture Teredo :

Routeur NAT

Réseau Privé IPv4Réseau Public IPv4

teredo.remlab.net

Relai Teredo

Réseau Public IPv6

Serveur TeredoClient Teredo

teredo.ipv6.microsoft.com

ServeurIPv6

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.

Construction de l’adresse IPv6 Teredo

32 bits 32 bits

Adresse IPv6 TEREDO

16 bits 32 bits

@ IPv4 Serveur Teredo Flags @ IPv4 Publique NATPort UDP

16 bits

Préfixe IPv6 Teredo = 2001::/32

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é,


Michel MARIE

o U = 0 (Universal/local),

o G = 0 (individual/Group),

o A = 12 bits générés aléatoirement par le client Teredo.

Le champ “Port UDP”, qui correspond au port UDP utilisé par le client pour encapsuler les

paquets IPv6 sur le réseau IPv4 public représenté en complément à 1.

Le champ “Adresse IPv4 Publique NAT”, qui correspond à l’adresse publique IPv4 utilisée pour

la NAT représentée en complément à 1.

Principe :

Routeur NAT

Réseau Privé IPv4Réseau Public IPv4

Relai Teredo

Réseau Public IPv6

Serveur Teredo

Client Teredo

Hôte IPv6

public

1

2

3

4

5

6

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.

7 Les commandes de configuration et de contrôle

7.1 Sur un switch Cisco

Activation de la pile IPv6, commandes sdm « Switch Database Managment » sdm prefer dual-ipv4-and-ipv6 default ipv6 unicast-routing show sdm prefer


Michel MARIE

7.2 Sur un routeur Cisco

Activation de la pile et du routage IPv6, ces commandes doivent-être réalisées dans cet ordre : ipv6 unicast-routing ip cef ipv6 cef

7.3 Sous Windows

Toutes les commandes ici présentées ont été testées avec Windows 7 Professionnel. Je n’assure pas

la compatibilité parfaite avec les autres OS Microsoft…

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>?

Les commandes suivantes sont disponibles : Commandes héritées du contexte netsh : .. - Monte d'un niveau de contexte. abort - Rejette les changements effectués en mode déconnecté. add - Ajoute une entrée de configuration à une liste d'entrées. advfirewall - Modifications pour le contexte `netsh advfirewall'. alias - Ajoute un alias. branchcache - Modifications pour le contexte `netsh branchcache'. bridge - Modifications pour le contexte `netsh bridge'. bye - Quitte le programme. commit - Valide les changements effectués en mode déconnecté. delete - Supprime une entrée de configuration d'une liste d'entrées. dhcpclient - Modifications pour le contexte `netsh dhcpclient'. dnsclient - Modifications pour le contexte `netsh dnsclient'. exit - Quitte le programme. firewall - Modifications pour le contexte `netsh firewall'. http - Modifications pour le contexte `netsh http'. interface - Modifications pour le contexte `netsh interface'. ipsec - Modifications pour le contexte `netsh ipsec'. lan - Modifications pour le contexte `netsh lan'. mbn - Modifications pour le contexte `netsh mbn'. namespace - Modifications pour le contexte `netsh namespace'. nap - Modifications pour le contexte `netsh nap'. netio - Modifications pour le contexte `netsh netio'. offline - Définit le mode courant comme non connecté. online - Définit le mode courant comme connecté. p2p - Modifications pour le contexte `netsh p2p'. popd - Retire un contexte de la pile. pushd - Émet le contexte actuel sur la pile. quit - Quitte le programme. ras - Modifications pour le contexte `netsh ras'. rpc - Modifications pour le contexte `netsh rpc'. set - Met à jour les paramètres de configuration. show - Affiche les informations. trace - Modifications pour le contexte `netsh trace'. unalias - Supprime un alias. wcn - Modifications pour le contexte `netsh wcn'. wfp - Modifications pour le contexte `netsh wfp'. winhttp - Modifications pour le contexte `netsh winhttp'. winsock - Modifications pour le contexte `netsh winsock'. wlan - Modifications pour le contexte `netsh wlan'. Commandes dans ce contexte : 6to4 - Modifications pour le contexte `netsh interface 6to4'. httpstunnel - Modifications pour le contexte `netsh interface httpstunnel'. ipv4 - Modifications pour le contexte `netsh interface ipv4'. ipv6 - Modifications pour le contexte `netsh interface ipv6'. isatap - Modifications pour le contexte `netsh interface isatap'. portproxy - Modifications pour le contexte `netsh interface portproxy'. set - Définit les informations de configuration.


Michel MARIE

show - Affiche les informations. tcp - Modifications pour le contexte `netsh interface tcp'. teredo - Modifications pour le contexte `netsh interface teredo'.

7.3.1 Commande d’affichage des adresses IPv6 de la machine.

netsh interface ipv6 show add

Interface 14 : Teredo Tunneling Pseudo-Interface Addr Type État DAD Vie valide Pers. Fav. Adresse --------- ----------- ---------- ---------- ------------------------ Public Préféré infinite infinite 2001:0:5ef5:79fb:1c30:5d3:b10b:7ffd Autre Préféré infinite infinite fe80::1c30:5d3:b10b:7ffd%14 Interface 10 : Connexion réseau sans fil Addr Type État DAD Vie valide Pers. Fav. Adresse --------- ----------- ---------- ---------- ------------------------ Autre Préféré infinite infinite fe80::1cea:5184:1eb2:df99%10 Interface 1 : Loopback Pseudo-Interface 1 Addr Type État DAD Vie valide Pers. Fav. Adresse --------- ----------- ---------- ---------- ------------------------ Autre Préféré infinite infinite ::1

On remarquera :

l’adresse de Loopback ::1,

l’adresse de type « Unicast Lien Local » de l’interface sans fil, avec un identificateur d’interface

choisi aléatoirement, ce qui est la configuration par défaut sous Windows 7, (l’adresse mac de la

carte est 0025:0046:7BB9)


Suffixe DNS propre à la connexion. . . :

Description. . . . . . . . . . . . . . : Carte réseau Broadcom 802.11n


l’adresse de l’interface Tunnel Teredo, interface installée sur les machines Microsoft pour réaliser

(temporairement) le tunnelage 6to4 pour les paquets IPv6 destinés à sortir sur le réseau public via

une NAT IPv4, en attendant que tous les routeurs soient compatibles 6to4. Dans la plage

« Unicast Global » la plage 2001::/32 est réservée pour les interfaces Teredo

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.

>netsh interface ipv6 set global randomizeidentifiers=disabled Ok. >netsh interface ipv6 show add Interface 10 : Connexion réseau sans fil Addr Type État DAD Vie valide Pers. Fav. Adresse --------- ----------- ---------- ---------- ------------------------ Autre Préféré infinite infinite fe80::225:ff:fe46:7bb9%10

On obtient bien cette fois ci l’adresse obtenue selon le mode de calcul présenté au paragraphe

« Identifiant d’interface ».


Michel MARIE

7.3.2 Autoconfiguration d’adresse, rôle du routeur

Schéma logique du réseau :

WWW

routeur2801

IPv4

172.19.32.0/24

IPv6

FD00:0:1:11:/64FD00:0:1:11:172:19:32:254

172.19.32.254

Serveur DHCPv4172.19.32.2

Serveur DHCPv6 et DNSv4-6172.19.32.2

FD00:0:1:11:172:19:32:2

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

Configuration de l’interface IPv6 du serveur DHCPv6 et DNS

Réinitialisation du poste client d’adresse physique 0025:0046:7BB9

>ipconfig /release6 >ipconfig /renew6


Michel MARIE

Les trames capturées :

ICMPv6 : Sollicitation du routeur Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)

Ethernet II, Src: Apple_46:7b:b9 (00:25:00:46:7b:b9), Dst: IPv6mcast_00:00:00:02 (33:33:00:00:00:02)

Internet Protocol Version 6, Src: fe80::225:ff:fe46:7bb9 (fe80::225:ff:fe46:7bb9), Dst: ff02::2 (ff02::2)

Internet Control Message Protocol v6

Type: Router Solicitation (133)

Code: 0

Checksum: 0x82e5 [correct]

Reserved: 00000000

ICMPv6 Option (Source link-layer address : 00:25:00:46:7b:b9)

Type: Source link-layer address (1)

Length: 1 (8 bytes)

Link-layer address: Apple_46:7b:b9 (00:25:00:46:7b:b9)

ICMPv6 : Annonce du routeur

Frame 2: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)

Ethernet II, Src: Cisco_8e:b4:15 (00:1a:6c:8e:b4:15), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01)

Internet Protocol Version 6, Src: fe80::21a:6cff:fe8e:b415 (fe80::21a:6cff:fe8e:b415), Dst: ff02::1

(ff02::1)


Type: Router Advertisement (134)

Code: 0

Checksum: 0x89a6 [correct]

Cur hop limit: 64

Flags: 0x00

0... .... = Managed address configuration: Not set

.0.. .... = Other configuration: Not set

..0. .... = Home Agent: Not set

...0 0... = Prf (Default Router Preference): Medium (0)

.... .0.. = Proxy: Not set

.... ..0. = Reserved: 0

Router lifetime (s): 1800

Reachable time (ms): 0

Retrans timer (ms): 0

ICMPv6 Option (Source link-layer address : 00:1a:6c:8e:b4:15)


Length: 1 (8 bytes)

Link-layer address: Cisco_8e:b4:15 (00:1a:6c:8e:b4:15)

ICMPv6 Option (MTU : 1500)

Type: MTU (5)

Length: 1 (8 bytes)

Reserved

MTU: 1500

ICMPv6 Option (Prefix information : fd00:0:1:11::/64)

Type: Prefix information (3)

Length: 4 (32 bytes)

Prefix Length: 64

Flag: 0xc0

1... .... = On-link flag(L): Set

.0.. .... = Autonomous address-configuration flag(A): Not Set

..00 0000 = Reserved: 0

Valid Lifetime: 36000

Preferred Lifetime: 35000

Reserved

Prefix: fd00:0:1:11:: (fd00:0:1:11::)

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

Tous les routeurs

du lien

ien

Tous les nœuds du

lien

ien


Michel MARIE

Affichage de la configuration IPv6 de l’interface du routeur

>sh ipv6 interface fastEthernet 0/1.3

FastEthernet0/1.3 is up, line protocol is up

IPv6 is enabled, link-local address is FE80::21A:6CFF:FE8E:B415

No Virtual link-local address(es):

Description: **** Sortie Vlan11 ****

Global unicast address(es):

FD00:0:1:11:172:19:32:254, subnet is FD00:0:1:11::/64

Joined group address(es):

FF02::1

FF02::2

FF02::1:FF32:254

FF02::1:FF8E:B415

MTU is 1500 bytes

ICMP error messages limited to one every 100 milliseconds

ICMP redirects are enabled

ICMP unreachables are sent

Output features: QoS classify QoS actions

ND DAD is enabled, number of DAD attempts: 1

ND reachable time is 30000 milliseconds (using 44188)

ND advertised reachable time is 0 (unspecified)

ND advertised retransmit interval is 0 (unspecified)

ND router advertisements are sent every 200 seconds

ND router advertisements live for 1800 seconds

ND advertised default router preference is Medium

Hosts use DHCP to obtain routable addresses.

Réinitialisation du poste client d’adresse physique 0025 :0046 :7BB9

>ipconfig /release6 >ipconfig /renew6

Les trames capturées :

ICMPv6 : sollicitation du routeur



Internet Protocol Version 6, Src: fe80::225:ff:fe46:7bb9 (fe80::225:ff:fe46:7bb9), Dst: ff02::2 (ff02::2)


Type: Router Solicitation (133)

Code: 0

Checksum: 0x82e5 [correct]

Reserved: 00000000



Length: 1 (8 bytes)


ICMPv6 : annonce du routeur


Ethernet II, Src: Cisco_8e:b4:15 (00:1a:6c:8e:b4:15), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01)

Internet Protocol Version 6, Src: fe80::21a:6cff:fe8e:b415 (fe80::21a:6cff:fe8e:b415), Dst: ff02::1

(ff02::1)


Type: Router Advertisement (134)

Code: 0

Checksum: 0x902d [correct]

Cur hop limit: 64

Flags: 0x80

1... .... = Managed address configuration: Set

.0.. .... = Other configuration: Not set

Adresse de sollicitation de lien de l’adresse unique locale

Adresse de sollicitation de lien de l’adresse lien local


Michel MARIE

..0. .... = Home Agent: Not set

...0 0... = Prf (Default Router Preference): Medium (0)

.... .0.. = Proxy: Not set

.... ..0. = Reserved: 0

Router lifetime (s): 1800

Reachable time (ms): 0

Retrans timer (ms): 0

ICMPv6 Option (Source link-layer address : 00:1a:6c:8e:b4:15)


Length: 1 (8 bytes)


ICMPv6 Option (MTU : 1500)

Type: MTU (5)

Length: 1 (8 bytes)

Reserved

MTU: 1500

DHCPv6 : requête DHCP



Internet Protocol Version 6, Src: fe80::225:ff:fe46:7bb9 (fe80::225:ff:fe46:7bb9), Dst: ff02::1:2

(ff02::1:2)

User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: dhcpv6-server (547)

Source port: dhcpv6-client (546)

Destination port: dhcpv6-server (547)

Length: 148

Checksum: 0xd90e [validation disabled]

[Good Checksum: False]

[Bad Checksum: False]

DHCPv6

Message type: Request (3)

Transaction ID: 0xa4e6bf

Elapsed time

Option: Elapsed time (8)

Length: 2

Value: 0000

elapsed-time: 0 ms

Client Identifier: 00010001137c311c00254baea3d2

Option: Client Identifier (1)

Length: 14

Value: 00010001137c311c00254baea3d2

DUID type: link-layer address plus time (1)

Hardware type: Ethernet (1)

Time: May 11, 2010 17:15:40 Paris, Madrid (heure d’été)

Link-layer address: 00:25:4b:ae:a3:d2

DHCPv6 : réponse DHCP


Ethernet II, Src: Dell_d6:45:d6 (00:1c:23:d6:45:d6), Dst: Apple_46:7b:b9 (00:25:00:46:7b:b9)

Internet Protocol Version 6, Src: fd00:0:1:11:172:19:32:2 (fd00:0:1:11:172:19:32:2), Dst:

fe80::225:ff:fe46:7bb9

User Datagram Protocol, Src Port: dhcpv6-server (547), Dst Port: dhcpv6-client (546)

Source port: dhcpv6-server (547)

Destination port: dhcpv6-client (546)

Length: 92

Checksum: 0x5b5f [validation disabled]

[Good Checksum: False]

[Bad Checksum: False]

DHCPv6

Message type: Reply (7)

Transaction ID: 0xa4e6bf

Server Identifier: 000100004e030878001c23d645d6

Option: Server Identifier (2)

Length: 14

Value: 000100004e030878001c23d645d6


Hardware type: NET/ROM pseudo (0)

Time: Not representable

Link-layer address: 001c23d645d6

Client Identifier: 00010001137c311c00254baea3d2

Option: Client Identifier (1)

Length: 14

Value: 00010001137c311c00254baea3d2


Hardware type: Ethernet (1)

Time: May 11, 2010 17:15:40 Paris, Madrid (heure d’été)

Link-layer address: 00:25:4b:ae:a3:d2

Identity Association for Non-temporary Address

Option: Identity Association for Non-temporary Address (3)

Tous les agents

DHCP du lien

ien


Michel MARIE

Length: 40

Value: 0d002500000546000008700000050018fd00000000010011...

IAID: 0d002500

T1: 345600

T2: 552960

IA Address: fd00:0:1:11:a017:f519:936c:d5f1

Option: IA Address (5)

Length: 24

Value: fd00000000010011a017f519936cd5f1000a8c00000fd200

IPv6 address: fd00:0:1:11:a017:f519:936c:d5f1

Preferred lifetime: 691200

Valid lifetime: 1036800


Suffixe DNS propre à la connexion. . . : ramses.ii

Description. . . . . . . . . . . . . . : Carte réseau Broadcom 802.11n


DHCP activé. . . . . . . . . . . . . . : Oui

Configuration automatique activée. . . : Oui

Adresse IPv6. . . . . . . . . . . . . .: fd00:0:1:11:a017:f519:936c:d5f1


Michel MARIE

7.3.3 Commande d’affichage routes IPv6 de la machine.

>netsh interface ipv6 show route

Publier Type Mét Préfixe Idx Nom passerelle/interface

------- -------- --- ------------------------ --- ------------------------

Non Manuel 256 ::/0 12 fe80::160c:76ff:fe6d:bf09

Non Manuel 256 ::1/128 1 Loopback Pseudo-Interface1

Non Manuel 8 2001::/32 29 Teredo Tunneling Pseudo-Interface

Non Manuel 8 2a01:e34:ef48:20::/64 12 Connexion réseau sans fil

Non Manuel 256 2a01:e34:ef48:20:8cca:6c91:5828:c49d/128 12 Connexion réseau sans fil

Non Manuel 256 2a01:e34:ef48:20:ad93:ef4b:7794:727a/128 12 Connexion réseau sans fil

Non Manuel 256 fe80::/64 12 Connexion réseau sans fil

Non Manuel 256 fe80::/64 29 Teredo Tunneling Pseudo-Interface

Non Manuel 256 fe80::101d:2777:b10b:7ffd/128 29 Teredo Tunneling Pseudo-Interface

Non Manuel 256 ff00::/8 12 Connexion réseau sans fil

…

7.3.4 Commande d’affichage des voisins IPv6 de la machine.

Capture de trames de solicitation et d’avertissement d’un voisin


Ethernet II, Src: Apple_46:7b:b9 (00:25:00:46:7b:b9), Dst: IPv6mcast_ff:8e:b4:15 (33:33:ff:8e:b4:15)

Internet Protocol Version 6, Src: fe80::225:ff:fe46:7bb9 (fe80::225:ff:fe46:7bb9), Dst: ff02::1:ff8e:b415

(ff02::1:ff8e:b415)


Type: Neighbor Solicitation (135)

Code: 0

Checksum: 0xacf2 [correct]

Reserved: 00000000

Target Address: fe80::21a:6cff:fe8e:b415 (fe80::21a:6cff:fe8e:b415)



Length: 1 (8 bytes)



Ethernet II, Src: Cisco_8e:b4:15 (00:1a:6c:8e:b4:15), Dst: Apple_46:7b:b9 (00:25:00:46:7b:b9)

Internet Protocol Version 6, Src: fe80::21a:6cff:fe8e:b415 (fe80::21a:6cff:fe8e:b415), Dst:


Type: Neighbor Advertisement (136)

Code: 0

Checksum: 0xb8c1 [correct]

Flags: 0xe0000000

1... .... .... .... .... .... .... .... = Router: Set

.1.. .... .... .... .... .... .... .... = Solicited: Set

..1. .... .... .... .... .... .... .... = Override: Set

...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0

Target Address: fe80::21a:6cff:fe8e:b415 (fe80::21a:6cff:fe8e:b415)

ICMPv6 Option (Target link-layer address : 00:1a:6c:8e:b4:15)

Type: Target link-layer address (2)

Length: 1 (8 bytes)


>netsh interface ipv6 show neighbors

Interface 10 : Connexion réseau sans fil

Adresse Internet Adresse physique Type

-------------------------------------------- ----------------- -----------

fd00:0:1:11:172:19:32:2 00-1c-23-d6-45-d6 Caduque

fd00:0:1:11:172:19:32:254 00-1a-6c-8e-b4-15 Caduque (Routeur)

7.4 Sous Linux

Toutes les commandes ici présentées ont été testées avec Linux Ubuntu 10.0. Je n’assure pas la

compatibilité parfaite avec les autres distributions du pingouin…


Michel MARIE

Visualiser la configuration d’une interface :

>ifconfig nomInterface

Désactiver, activer une interface (par exemple pour une réinitialisation DHCP) :

>sudo ifconfig nomInterface down

>sudo ifconfig nomInterface up

Visualiser les routes :

>netstat –nr

Visualiser les voisins IPv6 :

>ip -6 neigh show

7.5 Chez Apple

Visualiser la configuration d’une interface :

>ifconfig nomInterface

Désactiver, activer une interface (par exemple pour une réinitialisation DHCP) :

>sudo ifconfig nomInterface down

>sudo ifconfig nomInterface up

Visualiser les routes :

>netstat –nr

Les commandes spécifiques à IPv6 (commande UNIX apropos) :

>apropos ipv6

icmp6(4) - Internet Control Message Protocol for IPv6 ip6(4) - Internet Protocol version 6 (IPv6) network layer ndp(8) - control/diagnose IPv6 neighbor discovery protocol tcllib_ip(n) - IPv4 and IPv6 address manipulation traceroute6(8) - print the route IPv6 packets will take to a network node

Exemple, protocole ND, toutes les entrées :

>ndp -an

Neighbor Linklayer Address Netif Expire St Flgs Prbs 2a01:e34:ef48:20:225:ff:fe46:7bb9 0:25:0:46:7b:b9 en1 permanent R 2a01:e34:ef48:20:28e3:2fa5:75c3:fd4a 0:25:0:46:7b:b9 en1 permanent R fe80::1%lo0 (incomplete) lo0 permanent R fe80::225:ff:fe46:7bb9%en1 0:25:0:46:7b:b9 en1 permanent R fe80::160c:76ff:fe6d:bf09%en1 14:c:76:6d:bf:9 en1 35s R R fe80::bac7:5dff:fec7:4558%en1 b8:c7:5d:c7:45:58 en1 23h49m58s S

L'adressage IPV6 - Michel MARIEsitemm.michel-marie.net/network/Docs/CoursIPv6.pdf · adressage ipv6...

Documents

Transcript of L'adressage IPV6 - Michel MARIEsitemm.michel-marie.net/network/Docs/CoursIPv6.pdf · adressage ipv6...