= Сообщение: 1635 из 7440 ============================================= IPV6 = От : Michiel van der Vlist 2:280/5555 20 Sep 15 15:20:26 Кому : Paul Hayton 20 Sep 15 15:20:26 Тема : Basic Steps / Checks to look at IPv6 FGHI : area://IPV6?msgid=2:280/5555+55feb67c На : area://IPV6?msgid=2:280/5555+55fe898c = Кодировка сообщения определена как: CP850 ================================== Ответ: area://IPV6?msgid=3:770/100+47359994 ============================================================================== Hello Paul,
I see that although your binkd node anwers IPv6 incoming calls, your tunnel end point still does not ping. It is not needed for normal operation, but it must ping in order to harvest ISKs from SixXs.
I now remember I had the same problem. Outgoing IPv6 worked fine, but my tunnel end point would not ping from outside.
Until I noticed that it would ping if I had made an outgoing ping myself less than a minute or so before.
It makes sense. At the time I had a router that was blissfully unaware of IPv6. For that router the trafic passing through the tunnel were Ipv4 packets. So an IPv6 ping request comes in over the tunnel. The router sees it as an unsollicited incoming IPv4 packet. It does not know where to send it, so it is dropped.
Now, if an outgoing ping is made shortly before, a channel is opened from the internal IPv4 address to the outside world and so now the router knows what to do with similar incoming packets. Until the channel closes after a minute or so.
So what I did is that I created a task for the Windows task manager that runs the following batch file every minute:
ping6 -n 1 2001:7b8:2ff:3a9::1
Whereby the address is the SixXs end of the tunnel.
That did the trick. It is a kludge of course :-(
With a more advanced router, one could tell the router to forward protocol 41 packets to the right machine. But then again, with a more advanced router one could host the tunnel at the router...
