I have a v6-only house LAN running.  One of the machines on it is
complaining

ICMP6 redirect rejected; not equal to gw-for-src=0800:201f:7c95::fe66:fb23 (must be same): (src=fe80:0009::0210:5aff:fefc:5c1a dst=2001:0700:0400:0150::0002 tgt=2001:0700:0400:0150::0002)

icmp6.c is a little old, and this is apparently the case in which
-current would instead complain "no route with inet6 gateway found for
redirect dst", because the route is actually UHL, not UG or UGH (ie,
it's RTF_LLINFO and not RTF_GATEWAY), which is why the gw-for-src=
value is trash (it's a MAC address with 80 bits of garbage appended).

The appearance of this gripe presumably indicates that I'm doing
something wrong, but it's not clear what.  I do have some slightly
strange routing going on.  If some kind soul could read my description
of what I'm doing and explain what I've botched, I'd much appreciate
it.

I have three machines, which I'll call L, G, and R for short.  The
place I'm working has arranged connectivity to my house, and I want to
carry machine L (which is a laptop) back and forth between home and
work.  The whole site - workplace and home - is all running RIPng to
handle internal routing.

At home, I have 2001:700:400:150::/60 allocated to me; I'm actually
using ...::/112.  I have only three machines connected; ...::1 is G,
the gateway to the workplace LAN and thence to the outside world;
...::2 is R, a SPARCstation LX, and ...::3 is L, the laptop that I want
to carry around.  Everyone is running route6d (and yes, I imported the
fix to make it handle /128 routes correctly).

I have L running a simple program I wrote that just blabs (to ff02::9)
a RIPng packet advertising a route to 2001:700:400:150::3/128 every
thirty seconds.  The idea is that I can carry L between home and work,
and wherever I plug it in, its advertisement of that route gets
propagated and causes everything to Just Work, without needing to
change its address.  (It might even work, eventually, though I
determined that some of the routers involved don't yet have the route6d
fix in place, so it won't work yet.)

At home, I have the oddity.  On R's console, I get "nd6_lookup: failed
to add route for a neighbor(2001:0700:0400:0150::0003)" (that's L's
address), and on L's console, I see a whole slew of the "ICMP6 redirect
rejected" messages I mentioned above.  The src= address in the message
is G's link-local (fe80::) address; 9 is the correct scope ID for the
interface in question.  The dst= and tgt= addresses are R's.

I get the feeling that the code is just not designed to deal with the
case where (as here) an interface is configured with some prefix length
and then the routing table contains RTF_GATEWAY routes with longer
(more specific) prefixes to address space that falls within the
interface's prefix.  Is this just not supposed to work, that it comes
as close as it does is an accident of the implementation, and I should
just move L to an address that's outside the /112 the house LAN is
using?  Or is there actually something broken?  It seems odd to me that
L would have an RTF_LLINFO route for R's (non-link-local) address,
since L's Ethernet is configured with prefixlen 128.  The complaint on
R's console also strikes me as  odd; it's not clear why R would think L
is a neighbour - since R has an RTF_GATEWAY|RTF_HOST route to L (with
L's link-local address as the gateway), ISTM it shouldn't be doing
neighbour discovery for L's (non-link-local) address.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B