Faltam alguns dias para o início de um novo fluxo na taxa de OTUS. Nesse sentido, gostaríamos de compartilhar com vocês uma tradução de material útil sobre o tema.
Uma série de postagens de blog sobre dicas e truques para solucionar problemas de ping IPv6 (solicitação de eco ICMPv6/resposta de eco)
Observe que estou usando Linux (especificamente Fedora 31), mas espero que a sintaxe do comando ping para outros sistemas operacionais seja muito semelhante.
Faça ping em todos os nós IPv6 em um canal
A primeira e mais simples dica é fazer ping em todos os nós IPv6 do link.
O IPv6 usa endereços multicast para todos os tipos de comunicações um-para-muitos. Não há endereços IPv6 de difusão (ou difusão). Isto distingue o IPv6 do IPv4, onde existem vários tipos de endereços de broadcast, por exemplo, o endereço de “transmissão limitada” 255.255.255.255 [RFC1122].
No entanto, existe um endereço IPv6 “multicast para todos os nós”, portanto, usaremos isso para executar ping em todos os nós IPv6 no link. (Um endereço de "broadcast" é na verdade apenas um endereço multicast especialmente nomeado, que é um grupo multicast que inclui todos os nós. Observe que, por exemplo, o bit de endereço "grupo" ou multicast está ativado em endereços de transmissão Ethernet na camada de enlace ).
Endereço IPv6 multicast de todos os nós para o canal: ff02::1. ff denota um endereço IPv6 multicast. O próximo 0 é a parte do sinalizador com bits não definidos.
Próximo 2 define a área de um grupo multicast. Ao contrário dos endereços IPv4 multicast, os endereços IPv6 multicast têm um escopo. O valor do escopo indica a parte da rede pela qual um pacote multicast pode ser encaminhado. Quando um pacote atinge o limite do escopo especificado, o pacote deve ser descartado, independentemente de seu campo Hop Count ser diferente de zero. Obviamente, se a contagem de saltos chegar a zero antes de atingir o limite do grupo multicast especificado, ela também será redefinida imediatamente. Aqui está uma lista completa do escopo multicast IPv6.
Por fim, o ::1 especifica um grupo multicast de todos os nós.
Sobre o endereço ff02::1 Deve-se notar que é ambíguo. Em um host IPv6 com múltiplas interfaces, como um roteador ou host multihomed, o endereço ff02::1 não há nada onde você possa especificar para qual interface enviar solicitações de eco ICMPv6 ou esperar receber respostas de eco ICMPv6 quando elas chegarem. ff02::1 é válido e pode ser usado em qualquer uma das interfaces e canais anexados ao nó multiinterface.
Então, quando executamos ping em todos os nós IPv6 em um link, precisamos de alguma forma também informar ao utilitário ping para IPv6, qual interface usar.
Definindo Interfaces - 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 qual interface enviar e receber pacotes de solicitação de eco e resposta de eco ICMPv6.
Então, como especificamos a interface a ser usada para o espaço de endereço multicast ou espaço de endereço Link-Local unicast?
A primeira e mais óbvia maneira é fornecê-lo como parâmetro para a aplicação que estamos usando.
Para utilidade ping nós fornecemos 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 para todos os nós, recebemos respostas de 6 nós IPv6. As respostas vieram de endereços de nós Link-Local IPv6, começando com o prefixo fe80::/10.
Que ping não continua a enviar solicitações de eco ICMPv6 indefinidamente até que o interrompamos, geralmente especificamos o número de pacotes a serem enviados por meio da opção -c. No entanto, isso também impede que o ping aceite 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 especificar que o ping deve ser concluído após 1 segundo, independentemente de quantas solicitações de eco ICMPv6 ou respostas de eco foram enviadas ou recebidas.
Outra coisa a se prestar atenção é (DUP!) saída na segunda resposta e nas subsequentes. Esses pacotes são identificados como respostas duplicadas porque possuem o mesmo valor de sequência ICMP que as solicitações de eco ICMPv6 individuais que foram enviadas em primeiro lugar. Eles aparecem porque uma solicitação de eco multicast ICMPv6 resulta em múltiplas respostas unicast individuais. O número de duplicatas também é indicado no resumo das estatísticas.
Definindo Interfaces – ID da Zona
Outra forma de expor uma interface para uso é como parte de um parâmetro de endereço IPv6.
Podemos ver um exemplo disso na saída do ping, onde os endereços dos hosts IPv6 que respondem também possuem o sufixo %enp3s2, Por exemplo:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msEste método de especificação de interfaces é descrito formalmente em [RFC4007], "IPv6 Defined Address Architecture". Embora geralmente sejam chamadas de interface do sistema operacional, elas na verdade definem algo mais geral – uma “zona” ou “escopo”.
A razão para ter zonas mais gerais ou zonas de escopo é que, como mencionado em [RFC4007], um nó IPv6 pode ter diversas interfaces IPv6 diferentes conectadas ao mesmo canal. Essas interfaces são membros da mesma zona.
Deve ser possível agrupar múltiplas interfaces dentro de uma zona no sistema operacional; Atualmente não sei se isso é possível no Linux ou como fazê-lo.
Usando o sufixo %<zone_id>, podemos remover a opção de 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 de endereço local de link
Desse ping multicast de todos os nós, recebemos um total de 6 respostas exclusivas.
Essas respostas vieram de endereços de host Unicast Link-Local IPv6. Por exemplo, aqui está a primeira resposta:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msOs endereços IPv6 Unicast Link-Local são necessários em todas as interfaces habilitadas para IPv6 [RFC4291], “Arquitetura de endereçamento IP versão 6”. A razão para isso é que um nó IPv6 sempre possui automaticamente um endereço IPv6 unicast, que pode pelo menos usar para se comunicar com outros nós em seus links diretamente conectados. Isso inclui a comunicação com aplicativos em outros hosts por meio de endereços de host Link-Local.
Isso simplifica o projeto e a implementação de protocolos como IPv6 Neighbor Discovery e OSPFv3. Ele também permite que aplicativos de usuários finais em hosts se comuniquem pelo canal sem exigir qualquer outra infraestrutura IPv6 de suporte no canal. A comunicação direta entre hosts IPv6 conectados não requer um roteador IPv6 ou servidor DHCPv6 na conexão.
Os endereços Link-Local começam com um prefixo de 10 bits fe80, seguido por 54 zero bits e, em seguida, um identificador de interface (IID) de 64 bits. Na primeira resposta acima 2392:6213:a15b:66ff é um IID de 64 bits.
Multicast em loop
Por padrão, os pacotes multicast são retornados internamente ao nó que os enviou. Isso acontece tanto para endereçamento IPv6 quanto IPv4.
A razão para esse comportamento padrão é que quando pacotes multicast são enviados, também pode haver um aplicativo multicast local escutando em execução no próprio host remetente, bem como em algum lugar da rede. Esta aplicação 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 versus 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 ~]$Utilitário ping fornece uma maneira de suprimir feedback multicast local usando o 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 de envio.
[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ços locais de link de ping
Como você pode imaginar, os endereços Link-Local unicast por si só também não fornecem informações suficientes para indicar qual interface usar para alcançá-los. Tal como acontece com o ping multicast de todos os nós, também precisamos especificar a interface como um parâmetro de linha de comando ping ou ID de zona com endereço ao executar ping em endereços Link-Local.
Desta vez podemos usar -cpara limitar o número de pacotes e respostas enviados e recebidos ping, já que estamos executando 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) os outros endereços IPv6?
Neste artigo, vimos como fazer 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 um endereço IPv6 multicast para todos os nós, já que o próprio endereço não pode fornecer essa informação. Usamos a opção de linha de comando pingou especificou a interface usando o sufixo %<zone_id>.
Em seguida, aprendemos sobre endereços Link-Local unicast, que são endereços usados para responder a solicitações de eco ICMPv6 multicast de todos os nós.
Também vimos como os pacotes multicast são retornados ao nó remetente por padrão e como desabilitar isso para o utilitário ping.
Finalmente, executamos ping em um único endereço Link-Local usando o sufixo %<zone_id>, uma vez que os próprios endereços Link-Local também não fornecem informações sobre a interface de saída.
Então, que tal executar ping em todos os outros nós e obter seus endereços unicast globais (GUAs) (ou seja, seus endereços públicos na Internet) ou seus endereços unicast locais exclusivos (ULAs)? Veremos isso na próxima postagem do blog.
Isso é tudo.
Você pode saber mais sobre nosso curso em.
Fonte: habr.com