IPv6 funciona somente após o ping para a caixa de roteamento

Question

Situação:

Existe um roteador somente para ipv4 em nossa rede e cada computador está conectado a ele (wifi ou cabo). Um servidor com ipv4 e ipv6 também está conectado a este roteador. O servidor foi configurado com tunnelbrokers para tunelamento 6to4 e radvd. Clientes na rede têm o prefixo certo e podem pingar uns aos outros através do ipv6. Mas eles não podem pingar para a internet até que eles primeiro ping Server (aquele com o túnel). Eu encontrei em algum lugar que é um problema icmp, mas não consegui encontrar uma solução.

O problema é que o roteador é somente ipv4?

• servidor e clientes executam linux
• o roteador executa dd-wrt sem suporte a ipv6: (

Ping tente:

standa@standa-laptop:~$ ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::69) 56 data bytes
^C
--- ipv6.google.com ping statistics ---
29 packets transmitted, 0 received, 100% packet loss, time 28223ms

standa@standa-laptop:~$ ping6 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478
PING 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478(2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478) 56 data bytes
64 bytes from 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478: icmp_seq=1 ttl=64 time=3.55 ms
64 bytes from 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478: icmp_seq=2 ttl=64 time=0.311 ms
64 bytes from 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478: icmp_seq=3 ttl=64 time=0.269 ms
64 bytes from 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478: icmp_seq=4 ttl=64 time=0.292 ms
^C
--- 2001:470:XXXX:XXXX:21c:c0ff:fe2b:6478 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.269/1.107/3.559/1.415 ms
standa@standa-laptop:~$ ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::69) 56 data bytes
64 bytes from 2a00:1450:8007::69: icmp_seq=1 ttl=57 time=20.7 ms
64 bytes from 2a00:1450:8007::69: icmp_seq=2 ttl=57 time=20.2 ms
64 bytes from 2a00:1450:8007::69: icmp_seq=3 ttl=57 time=23.4 ms
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 20.267/21.479/23.413/1.392 ms

UPDATE: configuração do Radvd

interface eth0 {
    AdvSendAdvert on;
    MinRtrAdvInterval 3; 
    MaxRtrAdvInterval 10;
    AdvLinkMTU   1280;
    prefix 2001:470:1f0a:1511:1::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
    };
};

ATUALIZAÇÃO 2: Sem conexão

ip -6 neigh
fe80::21c:c0ff:fe2b:6478 dev wlan1 lladdr 00:1c:c0:2b:64:78 router REACHABLE

Com conexão (depois do ping)

fe80::21c:c0ff:fe2b:6478 dev wlan1 lladdr 00:1c:c0:2b:64:78 router STALE
2001:470:1f0a:1511::1 dev wlan1 lladdr 00:1c:c0:2b:64:78 router REACHABLE

Solicitação de vizinho fica feliz enquanto faz ping:

fe80::21c:c0ff:fe2b:6478 2001:470:1f0a:1511:21c:bfff:fe60:b389 ICMPv6 Neighbor solicitation
2001:470:1f0a:1511:21c:bfff:fe60:b389 fe80::21c:c0ff:fe2b:6478 ICMPv6 Neighbor advertisement

    

Answer 1

Os prefixos dos clientes estão sendo atribuídos manualmente? Normalmente eles devem encontrar automaticamente o roteador via Neighbor Discovery Protocol (durante o qual o roteador envia anúncios e os atribui automaticamente aos prefixos), mas parece que esse passo pode estar faltando.

Além disso, o anúncio do roteador deve incluir seu endereço de camada de link como uma opção no cabeçalho ICMP do anúncio do roteador. Se este campo estiver faltando, o cliente não saberá como enviar dados para o roteador. Parece que este poderia ser o caso. O cliente não sabe como chegar ao roteador, até que ele envie a mensagem Neighbor Discovery e receba um Anúncio de vizinho do roteador (com o sinalizador do roteador no conjunto de mensagens ICMP).

Para incluir o endereço da camada de enlace de origem nos seus anúncios do roteador, adicione o seguinte no seu radvd.conf

AdvSourceLLAddress on;

    

Answer 2

Certifique-se de que seus clientes estejam usando o endereço ipv6 do servidor como seu gateway / roteador. Como Jeff apontou, isso pode ser atribuído automaticamente (verifique sua configuração de radvd) ou manualmente, nesse caso, verifique a configuração dos clientes.

    

Answer 3

Eu acho que o seu radvd.conf está OK, apesar de não machucar comparar ip -6 addr; ip -6 route no cliente antes e depois do ping. Existe algum tipo de rastreamento de conexão ativado na caixa do túnel ou no roteador? Um ping6 feito da caixa do túnel é suficiente? Um firewall com monitoração de estado pode explicar por que os pacotes só retornam após um ping bem-sucedido.