Date:        Wed, 14 Aug 2002 11:30:48 +0200 (CEST)
    From:        der Mouse <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200208141015.GAA10275@Sparkle.Rodents.Montreal.QC.CA>

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

That's OK, while I'm not responsible for the parts of this that are
actually IPv6, I am for the parts that you read into my message...

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

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

Yes, and as long as you always manage to get the routing perfect, it
will all be OK.   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.

  | Or if you're willing to just ignore redirects from the routed-via
  | router, sounds like.

Yes, if you never want to use a redirect, then the value that you're using
as the address of the next hop gateway is (almost) irrelevant - it is known
only inside your IP stack.   You may end up doing an extra ND transaction
from time to time, but you also probably don't care.

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

  | IPv6 then gave every interface a link-local address, which meant that any
  | interface with a global address had multiple addresses.

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.

  | Upon noticing the problem this created for redirects,

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

  | they "solved" it by decreeing
  | that the link-local address is the distinguished one, rather than
  | letting the machine's admin specify somehow.

LL is the right choice for this kind of thing in any case, because the
packets only make sense on that one link.

Similarly, requiring the gateway address be a LL addr, means that people
aren't tempted to specify addresses as the gateway that aren't on the local
link (some address of the gateway on some link I'm not connected to, or
worse, a gateway I don't even have a direct link to).   Kernels can trap
and reject that easily enough, but actually telling people that they have
to use the LL addr of the gateway on the link drives the point home a little
better.

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

  | and (b) taking control away from the local
  | admin is rarely-to-never a good idea.

True, when there isn't a good reason.   Here I think the reasons are good
enough.

  | It also means that it's not "don't use global addresses as route
  | destinations" but rather "use link-local addresses as route
  | destinations",

Yes, that is the rule.

  | and not only that but also "don't configure multiple
  | link-local addresses on interfaces".

That isn't required.   I often configure an extra one, because
	ping6 fe80::2%ex0
is easier than
	fe80::201:3ff:fe40:8ae5%ex0

But just for that reason.   And I only tend to do it if I am actually
planning on pinging that interface a bit, using link local addressing,
it isn't a part of the normal config.

  | Or you need to just ignore the redirect.  Which is a valid
  | administrative decision - or at least should be,

Yes, you can do that.

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

  | So, there's no place in IPv6 for fully static routing?

No, of course there is.   It's just that the place is smaller than it was
for v4, because there's less need for it.   More is provided in the base
protocol implementations to make static routing less necessary.   That's
all part of making nodes just plug in and work - which again, is what most
people want.   You can always set up your net differently of course.

  | 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?
And if that traffic needs to be authenticated, it gets even harder, doesn't
it?

Once you get out of your little fiefdom, you know people are using dynamic
routing to get to you, whatever you think of it, so it is only your part
of the world that matters.

Personally, I think I'll keep to reasonably secured dynamic routing.
I know that I get link failures that require routing changes much more
often than successful attacks on the routing system...

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


No, I don't either.   Using LL addresses, redirects are relatively
safe on v6 (compared to their use on v4), they can only originate at
some local node on your link.    Adding authentication to these kinds
of packets is harder (than routing, etc), but there's on-going work
looking at how all of that might be done.

  | 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.   Because (for v6 anyway) I happen to have
no real alternative routes, I use static routing a lot currently.  But
that will change as v6 connectivity improves.

[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]

kre