Faltam apenas alguns dias para o início de uma nova turma do curso. Da OTUS. A este respeito, gostaríamos de compartilhar com vocês a tradução de algum material útil sobre este tema.
Uma série de posts no blog com dicas e truques para solucionar problemas de ping IPv6 (Solicitação de Eco ICMPv6/Resposta de Eco).
Observe que estou usando Linux (especificamente o Fedora 31), porém a sintaxe do comando ping para outros sistemas operacionais deve ser muito semelhante.
Faça ping em todos os nós IPv6 em um canal
O primeiro e mais simples conselho é pingar todos os nós IPv6 no canal.
O IPv6 usa endereços multicast para todos os tipos de comunicação de um para muitos. Não existem endereços de broadcast no IPv6. Isso distingue o IPv6 do IPv4, que possui vários tipos de endereços de broadcast, como o endereço de "broadcast limitado" 255.255.255.255 [RFC1122].
No entanto, existe um endereço IPv6 "multicast para todos os nós", então o usaremos para pingar todos os nós IPv6 no link. (O endereço "broadcast" é, na verdade, apenas um endereço multicast com nome específico, que é um grupo multicast que inclui todos os nós. Observe que, por exemplo, o bit de "grupo" ou endereço multicast é habilitado nos endereços de broadcast Ethernet na camada de enlace.)
Endereço IPv6 multicast para todos os nós do canal: ff02::1. ff denota um endereço IPv6 multicast. O 0 seguinte representa a porção do sinalizador com bits não definidos.
Próximo 2 Define o escopo de um grupo multicast. Ao contrário dos endereços multicast IPv4, os endereços multicast IPv6 possuem um escopo. O valor do escopo especifica a porção da rede sobre a qual um pacote multicast pode ser encaminhado. Assim que um pacote atinge o limite do escopo especificado, ele deve ser descartado, independentemente de o campo "Contagem de Saltos" ser diferente de zero. Obviamente, se a Contagem de Saltos chegar a zero antes de atingir o limite do grupo multicast especificado, o pacote também será descartado imediatamente. Aqui está uma lista completa dos escopos multicast IPv6.
Por fim, o ::1 Especifica um grupo multicast para todos os nós.
Sobre o endereço ff02::1 É importante notar que isso é ambíguo. Em um nó IPv6 com múltiplas interfaces, como um roteador ou um host com múltiplas interfaces de rede, o endereço ff02::1 Não há nada que especifique para qual interface enviar solicitações de eco ICMPv6 ou para qual interface esperar receber respostas de eco ICMPv6 quando elas chegarem. ff02::1 É válido e pode ser usado em qualquer uma das interfaces e canais conectados ao nó multi-interface.
Portanto, quando enviamos pings para todos os nós IPv6 no canal, também precisamos informar de alguma forma o utilitário. ping Para IPv6, qual interface usar?
Definição de interfaces - Opção de linha de comando
Como já vimos, o endereço multicast para todos os nós que queremos usar é ff02::1 — não fornece nenhuma informação sobre qual interface usar para enviar e receber pacotes de solicitação e resposta de eco ICMPv6.
Então, como especificamos a interface a ser usada para o espaço de endereços multicast ou para endereços unicast Link-Local?
A primeira e mais óbvia maneira é fornecê-lo como um parâmetro para o aplicativo que estamos usando.
Para o serviço público ping Nós oferecemos isso 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 este ping multicast para todos os nós, recebemos respostas de 6 nós IPv6. As respostas vieram dos endereços IPv6 link-local dos nós, começando com o prefixo fe80::/10.
Que ping Para impedir que o ping continue enviando solicitações de eco ICMPv6 indefinidamente até que o encerremos, normalmente especificamos o número de pacotes a serem enviados usando a 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 especificar que o ping deve ser encerrado após 1 segundo, independentemente de quantas solicitações de eco ICMPv6 ou respostas de eco foram enviadas ou recebidas.
Outro ponto a observar é (DUP!) saída na segunda e nas respostas 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 enviadas inicialmente. Isso ocorre porque uma solicitação de eco ICMPv6 multicast resulta em múltiplas respostas unicast individuais. O número de duplicatas também é indicado no resumo estatístico.
Definição de interface - 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 têm 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 é formalmente descrito em [RFC4007], "Arquitetura específica de endereço IPv6". Embora seja comumente referido como uma interface de sistema operacional, na verdade define algo mais geral — uma "zona" ou "escopo".
A razão para ter zonas ou zonas de escopo mais gerais é que, como mencionado em [RFC4007], um nó IPv6 pode ter várias interfaces IPv6 diferentes conectadas ao mesmo link. Essas interfaces são membros da mesma zona.
Deveria ser possível agrupar várias interfaces dentro de uma zona em um sistema operacional; não sei neste momento se isso é possível no [sistema operacional em questão]. Linux e como fazer isso.
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 de endereço local de link
A partir desse ping multicast para todos os nós, recebemos um total de 6 respostas únicas.
Essas respostas vieram dos endereços unicast Link-Local dos nós 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 msEndereços IPv6 unicast link-local são necessários em todas as interfaces habilitadas para IPv6 [RFC4291], "Arquitetura de Endereçamento IPv6". Isso ocorre porque um nó IPv6 sempre possui automaticamente um endereço IPv6 unicast, que pode ser usado para se comunicar com outros nós por meio de seus links diretamente conectados. Isso inclui a comunicação com aplicativos em outros hosts por meio dos endereços link-local desses hosts.
Isso simplifica o desenvolvimento e a implementação de protocolos como IPv6 Neighbor Discovery e OSPFv3. Também permite que aplicativos de usuário final em hosts troquem dados pela conexão sem a necessidade de qualquer outra infraestrutura habilitada para IPv6 na mesma. A comunicação direta entre hosts IPv6 conectados não requer um roteador IPv6 ou um servidor DHCPv6.
Os endereços locais de link começam com um prefixo de 10 bits. fe80, seguido por 54 bits zero 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 devolvidos internamente ao nó que os enviou. Isso ocorre tanto para endereçamento IPv6 quanto IPv4.
O motivo desse comportamento padrão é que, ao enviar pacotes multicast, pode haver também um aplicativo multicast local em execução no próprio host remetente, bem como em algum outro lugar na rede. Esse aplicativo local também deve receber pacotes multicast.
Podemos observar esse loop multicast local na saída do nosso 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 ~]$Utilitário ping fornece uma maneira de suprimir o feedback multicast local usando o parâmetro -LSe enviarmos um ping multicast para todos os nós com essa flag, as respostas serão limitadas aos nós remotos. Não receberemos 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!)
...Link de ping - Endereços locais
Como você deve imaginar, os endereços unicast Link-Local por si só não fornecem informações suficientes para especificar qual interface usar para alcançá-los. Assim como no ping multicast entre todos os nós, também precisamos especificar a interface como um parâmetro de linha de comando. ping ou ID da zona com endereço ao pingar endereços Link-Local.
Desta vez podemos usar -cpara limitar o número de pacotes e respostas enviados e recebidos. ping, visto 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 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 para todos os outros endereços IPv6?
Neste artigo, vimos como pingar todos os nós IPv6 em um canal usando o endereço IPv6 multicast de todos os nós. ff02::1També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 fornece essa informação. Usamos um parâmetro de linha de comando. pingou especificou a interface por meio de um sufixo. %<zone_id>.
Em seguida, aprendemos sobre endereços unicast Link-Local, que são os 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 devolvidos ao host remetente por padrão e como desativar isso para o utilitário. ping.
Finalmente, enviamos um ping para um único endereço Link-Local usando o sufixo. %<zone_id>, visto 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 enviar pings para todos os outros nós e obter seus endereços unicast globais (GUAs) (ou seja, seus endereços publicamente acessíveis na Internet) ou seus endereços unicast locais exclusivos (ULAs)? Abordaremos isso na próxima postagem do blog.
Isso é tudo.
Você pode encontrar mais informações sobre o nosso curso em.
Fonte: habr.com
