Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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


# 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?

share|improve this question
up vote 3 down vote accepted

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 not ip -6 route. That's because the route is in the local table, rather than main. You can see it with ip -6 route list table local. Just removing that /128 route might do the trick.

share|improve this answer
That's great, thanks. I managed to convince upstream to move away from the ::0 address. – Zanchey Dec 21 '10 at 4:08

(In the short term we have solved this with

# ip -6 addr add 2405:3c00:1:13::/128 dev  eth1
# ip -6 addr delete 2405:3c00:1:13::/128 dev  eth1
# route -6 | grep 3c00
2405:3c00:1:13::/64            ::                         U    256 0     0 eth1
2405:3c00:1:13::2/128          ::                         Un   0   1     0 lo

but that is a bodgy hack.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.