Il reste quelques jours avant le début d'un nouveau flux au rythme de l'OTUS. À cet égard, nous aimerions partager avec vous une traduction de documents utiles sur le sujet.
Une série d'articles de blog sur des trucs et astuces pour résoudre les problèmes de ping IPv6 (ICMPv6 Echo Request/Echo Reply)
Veuillez noter que j'utilise Linux (en particulier Fedora 31), mais la syntaxe de la commande ping pour d'autres systèmes d'exploitation devrait, espérons-le, être très similaire.
Pingez tous les nœuds IPv6 sur un canal
Le premier et le plus simple conseil consiste à envoyer une requête ping à tous les nœuds IPv6 sur le lien.
IPv6 utilise des adresses de multidiffusion pour tous les types de communications un-à-plusieurs. Il n’y a pas d’adresses IPv6 de diffusion (ou de 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 « multidiffusion sur tous les nœuds », nous l'utiliserons donc pour envoyer une requête ping à tous les nœuds IPv6 sur la liaison. (Une adresse de « diffusion » est en fait simplement une adresse de multidiffusion spécialement nommée, qui est un groupe de multidiffusion qui inclut tous les nœuds. Notez que, par exemple, le bit « groupe » ou d'adresse de multidiffusion est activé dans les adresses de diffusion Ethernet au niveau de la couche liaison. ).
Adresse IPv6 de multidiffusion sur tous les nœuds pour le canal : ff02::1. ff désigne une adresse IPv6 de multidiffusion. Le 0 suivant est la partie du drapeau avec les bits non définis.
Suivant 2 définit la zone d'un groupe multicast. Contrairement aux adresses IPv4 de multidiffusion, les adresses IPv6 de multidiffusion ont une portée. La valeur de portée indique la partie du réseau sur laquelle un paquet de multidiffusion peut être transmis. Une fois qu'un paquet atteint la limite de la portée spécifiée, le paquet doit être abandonné, que son champ Hop Count soit différent de zéro ou non. Bien entendu, si le nombre de sauts atteint zéro avant d’atteindre la limite spécifiée du groupe de multidiffusion, il est également immédiatement réinitialisé. Voici une liste complète des portées de multidiffusion IPv6.
Enfin, le ::1 spécifie un groupe de multidiffusion composé de tous les nœuds.
À propos de l'adresse ff02::1 Il convient de noter que c'est ambigu. Sur un hôte IPv6 doté de plusieurs interfaces, tel qu'un routeur ou un hôte multirésident, l'adresse ff02::1 il n'y a rien où vous pouvez spécifier à quelle interface envoyer les demandes d'écho ICMPv6 ou vous attendre à recevoir des réponses d'écho ICMPv6 à leur arrivée. ff02::1 est valide et peut être utilisé sur n’importe quelle interface et canal attaché au nœud multi-interface.
Ainsi, lorsque nous pingons tous les nœuds IPv6 sur une liaison, nous devons également informer l'utilitaire ping pour IPv6, quelle interface utiliser.
Définition des interfaces - Option de ligne de commande
Comme nous l'avons déjà vu, l'adresse de multidiffusion de tous les nœuds que nous souhaitons utiliser est - ff02::1 - ne fournit aucune information sur l'interface sur laquelle envoyer et recevoir les paquets de demande d'écho et de réponse d'écho ICMPv6.
Alors, comment spécifier l'interface à utiliser pour l'espace d'adressage multicast ou l'espace d'adressage Link-Local unicast ?
La première et la plus évidente consiste à le fournir comme paramètre à l’application que nous utilisons.
Pour l'utilité ping nous le fournissons via l'option -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$En utilisant ce ping multicast sur tous les nœuds, nous avons reçu des réponses de 6 nœuds IPv6. Les réponses provenaient des adresses de nœuds Link-Local IPv6, en commençant par le préfixe fe80::/10.
Que ping ne continue pas à envoyer des requêtes d'écho ICMPv6 indéfiniment jusqu'à ce que nous l'interrompions, nous spécifions généralement le nombre de paquets à envoyer via l'option -c. Cependant, cela empêche également le ping d'accepter et d'afficher plusieurs réponses d'écho ICMPv6 lors de l'envoi d'une demande d'écho ICMPv6 multidiffusion. Au lieu de cela, nous avons utilisé l'option -w pour spécifier que le ping doit se terminer après 1 seconde, quel que soit le nombre de demandes d'écho ou de réponses d'écho ICMPv6 envoyées ou reçues.
Une autre chose à laquelle il faut faire attention est (DUP!) sortie sur la deuxième réponse et les suivantes. Ces paquets sont identifiés comme des réponses en double car ils ont la même valeur de séquence ICMP que les demandes d'écho ICMPv6 individuelles envoyées en premier lieu. Ils apparaissent car une demande d'écho de multidiffusion ICMPv6 entraîne plusieurs réponses individuelles de monodiffusion. Le nombre de doublons est également indiqué dans la synthèse des statistiques.
Définition des interfaces - ID de zone
Une autre façon d’exposer une interface à utiliser consiste à l’intégrer à un paramètre d’adresse IPv6.
Nous pouvons en voir un exemple dans la sortie ping, où les adresses des hôtes IPv6 répondants portent également le suffixe %enp3s2, Par exemple:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msCette méthode de spécification des interfaces est formellement décrite dans la [RFC4007], « Architecture d'adresse définie IPv6 ». Bien qu’elles soient généralement appelées interface du système d’exploitation, elles définissent en réalité quelque chose de plus général : une « zone » ou une « portée ».
La raison pour laquelle il y a des zones plus générales ou des zones de portée est que, comme mentionné dans la [RFC4007], un nœud IPv6 peut avoir plusieurs interfaces IPv6 différentes connectées au même canal. Ces interfaces sont membres de la même zone.
Il devrait être possible de regrouper plusieurs interfaces au sein d’une zone sous le système d’exploitation ; Actuellement, je ne sais pas si cela est possible sous Linux ni comment le faire.
Utiliser le suffixe %<zone_id>, nous pouvons supprimer l'option de ligne de commande -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Réponses d'adresse lien-local
De ce ping multidiffusion sur tous les nœuds, nous avons reçu un total de 6 réponses uniques.
Ces réponses provenaient d’adresses d’hôte IPv6 Link-Local en monodiffusion. Par exemple, voici la première réponse :
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msLes adresses IPv6 Unicast Link-Local sont requises sur toutes les interfaces compatibles IPv6 [RFC4291], « Architecture d'adressage IP version 6 ». La raison en est qu'un nœud IPv6 dispose toujours automatiquement d'une adresse IPv6 unicast, qu'il peut au moins utiliser pour communiquer avec d'autres nœuds sur ses liens directement connectés. Cela inclut la communication avec des applications sur d'autres hôtes via des adresses d'hôte Link-Local.
Cela simplifie la conception et la mise en œuvre de protocoles tels que IPv6 Neighbour Discovery et OSPFv3. Il permet également aux applications des utilisateurs finaux sur les hôtes de communiquer sur le canal sans nécessiter aucune autre infrastructure IPv6 de support sur le canal. La communication directe entre les hôtes IPv6 connectés ne nécessite pas de routeur IPv6 ou de serveur DHCPv6 sur la connexion.
Les adresses Link-Local commencent par un préfixe de 10 bits fe80, suivi de 54 bits zéro, puis d'un identifiant d'interface (IID) de 64 bits. Dans la première réponse ci-dessus 2392:6213:a15b:66ff est un IID 64 bits.
Multidiffusion en boucle
Par défaut, les paquets multicast sont renvoyés en interne au nœud qui les a envoyés. Cela se produit pour l’adressage IPv6 et IPv4.
La raison de ce comportement par défaut est que lorsque des paquets de multidiffusion sont envoyés, il peut également y avoir une application de multidiffusion locale d'écoute exécutée sur l'hôte émetteur lui-même, ainsi que quelque part sur le réseau. Cette application locale doit également recevoir des paquets multicast.
Nous pouvons voir cette boucle locale de multidiffusion dans notre sortie ping :
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from 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 elle-même. enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilitaire ping fournit un moyen de supprimer les commentaires de multidiffusion locale à l'aide du paramètre -L. Si nous envoyons un ping multicast à tous les nœuds avec cet indicateur, alors les réponses sont limitées aux nœuds distants. Nous ne recevons pas de réponse de l'adresse Link-Local de l'interface d'envoi.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Adresses locales du lien Ping
Comme vous pouvez le deviner, les adresses Link-Local en monodiffusion ne fournissent pas non plus suffisamment d'informations pour indiquer quelle interface utiliser pour les atteindre. Comme pour le ping multicast sur tous les nœuds, nous devons également spécifier l'interface en tant que paramètre de ligne de commande. ping ou ID de zone avec adresse lors du ping des adresses Link-Local.
Cette fois, nous pouvons utiliser -climiter le nombre de paquets et de réponses envoyés et reçus ping, puisque 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 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping (toutes) les autres adresses IPv6 ?
Dans cet article, nous avons vu comment envoyer une requête ping à tous les nœuds IPv6 sur un canal à l'aide d'une adresse IPv6 de multidiffusion pour tous les nœuds. ff02::1. Nous avons également vu comment spécifier quelle interface utiliser avec une adresse IPv6 multicast tous nœuds, puisque l'adresse elle-même ne peut pas fournir cette information. Nous avons utilisé soit l'option de ligne de commande ping, ou spécifié l'interface à l'aide du suffixe %<zone_id>.
Nous avons ensuite découvert les adresses Link-Local unicast, qui sont des adresses utilisées pour répondre aux demandes d'écho ICMPv6 multicast de tous les nœuds.
Nous avons également vu comment les paquets multicast sont renvoyés par défaut au nœud expéditeur et comment désactiver cela pour l'utilitaire. ping.
Enfin, nous avons envoyé une requête ping à une seule adresse Link-Local en utilisant le suffixe %<zone_id>, puisque les adresses Link-Local elles-mêmes ne fournissent pas non plus d'informations sur l'interface sortante.
Alors, qu'en est-il d'un ping sur tous les autres nœuds et d'obtenir leurs adresses de monodiffusion globales (GUA) (c'est-à-dire leurs adresses publiques sur Internet) ou leurs adresses de monodiffusion locales uniques (ULA) ? Nous y reviendrons dans le prochain article du blog.
C'est tout.
Vous pouvez en savoir plus sur notre cours sur.
Source: habr.com