> I suspect this topic has just about exhausted itself...

Well, this subthread of it has.  But I have a little more to say about
the initial "problem".  I've moved L to an address not part of the /112
used by R and G, and the complaints on L's console have gone away.  But
R's console still gripes about

nd6_lookup: failed to add route for a neighbor(2001:0700:0400:0150::0001:0001)

which makes no sense to me.  The address is the address I moved L to.
It's on the same 10baseT hub as R and G, but it is not in the same
/112.  L is advertising a route to that address, as a /128; R and G
correctly pick up that route (with a LL gateway address :-) and install
routes to it.  What I don't get is how ND is getting dragged into the
picture.  There's the RTF_HOST route, which is why nd6_lookup is unable
to install the RTF_LLINFO route it wants to - but why does ND want to
install such a route to begin with?  R has no business doing ND for L
at all, since L isn't on the /112 R's on.

I don't necessarily expect anyone to be able to come up with why, but
any hints as to what might be causing it and how to track it down would
be welcomed.

To continue with a response to the message (those not interested in
watching kre and me chatter at one another can stop reading now :-),

>>> [you may get renumbered]
>> That may be the theory, but it is not the practice, and until we get
>> something better than AAAA records,
> I have no idea what the DNS has to do with this in particular.

Because until the DNS infrastructure supports it well, renumbering
isn't going to become something that's undertaken casually.  And
requiring changing every AAAA record and the reverse zone names in
named.conf or equivalent doesn't count as "support[ing] it well".

> It is also possible, though I haven't actually tried it, that if the
> very first IPv6 thing that you do to an interface is to manually
> assign it a LL address, then the automatically generated one won't
> exist.

That would make sense.  It also seems to at least somewhat work that
way.  I just now tried it.  (On this machine, le0 is the interface
that's actually used; le1 is not, presently, used for anything, and is
not touched by the boot scripts.)

# ifconfig le1 inet6 fe80::1:2:3:4 prefixlen 64

The kernel did complain

in6_prefix.c: add_each_addr: addition of an addr2001:0700:0400:0150::0004/112 failed because in6_control failed for error 17

which I haven't (yet) even glanced at the reason for.
(2001:700:400:150:: is the /112 running on le0.  There is however no
::4 on that /112; I suspect it got the host part from the LL address I
specified, weird as that seems.)  But when I check afterwards, le1 does
have fe80::1:2:3:4 and no other LL address.

> I'm also not sure what the ipv6 mode (in NetBSD/KAME) "host" means,
> as distinct from "autohost" in this context, as I only ever use the
> latter.

Reading netstart, it looks to me as though autohost is just host plus
accept_rtadv=1 and rtsold.  (That is, autohost and host are the same,
except that autohost gets its address from the router solicitation
mechanisms, whereas host doesn't, presumably expecting you to configure
it with ifconfig_xx0 or /etc/ifconfig.xx0 or whatnot, or by hand if you
aren't interseted in having it happen on every boot.  A host that
doesn't normally speak v6, for example, would be set as host with no v6
addresses configured by the boot scripts.)

> Last, it doesn't seem as if there's been any response to the
> substance of the message you originally posted (why the redirect
> seemed to be handled weirdly).

Yeah.  As I said above, I did try moving L out of the /112, and as I
speculated might be the case, it helped some.  I'm still seeing the
nd6_lookup gripes, though, and I don't understand those.

/~\ 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