Date:        Fri, 16 Aug 2002 10:12:13 +0200 (CEST)
    From:        der Mouse <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200208160849.EAA22193@Sparkle.Rodents.Montreal.QC.CA>

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

  | Is it for v4??

Yes.   v4 started with an address per interface.  People wanted more
and added aliases.  The "real address" and the "alias" aren't treated
equivalently.   Their existence causes all kinds of subtle problems.

  | That same house LAN has two v4 addresses on most
  | interfaces, and I've never seen any trouble attributable to that.

No, the problems are obscure, and don't bother most people, which is
why the world has been getting away with this for so long.   But IPv4
was designed with the one address per interface cornerstone, and lots
of things just don't quite function perfectly when it is ignored.

  | (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?

  | 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.   Even though itojun probably won't agree, the v6 theory is that
any of your addresses can be yanked from under you (and replaced with
something else) with comparatively little notice.   That's needed to keep
the routing table aggregation rates adequate.

Note that what you're asking for here is for one address on your router to
be stable enough that you can (manually) add it as the route in other boxes.

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

That was expected before LL addresses were created.

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

Yes.

  | Global-scope addresses can appear and disappear without explicit
  | configuration causing it?  How??

Router advertisements.  On regular nodes.   On routers, router renumbering,
except that most likely isn't enabled by default, and might not even be
implemented (or perhaps not shipped) in the NetBSD code.

  | I think I have a little more patching to do somewhere....

If you do that, you might (some day) find yourself just slipping off
the net until you manually go and do what the system would have
automated, except that you won't allow it.

  | Except I thought you recommended using them as static route
  | destinations.

Replacing the ugly LL addr, yes, sometimes, not in addition.   Having 2
LL addrs has almost no point (unless you just want something easy to ping).

  | 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::37%ex0 prefixlen 64
jade# ifconfig ex0
ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet autoselect (100baseTX)
        status: active
        inet 172.30.0.21 netmask 0xffffff00 broadcast 172.30.0.255
        inet6 fe80::201:3ff:fe40:8ae5%ex0 prefixlen 64 scopeid 0x2
        inet6 3ffe:8001:2:181::2 prefixlen 64
        inet6 fec0::181:201:3ff:fe40:8ae5%100 prefixlen 64 scopeid 0x64
        inet6 3ffe:b80:53:181::2 prefixlen 64
        inet6 3ffe:8001:2:181:200::2 prefixlen 64
        inet6 fe80::37%ex0 prefixlen 64 scopeid 0x2
        inet6 3ffe:b80:53:181::37 prefixlen 64
        inet6 fec0:0:0:181::37 prefixlen 64
        inet6 3ffe:8001:2:181::37 prefixlen 64
jade# ifconfig ex0 inet6 fe80::201:3ff:fe40:8ae5%ex0 delete
jade# ifconfig ex0
ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet autoselect (100baseTX)
        status: active
        inet 172.30.0.21 netmask 0xffffff00 broadcast 172.30.0.255
        inet6 3ffe:8001:2:181::2 prefixlen 64
        inet6 fec0::181:201:3ff:fe40:8ae5%100 prefixlen 64 scopeid 0x64
        inet6 3ffe:b80:53:181::2 prefixlen 64
        inet6 3ffe:8001:2:181:200::2 prefixlen 64
        inet6 fe80::37%ex0 prefixlen 64 scopeid 0x2
        inet6 3ffe:b80:53:181::37 prefixlen 64
        inet6 fec0:0:0:181::37 prefixlen 64
        inet6 3ffe:8001:2:181::37 prefixlen 64

I forgot to ifconfig and show the interface with just the
fe80::201:3ff:fe40:8ae5 LL addr, but there you can see that I
added a new LL addr, and then deleted that first one.

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

As I said last time, if there are multiple, that is a problem, except
that there you can assume that a LL address won't just appear or disappear,
they only change by explicit action (like that above) and so ...

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

is probably what happend.

  | - the admin has to figure out a way to delete the autoconfigured one,

it doesn't take a lot of figuring... rtfm.

And the rest of the sequence of alternatives all ends up
being irrelevant, right?

  | 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 - ipv6 routing table entry
requirements probably haven't made it there, just yet, so "illegal"
might have been technically a little strong - but if understood in the
common way, as being against the specs, he was correct.

And yes, NetBSD doesn't bother enforcing that particular rule.   However
it shouldn't normally be required for rules to be enforced for them to be
obeyed, enforcement is usually only required if the rules are ignored.

  | > And if that traffic needs to be authenticated, it gets even harder,
  | > doesn't it?
  | Yes, of course.  How do I configure that?

Redirects, you don't yet, no-one has figured out how to make that work
(key distribution gets hard).   Routing protocols, rtfm (or use a better
one if the one you're using doesn't understand authentication, all the
modern ones do).

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

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

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

I haven't ever wanted to do this, so this part is a guess, but check the
route command - the ND data all goes in the routing (forwarding really)
table, so a suitably crafted route command with a MAC addr destination
might be the equivalent of static arp.

kre