>> The thing that I'm calling broken is the dictum that Thou Shalt Not
>> Use Other Than Link-Local Addresses As Route Destinations, which the
>> NetBSD implementation does not, as far as I can see, enforce.
> No, I don't think it does - but if you don't obey it, and then wonder
> why redirects aren't working (which seemed to be what your initial
> message was saying - though I suspect there might be a deeper
> problem) then you have to understand that people are going to just
> tell you "you're not doing it right".

True as far as it goes.

The initial message was not "why aren't redirects working".  They were
working, sort of.  The LAN on which that was happening _was_ using
dynamic routing and _was_ using link-local addresses as route
destinations (at least whenever I checked - route6d was responsible for
them all, and I didn't check every last route it installed).  As I
recall, the exchange went something like

itojun> I bet you're using global addresses ...

me> You'd lose that bet.
me> [mini-rant which started this thread off]

>> (But I also have occasion to see v4 redirects about as often as I
>> have occasion to see v6 redirects, which is to say, never.)
> Wasn't it ipv6 redirects (dumb ones, but anyway) which started this?

Yes, but (as I said above) on a different LAN.

House LAN A is using fully static routing, has both IPv4 and IPv6
addresses for all hosts (except one that has no v6 address because,
principally, of the lack of proxy ND; its v4 connectivity depends
heavily on proxy arp), sees redirects approximately never, and has no
problems related to this thread as far as I can tell.  It's also the
one where I'm using global-scope addresses as route destinations.

House LAN B is using fully dynamic routing (route6d, mostly), is
IPv6-only, and is the one where I saw the issue that provoked the
message which started things off.  I've never caught it using other
than link-local route destinations since I stopped trying to do any
routing by hand.  (Initially, I tried to do static routing for it too.
But the environment is different; it experiences topology changes
routinely instead of approximately never.  And all the hybrid setups I
tried, partially static and partially dynamic, never worked - as I'm
sure you're not surprised to hear.)

>> I don't see why that means there can't be one distinguished address.
> Because you have no address for v6 that is stable enough to use for
> that purpose.

That may be the theory, but it is not the practice, and until we get
something better than AAAA records, I can't see how it can be.  (Given
what you say about dynamic renumbering, I can't understand why people
backed off from A6 records; we'll need not only something like them but
some way to delegate a zone that is not known to the delegated-to
server at config time before changing someone's prefix can become a
routine operation.)

>> This means either carrying multiple LL addresses or getting rid of
>> the first one, and I don't see any easy way to do the latter.  (Or
>> is that just a NetBSD implementation defect?)

> Neither ...
[...]
> jade# ifconfig ex0 inet6 fe80::201:3ff:fe40:8ae5%ex0 delete

I was a little too abbreviated.

I don't see any way to get rid of the EUI64-based LL address in the
network startup scripts without hardwiring knowledge of the EUI64
chosen by the kernel into those scripts.  Do you really think it's sane
to have startup scripts that look like

ifconfig de0 inet6 `ifconfig de0 | egrep 'inet6 fe80:.*' | head -1 | sed -e 's/ prefix.*//' -e 's/.* //'` delete

I don't see any better way to strip off the autoconfigured LL address
without having a boot script that breaks if you swap Ethernet hardware
(or if you copy it verbatim to another machine) because it has,
effectively, the card's MAC address in it.

>> - the admin has to figure out a way to delete the autoconfigured one,
> it doesn't take a lot of figuring... rtfm.

You mean I missed "ifconfig de0 inet6 delete-autoconfigured-ll-addr"?
See above.

I find this particularly peculiar since the ifconfig manpage says
"delete does not work for IPv6 addresses.  Use -alias with explicit
IPv6 address instead.", which runs counter both to what you recommend
and to my (and apparently your) experience.

>> I'm not talking about avoiding global-scope addresses by default.
>> I'm talking about going so far as to forbid them (itojun called them
>> "illegal", though fortunately NetBSD does not seem to enforce any
>> such forbidding).
> Yes, the specs say that thou shalt not do that.   "Illegal" usually
> means something related to your local legislature

Oh, stop trying to confuse the issue.  In computer contexts, "illegal"
means "forbidden by the specificaion", where "the specification" is
context-dependent - in this case, it would be the IPv6 standards (RFCs
and drafts).

>> What's incorrect about not using LL addresses?  It means redirects
>> don't work, which is the Right Thing anyway if you're doing static
>> routing.
> Actually, when you're doing static routing is usually the time you
> most want redirects,

Perhaps I am using the wrong term, then.  Static routing, as I use the
term, *by definition* means you don't want to pay attention to
redirects, because static routing means routing that does not change
expect by explicit administrator action.  And an
automatically-generated redirect does not qualify.

> because manually keeping up with routing changes is way too much work
> ... except in the odd cases where there are no routing changes of
> course.

Which is often enough the case in small backwaters of the net like
house LANs that have only one link out; if it's up, that's the right
place to send packets, and if it's down, it's no worse than any other
place, 'cause they aren't getting out no matter where you send them.

>>> [static ARP table?]
>> No, that would correspond to static ND info, not to static routes.
> Yes, it would - but dynamic arp runs all the same risks as (link
> local) redirects.   A local hacker can hijack paths by sending them
> to a bogus MAC addr...

Hm, true.  I'll have to figure out whether the pain of hardwired arp
tables is worth the benefit, and if not, decide whether it's worth the
disruption to switch to dynamic routing, at least for v6.  (On house
LAN A, that is, of course.)

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