Quedan solo unos días para el inicio del nuevo curso de OTUS. Con esto, queremos compartir con ustedes la traducción de un material útil sobre el tema.
Serie de artículos en el blog dedicados a consejos y recomendaciones para solucionar problemas relacionados con el ping de IPv6 (ICMPv6 Echo Request/Echo Reply)
Tenga en cuenta que estoy usando Linux (en particular, Fedora 31), sin embargo, la sintaxis del comando ping para otros sistemas operativos debería ser muy parecida.
Ping de todos los nodos IPv6 en el canal
El primer y más simple consejo es hacer ping a todos los nodos IPv6 en el canal.
IPv6 utiliza direcciones multicast para todos los tipos de comunicación «uno a muchos». No existen direcciones de difusión (broadcast) IPv6. Esto diferencia a IPv6 de IPv4, donde hay varios tipos de direcciones de difusión, como la dirección de «difusión limitada» 255.255.255.255 [RFC1122].
Sin embargo, hay una dirección IPv6 de multicast «todas las nodos» (all-nodes multicast), por lo que la utilizaremos para hacer ping a todos los nodos IPv6 en el canal. (La dirección «de difusión» es en realidad simplemente una dirección multicast nombrada específicamente, que es un grupo de difusión en multicast que incluye todos los nodos. Tenga en cuenta que, por ejemplo, el bit de «grupo» o de dirección multicast está incluido en las direcciones de difusión Ethernet en el nivel de enlace).
La dirección multicast all-nodes IPv6 para el canal: ff02::1. ff denota una dirección multicast IPv6. El siguiente 0 es parte del indicador con bits no establecidos.
Siguiente 2 define el ámbito del grupo multicast. A diferencia de las direcciones multicast IPv4, las direcciones multicast IPv6 tienen scope (ámbito). El valor de scope indica la parte de la red a través de la cual se permite reenviar el paquete multicast. Una vez que el paquete alcanza el límite del scope especificado, debe ser descartado, independientemente de si su campo de contador de saltos (Hop Count) es distinto de cero. Por supuesto, si el contador de saltos llega a cero antes de alcanzar el límite del grupo multicast especificado, también se descarta de inmediato. Aquí está la lista completa de los scopes multicast IPv6.
Finalmente, ::1 indica el grupo all-nodes multicast.
Acerca de la dirección ff02::1 hay que señalar que no es única. En un nodo IPv6 con múltiples interfaces, como un enrutador o un host multihomed, en la dirección ff02::1 No hay nada que indique a qué interfaz enviar los paquetes de eco ICMPv6 o esperar recibir respuestas de eco ICMPv6 cuando lleguen. ff02::1 Es válido y puede usarse en cualquiera de las interfaces y canales conectados a un nodo multi-interfaz.
Por lo tanto, cuando hacemos ping a todos los nodos IPv6 en el canal, necesitamos de alguna manera notificar a la utilidad ping para IPv6 qué interfaz usar.
La definición de interfaces es un parámetro de la línea de comandos.
Como ya hemos visto, la dirección multicast all-nodes que queremos usar — ff02::1 — no proporciona ninguna información sobre qué interfaz utilizar para enviar y recibir paquetes de eco ICMPv6.
Entonces, ¿cómo especificamos la interfaz que se utilizará para el espacio de direcciones multicast o direcciones Link-Local unicast?
La primera y más obvia forma es proporcionarla como un parámetro para la aplicación que estamos utilizando.
Para la utilidad ping lo proporcionamos a través de la opción -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Advertencia: la dirección de origen podría seleccionarse en un dispositivo diferente de: enp3s2
PING ff02::1(ff02::1) desde :: enp3s2: 56 bytes de datos
64 bytes desde fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tiempo=0.438 ms
64 bytes desde fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tiempo=0.589 ms (DUP!)
64 bytes desde fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 tiempo=5.15 ms (DUP!)
64 bytes desde fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 tiempo=58.0 ms (DUP!)
64 bytes desde fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 tiempo=62.3 ms (DUP!)
64 bytes desde fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 tiempo=62.8 ms (DUP!)
--- estadísticas de ping de ff02::1 ---
1 paquete transmitido, 1 recibido, +5 duplicados, 0% pérdida de paquetes, tiempo 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Con este ping all-nodes multicast, obtuvimos respuestas de 6 nodos IPv6. Las respuestas llegaron de direcciones IPv6 Link-Local de nodo, comenzando con el prefijo fe80::/10.
Para ping no continuó enviando paquetes de eco ICMPv6 indefinidamente hasta que lo detenemos, normalmente especificamos el número de paquetes a enviar mediante la opción -c. Sin embargo, esto tampoco permite que ping acepte y muestre más de una respuesta de eco ICMPv6 al enviar un paquete de eco multicast ICMPv6. En su lugar, utilizamos el parámetro -w para indicar que ping debería finalizar después de 1 segundo, independientemente de cuántos paquetes de eco o respuestas de eco ICMPv6 se hayan enviado o recibido.
Otra cosa a tener en cuenta es (DUP!) salida en las segunda y posteriores respuestas. Estos paquetes se identifican como duplicados de respuesta, ya que tienen el mismo valor de secuencia ICMP que los ecos individuales ICMPv6 que se enviaron primero. Aparecen porque el eco multicast ICMPv6 genera múltiples respuestas unicast individuales. La cantidad de duplicados también se indica en el resumen de estadísticas.
Definición de interfaces — Zone ID
Otra forma de proporcionar una interfaz para su uso es como parte del parámetro de dirección IPv6.
Podemos observar 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 desde fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msEste método de asignación de interfaces está formalmente descrito en [RFC4007], 'Arquitectura de direcciones IPv6 asignadas'. Aunque generalmente se les llama interfaz del sistema operativo, en realidad definen algo más general: 'zona' o 'ámbito'.
La razón de tener zonas más generales o zonas de ámbito es que, como se menciona en [RFC4007], un nodo IPv6 puede tener múltiples interfaces IPv6 conectadas al mismo canal. Estas interfaces son miembros de una misma zona.
Debería ser posible agrupar varias interfaces dentro de una zona bajo el sistema operativo; en este momento, no sé si esto es posible en Linux y cómo hacerlo.
Usando el sufijo %, podemos eliminar el parámetro de la línea de comandos -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de datos
64 bytes desde fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes desde fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes desde fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes desde fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes desde fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes desde fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes desde fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes desde fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- estadísticas de ping ff02::1%enp3s2 ---
1 paquetes transmitidos, 1 recibidos, +7 duplicados, 0% de pérdida de paquetes, tiempo 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Respuestas de direcciones Link-Local
De este ping multicast all-nodes obtuvimos un total de 6 respuestas únicas.
Estas respuestas llegaron de direcciones Link-Local unicast de nodos IPv6. Por ejemplo, aquí está la primera respuesta:
64 bytes desde fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msLas direcciones IPv6 Link-Local son requeridas en todas las interfaces que soportan IPv6 [RFC4291], "Arquitectura de direcciones IP versión 6". La razón de esto es que un nodo IPv6 siempre tiene automáticamente una dirección IPv6 unicast que puede utilizar, al menos, para comunicarse con otros nodos a través de sus canales conectados directamente. Esto incluye la comunicación con aplicaciones de otros hosts a través de las direcciones Link-Local de los hosts.
Esto simplifica el desarrollo e implementación de protocolos como IPv6 Neighbor Discovery y OSPFv3. También permite que las aplicaciones de los usuarios finales en los hosts intercambien datos a través del canal, sin requerir ninguna otra infraestructura de soporte para IPv6 en el canal. No se necesita un enrutador IPv6 o un servidor DHCPv6 en la conexión para la comunicación directa entre hosts conectados.
Las direcciones Link-Local comienzan con un prefijo de 10 bits fe80, seguido de 54 bits en cero, y luego un identificador de interfaz de 64 bits (IID). En la primera respuesta mencionada anteriormente, 2392:6213:a15b:66ff — es el IID de 64 bits.
Multicast en bucle
Por defecto, los paquetes multicast se devuelven internamente al nodo que los envía. Esto ocurre tanto para direcciones IPv6 como IPv4.
La razón de este comportamiento por defecto es que, al enviar paquetes multicast, puede haber también una aplicación multicast local escuchando en el mismo host que envía, así como en algún lugar de la red. Esta aplicación local también necesita recibir los paquetes multicast.
Podemos ver este ciclo local multicast en nuestra salida de ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de datos
64 bytes desde fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tiempo=0.106 ms
64 bytes desde fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tiempo=0.453 ms (¡DUP!)
...La primera y más rápida respuesta (0.106 ms frente a 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 ~]$Utilidad ping proporciona una forma de suprimir la retroalimentación local del bucle multicast utilizando el parámetro -L. Si enviamos un ping al multicast de todos los nodos con este flag, entonces las respuestas se limitan a nodos remotos. No recibimos respuesta de la dirección Link-Local de la interfaz del emisor.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de datos
64 bytes desde fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tiempo=0.383 ms
64 bytes desde fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tiempo=0.467 ms (¡DUP!)
...Ping de Direcciones Link-Local
Como puedes adivinar, las direcciones Link-Local unicaste no proporcionan suficiente información por sí solas para indicar qué interfaz utilizar para alcanzarlas. Al igual que con el ping multicast all-nodes, necesitamos especificar también la interfaz como un parámetro de línea de comandos. ping o el ID de zona con la dirección al hacer ping a las direcciones Link-Local.
Esta vez podemos usar — el número de paquetes, después de los cuales, para limitar el número de paquetes y respuestas enviados y recibidos ping, dado que estamos realizando un ping unicaste.
[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 bytes de datos
64 bytes desde fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tiempo=0.395 ms
--- estadísticas de ping fe80::f31c:ccff:fe26:a6d9%enp3s2 ---
1 paquetes transmitidos, 1 recibido, 0% de pérdida de paquetes, tiempo 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$¿Hacer ping a (todos) los demás direcciones IPv6?
En este artículo, hemos visto cómo hacer ping a todos los nodos IPv6 en el canal, utilizando la dirección multicast IPv6 all-nodes. ff02::1También hemos visto cómo especificar qué interfaz usar con la dirección multicast IPv6 all-nodes, ya que la dirección por sí sola no puede proporcionar esta información. Utilizamos ya sea un parámetro de línea de comandos ping, o especificamos la interfaz a través del sufijo %.
Luego aprendimos sobre las direcciones Link-Local unicaste, que son las direcciones utilizadas para responder a las solicitudes de eco multicast all-nodes ICMPv6.
También vimos cómo los paquetes multicast regresan al nodo emisor por defecto y cómo desactivar esto para la utilidad ping.
Finalmente, hicimos ping a una única dirección Link-Local, utilizando el sufijo %, ya que las direcciones Link-Local por sí solas tampoco proporcionan información sobre la interfaz de origen.
¿Qué tal hacer ping a todos los demás nodos y obtener sus direcciones unicaste globales (GUA) (es decir, sus direcciones públicas en Internet) o sus direcciones unicaste locales únicas (ULA)? Lo discutiremos en el próximo artículo del blog.
Eso es todo.
Para conocer más sobre nuestro curso, visita.
Fuente: habr.com
