MOOC:Resume Act31 - Revision history

Jlandru at 12:11, 10 March 2017

2017-03-10T12:11:26Z

Jlandru at 12:09, 10 March 2017

2017-03-10T12:09:57Z

Jlandru at 11:59, 10 March 2017

2017-03-10T11:59:54Z

Jlandru at 11:54, 10 March 2017

2017-03-10T11:54:15Z

Jlandru: /* Fonctionnement de la détection d'adresse dupliquée */

2017-03-10T11:49:58Z

‎Fonctionnement de la détection d'adresse dupliquée

Jlandru: /* Fonctionnement de la détection d'adresse dupliquée */

2017-03-10T11:49:25Z

‎Fonctionnement de la détection d'adresse dupliquée

Jlandru: /* Fonctionnement de la résolution d'adresse IP */

2017-03-10T11:42:44Z

‎Fonctionnement de la résolution d'adresse IP

Jlandru: /* Fonctionnement de la détection d'adresse dupliquée */

2017-03-10T09:38:22Z

‎Fonctionnement de la détection d'adresse dupliquée

Jlandru: /* Fonctionnement de la résolution d'adresse IP */

2017-03-10T09:34:41Z

‎Fonctionnement de la résolution d'adresse IP

Jlandru: /* Rapport d'erreur */

2017-03-10T09:28:20Z

‎Rapport d'erreur

@@ Line 4: / Line 4: @@
 -->
 __NOTOC__
 = Activité 31 : Contrôler le fonctionnement du réseau par ICMPv6  =
 ==Introduction==
 Le bon fonctionnement de la couche réseau est supervisé par le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443].  Tout comme ICMP pour IPv4, ICMPv6 s'appuie sur IPv6 pour réaliser ses fonctions. La famille des protocoles ICMP donne les informations sur l'état de marche du réseau. Elle rapporte également les erreurs quand un paquet ne peut être traité correctement. On distingue 3 fonctions propres à ICMP :
 * le signalement d'erreur en cours d'acheminement d'un paquet,
@@ Line 20: / Line 18: @@
 == Format général d'un message ICMPv6 ==
 Les messages ICMPv6 sont encapsulés directement dans un paquet IPv6. Le protocole se voit attribuer le numéro 58 pour être représenté dans l'en-tête IPv6 comme prochain en-tête (champ ''Next Header''). Le format général des messages ICMPv6 est donné par la figure 1. L'en-tête des messages ICMPv6 comporte 3 champs :
 # Le champ <tt>Type</tt> : il indique la nature du message ICMPv6 et, donc, le format spécifique du message. Les messages ICMPv6 forment 2 groupes : un groupe pour les messages d'informations et un autre pour les messages d'erreurs. Les groupes sont identifiés par le bit de poids fort de ce champ. Les messages d'erreurs ont ce bit à zéro et, donc, le champ <tt>Type</tt> prendra, pour ces messages, une valeur comprise entre 0 et 127. Les messages d'informations sont identifiés par un champ <tt>Type</tt> dont la valeur est comprise entre 128 et 255.
@@ Line 143: / Line 140: @@
 == Rapport d'erreur ==
 ICMPv6 permet de signaler à l'émetteur d'un paquet, un problème dans son acheminement ou dans sa réception, par des messages de rapport d'erreur. Lorsqu'une machine émet un paquet, si une erreur est détectée par le destinataire ou par tout routeur intermédiaire le long du chemin vers le destinataire alors l'élément qui détecte l'erreur renvoie à l'émetteur un rapport sous la forme d'un message ICMPv6. Le type du message et son code définissent précisément l'erreur détectée. L'extrait, jusqu'à concurence de 1280  octet du paquet en défaut, est incluse pour permettre l'analyse de l'erreur.
 L'exemple ci dessous illustre un message ICMP ''Paquet trop grand'', généré par un routeur intermédiaire dès qu'un datagramme ne peut être retransmis en raison de la limitation de la MTU sur son interface de sortie.
@@ Line 158: / Line 154: @@
 == Découverte des voisins ==
 La découverte des voisins ou NDP (''Neighbor Discovery Protocol'') est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6.
 NDP vise à gérer les interactions entre un noeud et ses voisins. Les voisins sont les noeuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un noeud est capable de dialoguer avec les équipements connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un noeud, de connaître exactement la liste de tous les autres noeuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

@@ Line 141: / Line 141: @@
 :  <font color="blue">''2021''</font>
 <center>'''Trace 2 : Message ICMPv6 Réponse d'écho.'''</center>
 == Rapport d'erreur ==
@@ Line 199: / Line 200: @@
 Tableau 3 : Messages ICMPv6 pour les interactions entre voisins
 </center>
 === Format des messages mis en oeuvre ===
 Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.<br>
@@ Line 204: / Line 206: @@
 ==== <div id="NS">Message Sollicitation d'un voisin</div> ====
 Le message de la figure 8 sert à demander des informations d'un noeud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.
@@ Line 215: / Line 216: @@
 ==== <div id="NA">Message Annonce d'un voisin</div> ====
 Le message de la figure 9 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. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.
@@ Line 229: / Line 229: @@
 === Fonctionnement de la résolution d'adresse IP ===
 La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction que ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 10 dans lequel les 2 noeuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.
@@ Line 353: / Line 352: @@
 A noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.
 == Conclusion ==
 Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.<br>
 A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non-livraison d'un paquet, les informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la communication si besoin est.
@@ Line 365: / Line 362: @@
 == Pour aller plus loin==
 RFC et leur analyse par S. Bortzmeyer :
 * RFC 1191 Path MTU Discovery

← Older revision		Revision as of 11:59, 10 March 2017
Line 383:		Line 383:
	* RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls		* RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
	* RFC 6275 Mobility Support in IPv6		* RFC 6275 Mobility Support in IPv6
−
−	~~== Référence bibliographique ==~~
−	~~<references />~~

@@ Line 353: / Line 353: @@
 A noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.
 == Référence bibliographique ==
 <references />

@@ Line 350: / Line 350: @@
 IP6 :: > ff02::1:ff02:202: ICMP6, neighbor solicitation, who has 2001:db8:b:2:fd:c8ff:fe02:202
 IP6 2001:db8:b:2:fd:c8ff:fe02:202 > ff02::1: ICMP6, neighbor advertisement, tgt is 2001:db8:b:2:fd:c8ff:fe02:202
-''Le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''
+'''''Nota : ''''' ''Le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.''
 A noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.

← Older revision		Revision as of 11:42, 10 March 2017
Line 294:		Line 294:

	Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages "Demande d'écho" et "Réponse d'écho" ont été présentés précédemment dans le paragraphe "Test d'accessibilité d'un noeud".		Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages "Demande d'écho" et "Réponse d'écho" ont été présentés précédemment dans le paragraphe "Test d'accessibilité d'un noeud".
		+
		+	Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les noeuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque noeud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 5 et 6 un échange NUD. Il s'agit du noeud Ganesha qui lance une vérification de la validité du noeud Uma.
		+
		+	IPv6
		+	Version : 6 Classe : 0x00 Label : 000000
		+	Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
		+	Nombre de sauts : 255 (0xff)
		+	Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
		+	Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
		+	ICMPv6
		+	Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116
		+	Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (ganesha)
		+	Option :
		+	Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
		+
		+	0000: ''6000 0000 0020 3aff fe80 0000 0000 0000''
		+	0010: ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''
		+	0020: ''0a00 20ff fe0a aa6d\|<font color="blue">8700 1116 0000 0000''</font>
		+	0030: <font color="blue">''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''</font>
		+	0040: <font color="blue">''0101 1a00 200c 7a34''</font>
		+	<center>'''Trace 5: Message ICMPv6 Sollicitation de voisin(NS).'''</center>
		+	On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, la machine émettrice effacera l'entrée de son cache "Résolution de voisin". Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.<br>
		+	La réception du message "Annonce voisin" (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ <tt>cible</tt> du message d'Annonce de voisin.
		+
		+	IPv6
		+	Version : 6 Classe : 0x00 Label : 000000
		+	Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)
		+	Nombre de sauts : 255 (0xff)
		+	Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
		+	Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
		+	ICMPv6
		+	Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f
		+	Bits (0x4) R = 0, S = 1, O = 0
		+	Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
		+
		+	0000: ''6000 0000 0018 3aff 2001 0db8 0012 0003''
		+	0010: ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''
		+	0020: ''1800 20ff fe0c 7a34\|<font color="blue">8800 855f 4000 0000''</font>
		+	0030: <font color="blue">''2001 0db8 0012 0003 0a00 20ff fe0a aa6d</font>''
		+	<center>'''Trace 6: Message ICMPv6 Annonce de voisin(NA).'''</center>

	=== Fonctionnement de la détection d'adresse dupliquée ===		=== Fonctionnement de la détection d'adresse dupliquée ===

@@ Line 297: / Line 297: @@
 === Fonctionnement de la détection d'adresse dupliquée ===
 Pour vérifier l'unicité des adresses lien-local ou unicast qui viennent d'être configurées manuellement ou automatiquement sur leurs interfaces, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser [RFC 4862]. L'algorithme utilise les messages ICMPv6 "sollicitation d'un voisin" et "annonce d'un voisin". Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire.
 Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans une en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message "sollicitation d'un voisin" avec, dans le champ <tt>adresse de la cible</tt>, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :
@@ Line 302: / Line 305: @@
 # Un message "sollicitation d'un voisin" est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
 # Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état provisoire à celui de valide et elle est assignée à l'interface.
 A noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.

@@ Line 242: / Line 242: @@
   PING ganesha (2001:db8:12:3::3): 56 data bytes
 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms
 Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du noeud destinataire. Dans notre exemple, le noeud destinataire est le destinataire final autrement dit le récepteur. Dans d'autre situation, le destinataire est le noeud destinaire de la transmission comme le routeur du lien (''next hop''). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution  par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 3.

@@ Line 154: / Line 154: @@
 * erreur de paramètre (type 4),
-'''''Nota : ''''' ''une description des messages courants d'erreur rapportés par ICMPv6 est disponible dans le document annexe à cette activité [[MOOC:Annexe_Compagnon_Act31]]''
+'''''Nota : ''''' ''une description de ces messages ICMPv6 est disponible dans le document annexe à cette activité [[MOOC:Annexe_Compagnon_Act31]]''
 == Découverte des voisins ==