Il ne reste que quelques jours avant le lancement d'un nouveau cours par OTUS. À cette occasion, nous souhaitons partager avec vous une traduction d'un matériel utile sur le sujet.
Une série d'articles de blog consacrés à des conseils et des recommandations pour résoudre les problèmes liés au ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Veuillez noter que j'utilise Linux (en particulier Fedora 31), cependant, la syntaxe de la commande ping pour d'autres systèmes d'exploitation devrait être très similaire.
Ping de tous les nœuds IPv6 sur le canal
Le premier et le plus simple des conseils est de pinger tous les nœuds IPv6 sur le canal.
IPv6 utilise des adresses multicast pour tous les types de communication « un à plusieurs ». Il n'existe pas d'adresses IPv6 de type broadcast (ou diffusion). Cela distingue IPv6 d'IPv4, où il existe plusieurs types d'adresses de diffusion, par exemple, l'adresse de « diffusion limitée » 255.255.255.255 [RFC1122].
Cependant, il existe une adresse IPv6 multicast « all-nodes » (multicast de tous les nœuds), que nous utiliserons pour pinger tous les nœuds IPv6 sur le canal. (L'adresse de « diffusion » est en fait simplement un nom spécial pour une adresse multicast qui est un groupe de diffusion multicast incluant tous les nœuds. Notez que, par exemple, le bit « groupe » ou l'adresse multicast est inclus dans les adresses de diffusion au niveau Ethernet).
L'adresse multicast IPv6 all-nodes pour le canal : ff02::1. ff indique une adresse multicast IPv6. Le suivant 0 fait partie du drapeau avec des bits non définis.
Ensuite 2 détermine la zone de groupe multicast. Contrairement aux adresses multicast IPv4, les adresses multicast IPv6 ont une portée (scope). La valeur de la portée indique la partie du réseau sur laquelle il est permis de transmettre un paquet multicast. Une fois le paquet atteint la limite de la portée spécifiée, il doit être abandonné, peu importe si son champ de compteur de sauts (Hop Count) est non nul. Bien sûr, si le compteur de sauts atteint zéro avant d'atteindre la limite de la zone multicast spécifiée, il est également immédiatement abandonné. Voici la liste complète des scopes multicast IPv6.
Enfin, ::1 indique le groupe multicast all-nodes.
À propos de l'adresse ff02::1 il convient de noter qu'elle est ambiguë. Sur un nœud IPv6 avec plusieurs interfaces, comme un routeur ou un hôte multi-réseau, dans l'adresse ff02::1 Il n'y a rien où l'on pourrait spécifier à quel interface envoyer les requêtes écho ICMPv6 ou s'attendre à recevoir les réponses écho ICMPv6 lorsqu'elles arrivent. ff02::1 Il est valide et peut être utilisé sur n'importe quelle des interfaces et canaux attachés à un nœud multi-interface.
Par conséquent, lorsque nous effectuons un ping sur tous les nœuds IPv6 sur le canal, nous devons également informer l'utilitaire. ping pour IPv6, quel interface utiliser.
La définition des interfaces est un paramètre de ligne de commande.
Comme nous l'avons déjà vu, l'adresse multicast all-nodes que nous voulons utiliser — ff02::1 — ne fournit aucune information sur l'interface à laquelle envoyer et recevoir les paquets de requêtes et réponses écho ICMPv6.
Alors, comment pouvons-nous spécifier l'interface à utiliser pour l'espace d'adresses multicast ou les adresses Link-Local unicast ?
La première et la plus évidente des méthodes est de la fournir comme paramètre à l'application que nous utilisons.
Pour l'utilitaire ping nous la fournissons via l'option -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Avertissement: l'adresse source peut être sélectionnée sur un appareil autre que : enp3s2
PING ff02::1(ff02::1) de :: enp3s2: 56 octets de données
64 octets de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 temps=0.438 ms
64 octets de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 temps=0.589 ms (DUP!)
64 octets de fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 temps=5.15 ms (DUP!)
64 octets de fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 temps=58.0 ms (DUP!)
64 octets de fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 temps=62.3 ms (DUP!)
64 octets de fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 temps=62.8 ms (DUP!)
--- statistiques de ping ff02::1 ---
1 paquets transmis, 1 reçu, +5 doublons, 0% de perte de paquets, temps 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Avec ce ping all-nodes multicast, nous avons reçu des réponses de 6 nœuds IPv6. Les réponses provenaient d'adresses IPv6 Link-Local de nœuds, commençant par le préfixe fe80::/10.
Pour que ping nous n'avons pas continué à envoyer indéfiniment des requêtes écho ICMPv6 jusqu'à ce que nous l'interrompions, nous spécifions généralement le nombre de paquets à envoyer via l'option -c. Cependant, cela n'empêche pas non plus ping de recevoir et d'afficher plus d'une réponse écho ICMPv6 lors de l'envoi d'une requête écho ICMPv6 multicast. Au lieu de cela, nous avons utilisé le paramètre -w pour indiquer que ping devait se terminer après 1 seconde, quel que soit le nombre de requêtes écho ou de réponses écho ICMPv6 qui ont été envoyées ou reçues.
Une autre chose à noter est (DUP!) sortie sur les secondes réponses et suivantes. Ces paquets sont identifiés comme des doublons de réponse, car ils ont la même valeur de séquence ICMP que les requêtes écho ICMPv6 individuelles qui ont été envoyées en premier. Ils apparaissent parce que la requête écho ICMPv6 en multicast entraîne plusieurs réponses unicast individuelles. Le nombre de doublons est également indiqué dans le résumé des statistiques.
Définition des interfaces — Zone ID
Une autre façon de fournir une interface est de faire partie du paramètre d'adresse IPv6.
Nous pouvons observer un exemple de cela dans la sortie de ping, où les adresses des nœuds IPv6 qui répondent ont également un suffixe %enp3s2, par exemple :
64 octets de fe80::1d36:1fff:fefd:82be%enp3s2 : icmp_seq=1 ttl=64 temps=0.438 msCette méthode de définition des interfaces est formellement décrite dans [RFC4007], « Architecture avec adresses IPv6 définies ». Bien qu'elles soient généralement appelées interface d'un système d'exploitation, elles définissent en réalité quelque chose de plus général — « zone » ou « portée ».
La raison d'avoir des zones générales ou des zones de portée est que, comme mentionné dans [RFC4007], un nœud IPv6 peut avoir plusieurs interfaces IPv6 différentes connectées au même canal. Ces interfaces sont membres d'une même zone.
Il devrait être possible de grouper plusieurs interfaces au sein d'une zone sous un système d'exploitation ; actuellement, je ne sais pas si cela est possible sous Linux et comment le faire.
En utilisant le suffixe %, nous pouvons supprimer le paramètre de ligne de commande -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 octets de données
64 octets de fe80::2392:6213:a15b:66ff%enp3s2 : icmp_seq=1 ttl=64 temps=0.106 ms
64 octets de fe80::1d36:1fff:fefd:82be%enp3s2 : icmp_seq=1 ttl=64 temps=0.453 ms (DUP !)
64 octets de fe80::f31c:ccff:fe26:a6d9%enp3s2 : icmp_seq=1 ttl=64 temps=0.606 ms (DUP !)
64 octets de fe80::7e31:f5ff:fe1b:9fdb%enp3s2 : icmp_seq=1 ttl=64 temps=6.23 ms (DUP !)
64 octets de fe80::f7f8:15ff:fe6f:be6e%enp3s2 : icmp_seq=1 ttl=64 temps=157 ms (DUP !)
64 octets de fe80::877d:4ff:fe1a:ad79%enp3s2 : icmp_seq=1 ttl=64 temps=159 ms (DUP !)
64 octets de fe80::877d:4ff:fe1a:b881%enp3s2 : icmp_seq=1 ttl=64 temps=161 ms (DUP !)
64 octets de fe80::23d:e8ff:feec:958c%enp3s2 : icmp_seq=1 ttl=64 temps=179 ms (DUP !)
--- statistiques de ping ff02::1%enp3s2 ---
1 paquets transmis, 1 reçu, +7 doublons, 0 % de perte de paquets, temps 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Réponses des adresses Link-Local
De ce ping multicast all-nodes, nous avons reçu un total de 6 réponses uniques.
Ces réponses provenaient d'adresses Link-Local unicast des nœuds IPv6. Par exemple, voici la première réponse :
64 octets de fe80::2392:6213:a15b:66ff%enp3s2 : icmp_seq=1 ttl=64 temps=0.106 msLes adresses IPv6 Link-Local sont requises sur toutes les interfaces prenant en charge IPv6 [RFC4291], « Architecture d'adressage IP version 6 ». La raison en est qu'un nœud IPv6 a toujours automatiquement une adresse IPv6 unicast qu'il peut utiliser, au moins pour communiquer avec d'autres nœuds via ses canaux connectés directement. Cela inclut la communication avec des applications d'autres hôtes via des adresses Link-Local.
Cela simplifie le développement et la mise en œuvre de protocoles tels que la découverte de voisins IPv6 et OSPFv3. Cela permet également aux applications des utilisateurs finaux sur les hôtes d'échanger des données sur le canal, sans nécessiter d'autres infrastructures de support IPv6 sur le canal. Pour la communication directe entre hôtes connectés, aucun routeur IPv6 ou serveur DHCPv6 n'est requis dans la connexion.
Les adresses Link-Local commencent par un préfixe de 10 bits fe80, suivi de 54 bits nuls, puis d'un identifiant d'interface (IID) de 64 bits. Dans la première réponse ci-dessus, 2392:6213:a15b:66ff — c'est un IID de 64 bits.
Multicast en boucle
Par défaut, les paquets multicast sont renvoyés en interne au nœud qui les envoie. Cela se produit pour les adresses IPv6 et IPv4.
La raison de ce comportement par défaut est que lors de l'envoi de paquets multicast, une application multicast locale peut également être à l'écoute, fonctionnant sur le même hôte émetteur, tout comme quelque part sur le réseau. Cette application locale doit également recevoir des paquets multicast.
Nous pouvons voir ce cycle local multicast dans notre sortie ping :
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 octets de données
64 octets de fe80::2392:6213:a15b:66ff%enp3s2 : icmp_seq=1 ttl=64 time=0.106 ms
64 octets de fe80::1d36:1fff:fefd:82be%enp3s2 : icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...La première et la plus rapide réponse (0.106 ms contre 0.453 ms) provient de l'adresse Link-Local configurée sur l'interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope lien noprefixroute
[mark@opy ~]$Utilitaire ping fournit un moyen de supprimer les retours locaux des diffusions multicast à l'aide du paramètre -L. Si nous envoyons un ping multicast to all-nodes avec ce drapeau, les réponses se limitent aux nœuds distants. Nous ne recevons pas de réponse de l'adresse Link-Local de l'interface d'émission.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 octets de données
64 octets de fe80::1d36:1fff:fefd:82be%enp3s2 : icmp_seq=1 ttl=64 time=0.383 ms
64 octets de fe80::f31c:ccff:fe26:a6d9%enp3s2 : icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Ping de l'adresse Link-Local
Comme vous pouvez le deviner, les adresses Link-Local unicast ne fournissent pas à elles seules suffisamment d'informations pour indiquer quel interface utiliser pour y accéder. Comme pour le ping multicast all-nodes, nous devons également spécifier l'interface comme un paramètre de ligne de commande ping ou l'ID de zone avec l'adresse lors du ping des adresses Link-Local.
Cette fois, nous pouvons utiliser -c, pour limiter le nombre de paquets et de réponses envoyés et reçus ping, car nous effectuons un ping unicast.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 octets de données
64 octets de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 temps=0.395 ms
--- statistiques de ping pour fe80::f31c:ccff:fe26:a6d9%enp3s2 ---
1 paquets transmis, 1 reçu, 0% de perte de paquets, temps 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping (tous) les autres adresses IPv6?
Dans cet article, nous avons vu comment pinger tous les nœuds IPv6 sur le canal en utilisant l'adresse multicast IPv6 all-nodes ff02::1. Nous avons également vu comment spécifier quelle interface utiliser avec l'adresse multicast IPv6 all-nodes, car l'adresse elle-même ne peut pas fournir cette information. Nous avons utilisé soit le paramètre de ligne de commande ping, soit nous avons spécifié l'interface via le suffixe %.
Nous avons ensuite appris sur les adresses Link-Local unicast, qui sont des adresses utilisées pour répondre aux requêtes ICMPv6 echo multicast all-nodes.
Nous avons également vu comment les paquets multicast sont retournés au nœud émetteur par défaut et comment désactiver cela pour l'utilitaire ping.
Enfin, nous avons pingé une adresse Link-Local unique en utilisant le suffixe %, car les adresses Link-Local elles-mêmes ne fournissent pas d'informations sur l'interface sortante.
Que diriez-vous de pinger tous les autres nœuds et d'obtenir leurs adresses unicast globales (GUA) (c'est-à-dire leurs adresses publiques sur Internet) ou leurs adresses unicast locales uniques (ULA)? Nous examinerons cela dans le prochain article de blog.
C'est tout.
En savoir plus sur notre cours dans.
Source : habr.com
