Restam alguns dias até o início de um novo fluxo no curso "Engenheiro de Rede" da OTUS. Nesse sentido, queremos compartilhar com você a tradução de material útil sobre o tema.
Uma série de artigos de blog sobre dicas e truques para solução de problemas de ping do IPv6 (solicitação de eco ICMPv6 / resposta de eco)Observe que eu uso o Linux (especificamente o Fedora 31), mas a sintaxe do comando ping para outros sistemas operacionais, espero deve ser muito parecido.Faça ping em todos os hosts IPv6 no canal
A primeira e mais fácil dica é executar ping em todos os hosts IPv6 no canal.O IPv6 usa endereços multicast para todos os tipos de comunicação um para muitos. Não há endereços IPv6 de transmissão (ou transmissão). Isso distingue o IPv6 do IPv4, onde existem vários tipos de endereços de broadcast, por exemplo, endereço de "broadcast limitado" 255.255.255.255 [RFC1122].No entanto, há um endereço IPv6 de “todos os nós multicast”, portanto, usá-lo-emos para executar ping em todos os nós IPv6 no canal. (Na verdade, um endereço de "difusão" é 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 endereço multicast está incluído nos endereços de difusão Ethernet no nível do link).Endereço IPv6 multicast de todos os nós para o canal: ff02::1. ffindica um endereço IPv6 multicast. O próximo 0 faz parte do sinalizador com bits não definidos.Além disso, 2define a área 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 na qual os pacotes multicast são permitidos. Quando o pacote atingir o limite do escopo especificado, o pacote deverá ser descartado, independentemente de o campo Contagem de saltos ser diferente de zero. Obviamente, se o contador de conversão atingir zero antes de atingir a borda especificada do grupo multicast, ele também será redefinido imediatamente. Aqui está uma lista completa do escopo multicast IPv6.Por fim, ::1indica o grupo multicast de todos os nós.Sobre o endereço ff02::1, note-se que é ambíguo. Em um host IPv6 com várias interfaces, como um roteador ou host com hospedagem múltipla, ff02::1não há nada no endereço em que você possa especificar para qual interface enviar pings de ICMPv6 ou aguardar pings de ICMPv6 quando eles chegarem. ff02::1válido e pode ser usado em qualquer uma das interfaces e canais conectados ao nó de multi-interface.Portanto, quando fazemos ping em todos os nós do IPv6 no canal, também precisamos informar de alguma forma ao utilitário pingdo IPv6 qual interface usar.Definição da interface - opção de linha de comando
Como já vimos, o endereço multicast de todos os nós que queremos usar - ff02::1- não fornece nenhuma informação sobre para qual interface enviar e receber pacotes de solicitação e resposta de eco ICMPv6.Então, como especificamos a interface que será usada para o espaço de endereço multicast ou endereços Link-Local unicast?A primeira e mais óbvia maneira é fornecê-lo como um parâmetro para o aplicativo que usamos.Para o utilitário, pingnós fornecê-la através da opção -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 esse ping multicast de todos os nós, recebemos respostas de 6 nós IPv6. As respostas vieram dos endereços IPv6 do Link-Local do host, começando com o prefixo fe80::/10.Para pingimpedir que as solicitações de eco do ICMPv6 continuem infinitamente até a abortar, geralmente especificamos o número de pacotes a serem enviados pela opção -c. No entanto, isso também impede que o ping receba e exiba mais de uma resposta de eco ICMPv6 ao enviar uma solicitação de eco ICMPv6 multicast. Em vez disso, usamos a opção -w para indicar que o ping deve ser concluído após 1 segundo, independentemente de quantos pings ou pings do ICMPv6 foram enviados ou recebidos.Outra coisa a prestar atenção é (DUP!) conclusão sobre a segunda e as respostas subsequentes. Esses pacotes são identificados como duplicados da resposta, porque eles têm o mesmo valor de sequência ICMP que os pings individuais do ICMPv6 que foram enviados primeiro. Eles aparecem porque a solicitação de eco multicast ICMPv6 resulta em várias respostas unicast individuais. O número de duplicatas também é indicado no resumo das estatísticas.Definição da interface - ID da zona
Outra maneira de fornecer uma interface a ser usada é parte do parâmetro de endereço IPv6.Podemos ver um exemplo disso na saída ping, em que os endereços dos nós IPv6 respondentes também possuem um sufixo %enp3s2, por exemplo:64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
Este método de definição de interfaces é formalmente descrito em [RFC4007], "Arquitetura com endereços IPv6 especificados". Embora eles geralmente sejam chamados de interface do sistema operacional, eles realmente definem algo mais geral - uma "zona" ou um "escopo".A razão para ter zonas mais gerais ou zonas de escopo é porque, como mencionado em [RFC4007], um host IPv6 pode ter várias interfaces IPv6 diferentes conectadas ao mesmo canal. Essas interfaces são membros da mesma zona.Deve ser possível agrupar várias interfaces dentro da zona sob o sistema operacional; Atualmente, não sei se isso é possível no Linux e como fazê-lo.Usando o sufixo %<zone_id>, podemos remover o parâmetro da linha 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 ~]$
Respostas do endereço local do link
Deste ping multicast para todos os nós, recebemos um total de 6 respostas únicas.Essas respostas vieram dos endereços de host IPv6 local de link de difusão ponto a ponto. Por exemplo, aqui está a primeira resposta:64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
Endereços IPv6 locais de link unicast necessários em todas as interfaces ativadas para IPv6 [RFC4291], arquitetura de endereçamento IP versão 6. A razão para isso é que o host IPv6 sempre possui automaticamente um endereço IPv6 unicast, que pode ser usado, pelo menos para se comunicar com outros hosts por meio de seus canais diretamente conectados. Isso inclui a comunicação com aplicativos de outros hosts por meio de endereços de host do Link-Local.Isso simplifica o desenvolvimento e a implementação de protocolos como o IPv6 Neighbor Discovery e OSPFv3. Ele também permite que aplicativos de usuário final nos hosts se comuniquem pelo canal sem exigir nenhuma outra infraestrutura IPv6 de suporte no canal. A comunicação direta entre hosts IPv6 conectados não requer um roteador IPv6 ou um servidor DHCPv6 em conexão.Os endereços locais de link começam com um prefixo de 10 bits fe80, seguido por 54 bits zero, seguido por um identificador de interface de 64 bits (IID). Na primeira resposta acima 2392:6213:a15b:66ff, esse é um IID de 64 bits.Multicast em loop
Por padrão, os pacotes multicast são retornados internamente para o nó que os envia. Isso acontece para os endereços IPv6 e IPv4.O motivo desse comportamento padrão é que, ao enviar pacotes multicast, também pode haver um aplicativo multicast local de escuta em execução no próprio host de envio, bem como em algum lugar da rede. Esse aplicativo local também deve receber pacotes multicast.Podemos ver esse loop local multicast em nossa saída 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!)
...
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 própria interface enp3s2.[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$
O utilitário pingfornece uma maneira de suprimir o feedback local da correspondência multicast usando um parâmetro -L. Se enviarmos um ping multicast para todos os nós com esse sinalizador, as respostas serão limitadas aos nós remotos. Não recebemos uma 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 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!)
...
Endereço local de link de ping
Como você pode imaginar, os endereços unicast do Link-Local também não fornecem informações suficientes para indicar qual interface usar para alcançá-los. Como no caso do ping multicast de todos os nós, também precisamos especificar a interface como um parâmetro de linha de comando pingou um ID de zona com o endereço ao executar ping nos endereços do Link-Local.Desta vez, podemos usar -cpara limitar o número de pacotes e respostas enviadas e recebidas ping, já que executamos 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 (todos) outros endereços IPv6?
Neste artigo, vimos como executar ping em todos os nós IPv6 em um canal usando um endereço IPv6 multicast para todos os nós ff02::1. Também vimos como especificar qual interface usar com o endereço IPv6 multicast de todos os nós, já que o endereço por si só não pode fornecer essas informações. Usamos um parâmetro de linha de comando pingou especificamos uma interface através de um sufixo %<zone_id>.Em seguida, aprendemos sobre endereços de Link-Local unicast, que são os endereços usados para responder às solicitações de eco ICMPv6 de difusão seletiva de todos os nós.Também vimos como os pacotes multicast retornam ao host de envio por padrão e como desabilitar isso no utilitário ping.Por fim, efetuamos ping em um único endereço Link-Local usando o sufixo%<zone_id>já que os endereços Link-Local sozinhos não fornecem informações sobre a interface de saída.Então, o que dizer de executar ping em todos os outros nós e recuperar seus endereços Unicast globais (GUAs) (ou seja, seus endereços públicos da Internet) ou seus endereços Unicast locais exclusivos (ULAs)? Vamos abordar isso no próximo post do blog.Isso é tudo.Você pode descobrir mais sobre o nosso curso no dia aberto .