Restam apenas alguns dias até o início do novo fluxo do curso da OTUS. Com isso, queremos compartilhar com você a tradução de um material útil sobre o tema.
Série de artigos no blog dedicados a dicas e recomendações para resolver problemas relacionados ao ping do IPv6 (ICMPv6 Echo Request/Echo Reply)
Observe que estou usando o Linux (em particular, o Fedora 31), no entanto, a sintaxe do comando ping para outros sistemas operacionais deve ser muito semelhante, espero.
Ping de todos os nós IPv6 no canal
A primeira e mais simples dica é pingar todos os nós IPv6 na rede.
O IPv6 utiliza endereços multicast para todos os tipos de comunicação 'um para muitos'. Não existem endereços de broadcast (ou de difusão) no IPv6. Isso distingue o IPv6 do IPv4, onde existem vários tipos de endereços de broadcast, por exemplo, o endereço de 'broadcast limitado' 255.255.255.255 [RFC1122].
No entanto, existe um endereço IPv6 de multicast 'all-nodes' (multicast de todos os nós), então usaremos isso para pingar todos os nós IPv6 na rede. (O endereço 'broadcast' é na verdade apenas um endereço multicast especialmente nomeado, que é um grupo de multicast que inclui todos os nós. Observe que, por exemplo, o bit de 'grupo' ou do endereço multicast está incluído nos endereços de broadcast Ethernet na camada de enlace).
Endereço IPv6 multicast all-nodes para a rede: ff02::1. ff indica um endereço multicast IPv6. O próximo 0 é a parte do flag com os bits não definidos.
Em seguida 2 define o escopo do grupo multicast. Ao contrário dos endereços multicast IPv4, os endereços multicast IPv6 têm escopo. O valor do escopo indica a parte da rede pela qual o pacote multicast pode ser roteado. Assim que o pacote atinge a fronteira do escopo especificado, ele deve ser descartado, independentemente de o campo de contador de saltos (Hop Count) ser não zero. Naturalmente, se o contador de saltos alcançar zero antes de atingir a fronteira do grupo multicast especificado, ele também é imediatamente descartado. Aqui está a lista completa dos escopos multicast do IPv6.
Finalmente, ::1 indica o grupo all-nodes multicast.
Sobre o endereço ff02::1 deve ser observado que ele é ambíguo. Em um nó IPv6 com múltiplas interfaces, como um roteador ou um host multi-homed, o endereço ff02::1 não há nada onde se possa indicar a qual interface enviar pacotes de eco ICMPv6 ou esperar receber respostas de eco ICMPv6 quando elas chegam. ff02::1 é válido e pode ser usado em qualquer uma das interfaces e canais anexados a um nó multiface.
Portanto, quando fazemos ping em todos os nós IPv6 no canal, precisamos informar à ferramenta de alguma forma ping para IPv6, qual interface usar.
A definição de interfaces é um parâmetro da linha de comando
Como já vimos, o endereço multicast all-nodes que queremos usar — ff02::1 — não fornece nenhuma informação sobre qual interface enviar e receber pacotes de eco e respostas de eco ICMPv6.
Então, como podemos especificar a interface que será usada para o espaço de endereços multicast ou endereços Link-Local unicast?
A primeira e mais óbvia maneira é fornecê-la como um parâmetro para o aplicativo que estamos usando.
Para a ferramenta ping nós a fornecemos através da opção -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Aviso: o endereço de origem pode ser selecionado em um dispositivo diferente de: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 bytes de dados
64 bytes de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes de fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes de fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes de fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes de fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- estatísticas de ping ff02::1 ---
1 pacotes transmitidos, 1 recebido, +5 duplicatas, 0% de perda de pacotes, tempo 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Com esse ping multicast all-nodes, recebemos respostas de 6 nós IPv6. As respostas foram recebidas de endereços IPv6 Link-Local, começando com o prefixo fe80::/10.
Para ping não continuamos enviando pacotes de eco ICMPv6 indefinidamente até que o interrompêssemos, normalmente especificamos o número de pacotes a serem enviados através da opção -c. No entanto, isso também não permite ao ping aceitar e exibir mais de uma resposta de eco ICMPv6 ao enviar um pacote de eco ICMPv6 multicast. Em vez disso, usamos o parâmetro -w para indicar que o ping deve terminar em 1 segundo, independentemente de quantos pacotes de eco ou respostas de eco ICMPv6 foram enviados ou recebidos.
Outra coisa a observar é (DUP!) saída nas respostas subsequentes. Estes pacotes são identificados como respostas duplicadas, pois eles possuem o mesmo valor de sequência ICMP que os echos ICMPv6 enviados primeiro. Eles aparecem porque o eco de multicast ICMPv6 resulta em várias respostas unicast individuais. O número de duplicatas também é indicado no resumo das estatísticas.
Definição de interfaces — Zone ID
Outra forma de fornecer interfaces para uso é por meio de um parâmetro do endereço IPv6.
Podemos observar um exemplo disso na saída do ping, onde os endereços dos nós IPv6 que respondem também possuem um sufixo %enp3s2, por exemplo:
64 bytes de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msEsse método de atribuição de interfaces é formalmente descrito em [RFC4007], "Arquitetura com endereços IPv6 atribuídos". Embora geralmente sejam chamados de interface do sistema operacional, eles realmente definem algo mais geral — "zona" ou "escopo".
A razão para a existência de zonas mais gerais ou zonas de escopo é que, como mencionado em [RFC4007], um nó IPv6 pode ter várias interfaces IPv6 conectadas ao mesmo canal. Essas interfaces são membros de uma mesma zona.
Deve ser possível agrupar várias interfaces dentro de uma zona sob o sistema operacional; atualmente, não sei se isso é possível no Linux e como fazer.
Usando o sufixo %, podemos remover o parâmetro de linha de comando -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de dados
64 bytes de fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes de fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes de fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes de fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes de fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes de fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- estatísticas de ping ff02::1%enp3s2 ---
1 pacotes transmitidos, 1 recebido, +7 duplicatas, 0% perda de pacotes, tempo 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Respostas de endereços Link-Local
Dessa execução do ping multicast all-nodes, recebemos um total de 6 respostas únicas.
Essas respostas vieram de endereços Link-Local unicast dos nós IPv6. Por exemplo, aqui está a primeira resposta:
64 bytes de fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msEndereços IPv6 Link-Local são necessários em todas as interfaces que suportam IPv6 [RFC4291], "Arquitetura de Endereçamento da Versão 6 do IP". A razão para isso é que um nó IPv6 sempre possui automaticamente um endereço IPv6 unicast, que pode usar, pelo menos, para se comunicar com outros nós através de suas conexões diretas. Isso inclui a comunicação com aplicativos de outros hosts através dos endereços Link-Local dos hosts.
Isso simplifica o desenvolvimento e a implementação de protocolos como a Descoberta de Vizinhos IPv6 e OSPFv3. Também permite que aplicativos finais em hosts troquem dados diretamente entre si, sem a necessidade de qualquer outra infraestrutura de suporte IPv6 no canal. Para a comunicação direta entre hosts conectados, um roteador IPv6 ou servidor DHCPv6 não é necessário.
Os endereços Link-Local começam com um prefixo de 10 bits fe80, seguido por 54 bits zerados e, em seguida, um identificador de interface de 64 bits (IID). Na primeira resposta acima, 2392:6213:a15b:66ff — é o IID de 64 bits.
Multicast Loops
Por padrão, pacotes multicast são retornados internamente ao nó que os enviou. Isso ocorre tanto para endereços IPv6 quanto IPv4.
A razão desse comportamento padrão é que, ao enviar pacotes multicast, pode haver também um aplicativo local de multicast ouvindo no próprio host do remetente, assim como em algum ponto da rede. Este aplicativo local também deve receber os pacotes multicast.
Podemos ver esse ciclo local multicast em nossa saída de ping:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de dados
64 bytes de fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 tempo=0.106 ms
64 bytes de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tempo=0.453 ms (DUP!)
...A primeira e mais rápida resposta (0,106 ms em comparação com 0,453 ms) vem do endereço Link-Local configurado na interface enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Utilitário ping fornece uma maneira de suprimir o feedback local de multicast usando a opção -L. Se enviarmos um ping multicast all-nodes com essa flag, as respostas serão limitadas a nós remotos. Não receberemos resposta do endereço Link-Local da interface do remetente.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 bytes de dados
64 bytes de fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 tempo=0.383 ms
64 bytes de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 tempo=0.467 ms (DUP!)
...Ping do Endereço Link-Local
Como você pode imaginar, os endereços Link-Local unicast não fornecem por si só informações suficientes para indicar qual interface usar para alcançá-los. Assim como no ping multicast all-nodes, também precisamos especificar a interface como um parâmetro de linha de comando. ping ou o ID da zona com o endereço ao fazer ping em endereços Link-Local.
Desta vez, podemos usar -c, para limitar o número de pacotes e respostas enviados e recebidos ping, já que estamos realizando um 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 bytes de dados
64 bytes de fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- Estatísticas de ping do fe80::f31c:ccff:fe26:a6d9%enp3s2 ---
1 pacotes transmitidos, 1 recebido, 0% de perda de pacotes, tempo 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Pingar (todos) os outros endereços IPv6?
Neste artigo, vimos como fazer ping em todos os nós IPv6 na rede, usando o endereço multicast all-nodes IPv6. ff02::1Também aprendemos como especificar qual interface usar com o endereço multicast all-nodes IPv6, já que o endereço por si só não pode fornecer essas informações. Usamos ou o parâmetro de linha de comando ping, ou especificamos a interface através do sufixo %.
Depois, aprendemos sobre os endereços Link-Local unicast, que são os endereços usados para respostas a solicitações de eco multicast all-nodes ICMPv6.
Também vimos como pacotes multicast retornam ao nó emissor por padrão e como desativar isso para o utilitário ping.
Finalmente, fizemos ping em um único endereço Link-Local, usando o sufixo %, uma vez que os endereços Link-Local por si só também não fornecem informações sobre a interface de saída.
E quanto a fazer ping em todos os outros nós e obter seus endereços unicast globais (GUA) (ou seja, seus endereços públicos na internet) ou seus endereços unicast locais únicos (ULA)? Vamos abordar isso no próximo artigo do blog.
E isso é tudo.
Saiba mais sobre nosso curso em.
Fonte: habr.com
