IPv6 works only after ping to routing box

Question

Situation:

There is an ipv4 only router in our network and every computer is connected to it (wifi or cable). A server with ipv4 and ipv6 is also connected to this router. The server has been configured with tunnelbrokers for 6to4 tunneling and radvd. Clients in the network have the right prefix and can ping each other via ipv6. But they can't ping to the internet until they first ping Server (the one with the tunnel). I found somewhere that it's an icmp problem, but I couldn't find solution.

Is the problem that the router is ipv4 only?

• server and clients run linux
• router runs dd-wrt without ipv6 support :(

Ping try:

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: Radvd config

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

UPDATE 2: Without connection

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

With connection (after 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

Neighbour solicitation happends while pinging:

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

Are the clients' prefixes being manually assigned? Usually they should automatically find the router via Neighbor Discovery Protocol (during which the router sends out advertisements and assign them prefixes automatically), but it sounds like that step might be missing.

Additionally, the router advertisement should be including its link-layer address as an option in the ICMP header of the router advertisement. If this field is missing, the client won't know how to send data to the router. It sounds like this could be the case. The client doesn't know how to reach the router, until it sends out the Neighbor Discovery message and it receives an Neighbor Advertisement from the router (with the router flag in the ICMP message set).

To include the source link layer address in your router advertisements, add the following into your radvd.conf

AdvSourceLLAddress on;

Answer 2

Ensure your clients are using the ipv6 address of the server as their gateway/router. As Jeff pointed out this may be automatically assigned (check you radvd configuration) or manually in which case check the clients configuration.

Answer 3

I think your radvd.conf is OK, although it wouldn't hurt to compare ip -6 addr; ip -6 route on the client before and after the ping. Is there some sort of connection tracking enabled on the tunnel box or on the router? Is a ping6 done from the tunnel box sufficient? A stateful firewall could explain why the packets only come back after a successful ping.