[Gllug] Oddity in IPv6 routing

[John Winters]

I'm still experimenting with IPv6 connectivity and have come across one 
odd bit of behaviour which I don't have the knowledge to explain.  It 
looks similar to an IPv4 arp issue, but I don't fully understand how the 
same mechanisms work in IPv6.

I have set up a gateway machine on my LAN (called knight) which uses an 
IPv6 tunnel over my normal IPv4 connection to connect to the outside 
world.  (ISP is A&A who provide the IPv6 tunnel.)  knight is also 
running radvd which means all the other machines on the LAN pick up 
global IPv6 addresses and see knight as their IPv6 gateway.  IPv6 
forwarding is turned on on knight.

I also have a virtual server with IPv6 enabled out there in the ether 
and I use that as a test target to which to connect (or ping).

Once the tunnel has been brought up on knight I can happily ping my 
remote server from knight using ping6.  If however I try to ping the 
remote server from another machine on my LAN I see no response.  If I 
run tcpdump on knight specifying protocol 41 (the protocol used in IPv4 
to tunnel IPv6) then I can see not only the outgoing IPv4 packet 
containing the encapsulated echo request I can also see the response 
coming back, but somehow the response doesn't get back to the 
originating machine.

If I then kill ping on the originating machine and instead do "ping6 
knight" for a couple of packets, then resume the pinging of the external 
machine all is hunky.  I see perfect connectivity all the way and can 
even ssh to the remote machine.

If I then leave everything for an hour or so (I haven't yet done tests 
to see how long the timeout is) things revert to the original state and 
the LAN machine can't see the remote machine through IPv6 until it 
ping6s knight again.

This smells to me like the sort of thing caused by the arp cache in 
IPv4, but I don't know what the corresponding mechanism is in IPv6.  Can 
anyone offer any suggestions of where to look.

TIA,
John

P.S.  The output of "ip -f inet6 route list" doesn't change on either 
knight or the client machine during the test.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug