First, thank you for the explanation.  It greatly clarifies the issues
for me.

Second, I have tried to edit away the emotional language below.  I
probably have not entirely succeeded.  The emotion is not directed at
you.  (Except, I suppose, to the extent that you may be behind the
decisions that I see as (a) stupid and (b) inappropriately
heavy-handed.)  I don't want to shoot the messenger here.

>>> [global addresses as route destinations aren't legal]
>> Not legal?  What on earth??  (They certainly _work_; I've used
>> global addresses as the target for default routes often enough.)
> No, they don't really work, they only seem to.

FVO "work" = "packets flow in both directions".

> The problem is how redirects are handled.  If you're willing to
> simply allow any random node to send you a redirect, and you'll trust
> it, then sure - you can use any address you like (for the gateway) in
> the routing tables.

Or if you're willing to just ignore redirects from the routed-via
router, sounds like.  Or if your setup is such that you'll never have
any redirects to start with, which is probably the case in the setup I
was referring to that "works" with global addresses in routes.

> [why router sends redirect from LL address]

Essentially, what this is doing is the same thing IPv4 did - send
redirects from-stamped with the machine's address on the sending
interface.  In IPv4, there was usually only one interface address per
interface; when there was more than one, one was considered
distinguished (usually the first-configured one) and it was used.  IPv6
then gave every interface a link-local address, which meant that any
interface with a global address had multiple addresses.  Upon noticing
the problem this created for redirects, they "solved" it by decreeing
that the link-local address is the distinguished one, rather than
letting the machine's admin specify somehow.  It really seems like just
partially hiding the problem, though, because (a) what if the interface
has multiple LL addresses, and (b) taking control away from the local
admin is rarely-to-never a good idea.

It also means that it's not "don't use global addresses as route
destinations" but rather "use link-local addresses as route
destinations", and not only that but also "don't configure multiple
link-local addresses on interfaces".

> So, now you are going to receive a redirect from the LL addr of the
> router you're using.   If you're not going to just trust anything,
> you need to know that that LL addr belongs to the router that you're
> using.  That is, that LL addr needs to be in the routing table, so it
> can be matched.

Or you need to just ignore the redirect.  Which is a valid
administrative decision - or at least should be, though it appears the
v6 people think they know better than I how to administer my systems,
something that always gets my wind up.  (Especially when it's with
respect to something that doesn't affect the rest of the net.)

>> In particular, how on earth am I supposed to determine the
>> link-local address corresponding to the global address of the router
>> I want to point the route to?
> In general, you're not.  That's what routing protocols and router
> discovery do for you.

So, there's no place in IPv6 for fully static routing?  That sounds
like a fairly serious security lose; it's much harder for someone to
attack me through routing if I pay no attention to network traffic in
making my routing decisions.

Which brings up another point; NetBSD has net.inet6.icmp6.rediraccept
turned on (ie, insecure) by default.  Fragile at best.  Another patch
for the private patch tree, I suppose, since I don't expect that to
change.

> [Y]ou're supposed to use routing protocols on routers, and router
> discovery on hosts.  And let the software figure out the paths.

I still think that's broken.  Fully static routing should be an
acceptable administrative choice.

>> That seems pointless and stupid, especially as it's unnecessary in
>> practice.
> Perhaps you now see why it isn't.

True; now I just think it's stupid and unnecessary in practice.
(Advisable in some, even many, environemnts != necessary.)

Recommending use of link-local addresses, fine.  Requiring them, no.
Not unless the above issues can be addressed.

Until someone comes up with a better suggestion, I will continue to use
fully static routing, with global addresses as route destinations, on
the relevant LAN.  Though I'm glad this issue arose, as I wouldn't've
noticed the insecurity introduced by having rediraccept turned on by
default otherwise.

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