Quedan unos días hasta el inicio de una nueva transmisión en el curso "Ingeniero de redes" de OTUS. En este sentido, queremos compartir con ustedes la traducción de material útil sobre el tema.
Una serie de artículos de blog sobre sugerencias y trucos de resolución de problemas de ping IPv6 (solicitud de eco ICMPv6 / respuesta de eco)Tenga en cuenta que uso Linux (específicamente Fedora 31), sin embargo, la sintaxis del comando ping para otros sistemas operativos, espero Debería ser muy similar.Haga ping a todos los hosts IPv6 en el canal
El primer y más fácil consejo es hacer ping a todos los hosts IPv6 en el canal.IPv6 utiliza direcciones de multidifusión para todos los tipos de comunicaciones uno a muchos. No hay direcciones IPv6 de difusión (o difusión). Esto distingue IPv6 de IPv4, donde hay varios tipos de direcciones de difusión, por ejemplo, la dirección de "difusión limitada" 255.255.255.255 [RFC1122].Sin embargo, existe una dirección IPv6 “multidifusión de todos los nodos”, por lo que la utilizaremos para hacer ping a todos los nodos IPv6 en el canal. (Una dirección de "difusión" es en realidad una dirección de multidifusión especialmente nombrada, que es un grupo de multidifusión que incluye todos los nodos. Tenga en cuenta que, por ejemplo, el bit de "grupo" o dirección de multidifusión se incluye en las direcciones de difusión Ethernet en el nivel de enlace).Dirección IPv6 de multidifusión de todos los nodos para el canal: ff02::1. ffdenota una dirección IPv6 de multidifusión. El siguiente 0 es parte de la bandera con bits sin establecer.Además 2define el área del grupo de multidifusión. A diferencia de las direcciones de multidifusión IPv4, las direcciones de multidifusión IPv6 tienen alcance. El valor del alcance indica la parte de la red a través de la cual se permiten los paquetes de multidifusión. Una vez que el paquete alcanza el límite del alcance especificado, el paquete debe descartarse, independientemente de si su campo Hop Count no es cero. Por supuesto, si el contador de conversión llega a cero antes de alcanzar el límite especificado del grupo de multidifusión, también se restablece de inmediato. Aquí hay una lista completa del alcance de multidifusión IPv6.Finalmente, ::1indica el grupo de multidifusión de todos los nodos.Sobre la dirección ff02::1, debe tenerse en cuenta que es ambigua. En un host IPv6 con múltiples interfaces, como un enrutador o host múltiple, ff02::1no hay nada en la dirección donde pueda especificar a qué interfaz enviar pings ICMPv6 o esperar pings ICMPv6 cuando lleguen. ff02::1válido y se puede usar en cualquiera de las interfaces y canales conectados al nodo de interfaz múltiple.Por lo tanto, cuando hacemos ping a todos los nodos de IPv6 en el canal, también necesitamos decirle de alguna manera a la utilidad pingpara IPv6 qué interfaz usar.Definición de interfaz - Opción de línea de comando
Como ya hemos visto, la dirección de multidifusión de todos los nodos que queremos usar - ff02::1no proporciona ninguna información sobre a qué interfaz enviar y recibir paquetes de solicitud de eco ICMPv6 y respuesta de eco.Entonces, ¿cómo especificamos la interfaz que se utilizará para el espacio de direcciones de multidifusión o las direcciones de enlace local de unidifusión?La primera y más obvia forma es proporcionarlo como parámetro para la aplicación que utilizamos.Para la utilidad, la pingproporcionamos a través de la opción -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 ~]$
Usando este ping de multidifusión de todos los nodos, recibimos respuestas de 6 nodos IPv6. Las respuestas vinieron de las direcciones IPv6 de enlace local del host, comenzando con el prefijo fe80::/10.Para pingevitar que las solicitudes de eco ICMPv6 continúen sin cesar hasta que lo anulemos, generalmente especificamos el número de paquetes a enviar a través de la opción -c. Sin embargo, esto también evita que ping reciba y muestre más de una respuesta de eco ICMPv6 al enviar una solicitud de eco ICMPv6 de multidifusión. En su lugar, utilizamos la opción -w para indicar que el ping debe completarse después de 1 segundo, independientemente de cuántos pings o pings ICMPv6 se hayan enviado o recibido.Otra cosa a la que prestar atención es (DUP!) conclusión sobre la segunda y posteriores respuestas. Estos paquetes se identifican como duplicados de la respuesta, porque tienen el mismo valor de secuencia de ICMP que los pings de ICMPv6 individuales que se enviaron primero. Aparecen porque la solicitud de eco de multidifusión ICMPv6 da como resultado varias respuestas de unidifusión individuales. El número de duplicados también se indica en el resumen de estadísticas.Definición de interfaz - ID de zona
Otra forma de proporcionar una interfaz para usar es parte del parámetro de dirección IPv6.Podemos ver un ejemplo de esto en la salida de ping, donde las direcciones de los nodos IPv6 que responden también tienen un sufijo %enp3s2, por ejemplo:64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
Este método de definición de interfaces se describe formalmente en [RFC4007], "Arquitectura con direcciones IPv6 especificadas". Aunque generalmente se denominan la interfaz del sistema operativo, en realidad definen algo más general: una "zona" o un "alcance".La razón para tener zonas más generales o zonas de alcance es porque, como se menciona en [RFC4007], un host IPv6 puede tener varias interfaces IPv6 diferentes conectadas al mismo canal. Estas interfaces son miembros de la misma zona.Debería ser posible agrupar varias interfaces dentro de la zona bajo el sistema operativo; Actualmente, no sé si esto es posible en Linux y cómo hacerlo.Usando el sufijo %<zone_id>, podemos eliminar el parámetro de línea de comando -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 ~]$
Respuestas de dirección local de enlace
De este ping de multidifusión de todos los nodos, recibimos un total de 6 respuestas únicas.Estas respuestas provienen de direcciones de host IPv6 de enlace de unidifusión local. Por ejemplo, aquí está la primera respuesta:64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
Se requieren direcciones IPv6 de enlace de unidifusión locales en todas las interfaces habilitadas para IPv6 [RFC4291], Arquitectura de direccionamiento de la versión 6 de IP. La razón de esto es que el host IPv6 siempre tiene automáticamente una dirección IPv6 de unidifusión, que puede usar, al menos para comunicarse con otros hosts a través de sus canales conectados directamente. Esto incluye la comunicación con aplicaciones de otros hosts a través de direcciones de host Link-Local.Esto simplifica el desarrollo y la implementación de protocolos como IPv6 Neighbor Discovery y OSPFv3. También permite que las aplicaciones de usuario final en los hosts se comuniquen a través del canal sin requerir ninguna otra infraestructura IPv6 de soporte en el canal. La comunicación directa entre los hosts IPv6 conectados no requiere un enrutador IPv6 o un servidor DHCPv6 en conexión.Las direcciones locales de enlace comienzan con un prefijo de 10 bits fe80, seguido de 54 bits cero, seguido de un identificador de interfaz de 64 bits (IID). En la primera respuesta anterior 2392:6213:a15b:66ff, este es un IID de 64 bits.Multidifusión en bucle
Por defecto, los paquetes de multidifusión se devuelven internamente al nodo que los envía. Esto sucede para las direcciones IPv6 e IPv4.La razón de este comportamiento predeterminado es que al enviar paquetes de multidifusión, también puede haber una aplicación de multidifusión local en ejecución que se ejecuta en el host de envío, así como en algún lugar de la red. Esta aplicación local también debería recibir paquetes de multidifusión.Podemos ver este bucle local de multidifusión en nuestra salida de 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 primera y más rápida respuesta (0,106 ms en comparación con 0,453 ms) proviene de la dirección Link-Local configurada en la propia interfaz enp3s2.[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$
La utilidad pingproporciona una forma de suprimir la retroalimentación local del correo de multidifusión utilizando un parámetro -L. Si enviamos un ping de multidifusión de todos los nodos con este indicador, las respuestas se limitarán a los nodos remotos. No recibimos una respuesta de la dirección Link-Local de la interfaz del remitente.[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!)
...
Direcciones locales de enlace de ping
Como puede adivinar, las direcciones de enlace local de unidifusión en sí mismas tampoco proporcionan suficiente información para indicar qué interfaz utilizar para llegar a ellas. Como en el caso del ping de multidifusión de todos los nodos, también debemos especificar la interfaz como un parámetro de línea de comando pingo ID de zona con la dirección al hacer ping a las direcciones locales de enlace.Esta vez podemos usar -cpara limitar la cantidad de paquetes y respuestas enviadas y recibidas ping, ya que realizamos un ping de unidifusión.[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 (todas) otras direcciones IPv6?
En este artículo, vimos cómo hacer ping a todos los nodos IPv6 en un canal utilizando una dirección IPv6 multicast de todos los nodos ff02::1. También vimos cómo especificar qué interfaz usar con la dirección IPv6 de multidifusión de todos los nodos, ya que la dirección por sí sola no puede proporcionar esta información. Utilizamos un parámetro de línea de comando pingo especificamos una interfaz a través de un sufijo %<zone_id>.Luego nos enteramos de las direcciones de enlace local de unidifusión, que son las direcciones utilizadas para responder a las solicitudes de eco ICMPv6 de multidifusión de todos los nodos.También vimos cómo los paquetes de multidifusión regresan al host emisor de forma predeterminada y cómo deshabilitar esto para la utilidad ping.Finalmente, fijamos una sola dirección Link-Local usando el sufijo%<zone_id>dado que las direcciones locales de enlace por sí solas no proporcionan información sobre la interfaz saliente.Entonces, ¿qué pasa con hacer ping a todos los otros nodos y recuperar sus direcciones Unicast globales (GUA) (es decir, sus direcciones públicas de Internet) o sus direcciones locales Unicast (ULA) únicas? Cubriremos esto en la próxima publicación del blog.Eso es todo.Puede encontrar más información sobre nuestro curso en la entrada de día abierto .