> (And apologies for taking days to reply, I don't always get a chance
> to read NetBSD related mail every day).

Oh, quite OK, I've been known to take my time about replying too.

> But for IP to "work" as it should, it has to transparently handle
> routing changes as well.   You might never have to worry about that,
> many of us don't (in that, the only change possible is from routable
> to not routable, or vice versa) - but the IP stack in general, and
> the NetBSD implementation, cannot assume that.

Oh, certainly.  I'm not saying the NetBSD implementation is broken.
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.  In some
environments - like the little house LAN I was referring to where I use
entirely static routing, and yes, the only topology changes that are
plausible enough for me to care about are my external link blinking in
and out - I can't see anything wrong with it, nor that it breaks
anything that matters (in that environment).

>> Essentially, what this is doing is the same thing IPv4 did - send
>> redirects from-stamped with the machine's address on the sending
>> interface.
> Yes.   Just dealing with the fact that having multiple global
> addresses on an interface isn't to be treated as a "weird special
> case" for IPv6.

Is it for v4??  That same house LAN has two v4 addresses on most
interfaces, and I've never seen any trouble attributable to that.  (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.)

> Every interface was going to have to be able to deal with multiple
> addresses anyway.   There can't really be one distinguished address
> any more, as IPv6 wants nodes to be able to delete old addresses, and
> take on new ones dynamically.

I don't see why that means there can't be one distinguished address.  I
can add and delete v4 addresses dynamically too, and the
"distinguished" address is always well-defined, unless the interface
has no addresses at all.  The only thing I would have changed wrt this
for v6 is that I'd provide a means for the admin to mark one particular
address as the distinguished one, even if it's not the first one on the
list of addresses.

> so it wasn't really the addition of LL addresses that created the
> problem.  The same thing exists in v4, it is just that most of us
> ignore it most of the time (after all, if we ignore redirects, the
> packets are still getting through, just taking an extra hop on the
> local lan).

The addition of LL addresses created the problem in that it meant that
having multiple addresses on an interface became a routine thing.

And the parenthetical note is just as true of v6, is it not?

>> It really seems like just partially hiding the problem, though,
>> because (a) what if the interface has multiple LL addresses,
> Yes, that one is a problem.  Fortunately, LL addresses (after the
> first) only ever appear by explicit configuration, so there the
> address won't change by itself while a node is running (unlike global
> addresses might).

Global-scope addresses can appear and disappear without explicit
configuration causing it?  How??  I think I have a little more patching
to do somewhere....

> Because of that, an implementation can easily guarantee to always
> send all redirects (and other packets requiring LL addressing) from
> the "first" LL addr, leaving the others only to be used as extra
> addresses (things that can be ping'd).   There isn't really much
> point for multiple LL addresses...

Except I thought you recommended using them as static route
destinations.  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?)

>> and not only that but also "don't configure multiple link-local
>> addresses on interfaces".
> That isn't required.

Then that introduces the ambiguity of which LL address is to be used to
source redirects, which is what I thought we were trying to get away
from.

Of course, that ambiguity is resolved, probably by "pick the first one"
which means either

- the admin has to figure out a way to delete the autoconfigured one,
or
- using the autoconfigured one,
in which case,
- - static routes have to point to the autoconfigured one,
which means
- - - figuring that out, and changing all the routes when you change
      hardware and thus change your EUI64,
or
- - you ignore redirects, in which case you might as well use the
    global address instead.

I can't see any good conclusion here except "don't do static routing".

>> though it appears the v6 people think they know better than I how to
>> administer my systems,
> No.   The defaults tend to be set so that they work best for
> everyone.  That they're not set in the way that works best for you
> shouldn't be considered as a personal affront...

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).

>> 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.
> True, but if the only routing traffic you ever listen to is local
> traffic, generated by local nodes on the link, then it is still
> pretty hard isn't it?

Only for remote attackers.  I don't want to contemplate a local
attacker, as it means one of my machines has already been cracked (or
my physical perimeter has been breached, which I consider less likely),
but if it does happen, I don't want it to be trivial for said attacker
to break routing to all other machines on the LAN as easily as spewing
forged redirects.

> And if that traffic needs to be authenticated, it gets even harder,
> doesn't it?

Yes, of course.  How do I configure that?

> Once you get out of your little fiefdom, you know people are using
> dynamic routing to get to you, whatever you think of it,

Oh, certainly.  If they're willing to accept the risk, I really have
nothing to say about it; their network, their choices.  (Except to the
extent that I'm their customer, in which case I have the same right to
have a say in how they run it that any provider's customer has.)

>> I still think that's broken.  Fully static routing should be an
>> acceptable administrative choice.
> It is.  You just need to go find the appropriate LL addresses to use,
> in order to do it correctly.

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.

> [Aside: do you yse fully static IPv4 ARP tables as well???   I know
> some people do, but almost none - it seems to be the same issue]

No, that would correspond to static ND info, not to static routes.  My
IPv4 routing table _is_ fully static.  (On that same house LAN.  I also
run another house LAN on which I do run IPv6 dynamic routing protocols;
the tradeoffs are different.)

Oh, and I do use some static ARP entries, and I find it..inconvenient,
to put it mildly..that NetBSD has no IPv6 equivalent of arp -s or proxy
arp, as it means I can't do the corresponding things for v6.  Someday I
may add them, if I'm still using NetBSD for that by the time I collect
enough round tuits.

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