> But the point was that it works in Linux and thus in situations where
> Linux can be dropped in, Linux wins by default.

There will always be things for which Linux is better, just as there
will always be things for which NetBSD is better.  I see NetBSD as
heading in directions I don't like, but trying to be all things to all
people is a sure path to disaster.

> It's a bit of a blow to the ego, I suppose, that my favourite OS
> loses in patchwork networks. :(

It won't work very well on Linux-mutant-IP networks, because it doesn't
run Linux-mutant-IP, any more than it will work very well in DECnet
networks, because it doesn't run DECnet.  (Because Linux-mutant-IP is
closer to something it does run than DECnet is, it comes closer to
working.  But that's about it.)

>>> The ARP code has a different problem.  You can't publish an ARP
>>> entry only to a specific interface, [...]
>> Yes, I ran into this myself, and hacked on the ARP code to make ARP
>> entries interface-specific.  The result has some problems [...]
> I think if you satisfy the following:
> . Default is to publish on all interfaces.
> . If an interface is specified, publish only on that interface
> ... then I say clean it up and submit it.

It doesn't.  It makes ARP entries interface-specific.  If you want to
publish on all interfaces, you have to add N ARP entries, and you can't
actually do that because ARP entries are actually host routes with the
LLINFO flag set, and you can't have multiple distinct routes with the
same destination.

> Fighting against that is admirable, but why fight against it
> unnecessarily?  Is there a Reason Why Not?  Just because it's not
> standard doesn't mean it's not worth pursuing.

No, of course not.  It might even be worth pursuing for NetBSD (though
at this stage my take is that it's not); I'm not the one to make that
call in any case.

>>> as we all claim it to be.
>> Where have "we" (TINW) claimed that NetBSD is capable of such routes?
> Not capable of such mutant routing, but "robust and comprehensive
> networking".  Perhaps that should be rephrased to increase its
> accuracy. :-)

Doesn't do DECnet, doesn't do CHAOSnet, and those are much better
standardized than this Linuxism, which I suspect is a case of "an
accident of the implementation someone noticed, added a cool-sounding
hack to without thinking much...".

If it comes down to the choice, I'd rather have robust than
comprehensive.  Perhaps adding Linux-mutant-IP capability wouldn't
break anything for people running normal IP, but until I'm sure of that
I don't think it should go into the main tree.

Not that I'm the person to make _that_ call either.

> So far there's been no reason why not except "NetBSD != Linux."

You've conveniently ignored the point that it's not how IP routing is
defined to work.

> I don't think adopting mutant routing capabilities that make the
> lives of people easier would drown us in Linux conformity nor
> philosophy. :-)  Do you?

No.  And I have no problem with your adding it to your kernel, nor with
making patches available to people who can afford to indulge in
experimental mutant networking.  Nor even putting it into the main
kernel, if it's judged worth that and it can avoid interference with
the normal IP stack.

What really bothers me is the idea of silently turning our normal IP
stack into a Linux-mutant-IP stack.

> I have no problem conceptualizing the idea of two different subnets
> and combining that with a distaste for wasteful IP allocation.

Neither do I.  But there are many things that I have a distaste for
that are nevertheless obviously necessary, and - at least for my values
of "obvious"! - this is one.

>>> Linux works just fine in this regard.
>> How do you configure what traffic should go out what interface?  So
>> far, you've said nothing that describes how the admin configures
>> that.
> By default it answers on the same interface the traffic came in on,
> IIRC.

...??  Does this apply only to traffic originating on this box, then,
not traffic forwarded from elsewhere?

Worse, how does it _tell_ what interface the traffic came in on?  At
least for UDP, that information is long since lost by the time a reply
is sent; at most, it has the address it was sent to.

> If a message from 24.1.2.3 came in on the 10.0.0.40 interface, I
> really don't think many people who are running static routes would
> want it to go back out the other side *with the 10.0.0.40* source
> address intact, or even at all.

"came in on the 10.0.0.40 interface" != "addressed to 10.0.0.40".

If you mean "it goes out the interface it came in on", that is very
hard to arrange, because it means there has to be some way of
associating output with the input that provoked it.  For TCP traffic,
for which part of an input request might arrive over one interface and
part over another, this is approximately impossible; even for UDP, I
think it needs APIs we don't have.

If you mean "it goes out the interface which has the address it came in
addressed to", that is comparatively easy...but that's not what you
said.

> What makes more sense?

> 1. A message comes in from 24.1.2.3 to 10.0.0.40.  The answer goes
> out *with a source address of 10.0.0.40* to the interface with a
> 64.1.2.3 address.  [...]

> 2. A message comes in from 24.1.2.3 to 10.0.0.40.  The answer goes
> back out the 10.0.0.40 interface if there's a default gateway
> available there.  [...]

To whom?

I think 1 is the most predictable and thus the most sensible.  Your
description of 2 sounds as though there are even more ugly kludges
involved, that having multiple routes set up somehow turns this
behaviour on.  That strikes me as even more broken; why, of all the
various ways to loadshare among multiple routes, should the source
address be the only one available?  (Even worse if this works only for
default routes; your description is unclear on this point.)

It also strikes me as a really gross kludge to make routing decisions
based on ip_src in this one case but not in any others.  srt is at
least general enough that it doesn't restrict you to getting
ip_src-based routing decisions only for source addresses belonging to
the local machine, and only with this one particular routing policy.

The Jargon File entry for "uninteresting" says, in part,

                                               Real hackers (see
   toolsmith) generalize uninteresting problems enough to make them
   interesting and solve them -- thus solving the original problem as a
   special case

That's what happened here: I wanted a special case, basically the same
one Linux provides.  Rather than throw in a quick and dirty kludge the
way Linux tends to (and, in this case, did), I generalized the problem
to "ip_src-based routing decisions" and wrote a tool to address that.
(And as tends to happen in such cases, I've since found other
applications for that tool, some of them not even directly related to
its nominal purpose.)

My tool may not be the Right Answer.  But I believe it's a lot more
nearly right than Linux's narrow choice to provide one particular
special case.

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