We have a router running Debian Lenny that has been happily routing IPv6 for several months. Our upstream has advised that our address range is changing, and both are currently operational, so I thought I'd add the second address for testing.
ip -6 addr add 2405:3c00:1:13::2/64 dev eth1
# ping6 2405:3c00:1:13:: (our upstream router)
64 bytes from 2405:3c00:1:13::2: icmp_seq=1 ttl=64 time=0.089 ms
What?
# ip -6 route get 2405:3c00:1:13::
local 2405:3c00:1:13:: from :: via :: dev lo table local proto none src 2405:3c00:1:13::2 metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
# route -6 | grep 2405
2405:3c00:1:13::/64 :: U 256 0 1 eth1
2405:3c00:1:13::/128 :: Un 0 1 0 lo
2405:3c00:1:13::2/128 :: Un 0 1 0 lo
I am curious how the ...13::/128
route arrived. It appears about two seconds after I add the address to the interface. radvd(8) is not enabled on the interface, unsetting accept_ra
and autoconf
makes no difference.
Is there any easy way to keep an eye on which process is modifying the routing table? Does anyone have any brilliant ideas about what the culprit might be?
In any /64 subnet, the ::0 address is the subnet-router anycast address; it identifies all routers on the link. Since you have net.ipv6.conf.all.forwarding turned on, the system identifies itself as a router and joins that anycast group. Unfortunately, this behavior isn't really documented or configurable, so you probably have about the right solution.
More ideal would be not using that address, since it's technically reserved, but that may not be an option with your ISP.
You may have noticed that the route only shows up with
route -6
and notip -6 route
. That's because the route is in thelocal
table, rather thanmain
. You can see it withip -6 route list table local
. Just removing that /128 route might do the trick.(In the short term we have solved this with
but that is a bodgy hack.)