>>> You can't program the default route with an IP address that isn't
>>> in your netmask, even if it's still on the same ethernet segment as
>>> you are.
>> Of course not, because you're not on the same network (in the IP
>> sense, not in the layer-2 sense).
> But technically there's no reason not to allow it. It'

Except that it's not the way IP routing works.

If you want to draw up a precise definition of the new paradigm for
this IPv4-bis, go ahead.  Once you have it, then it might be reasonable
to try to make NetBSD support it.  But trying to make NetBSD support
something on the basis of someone's intuition, without thinking hard
about the implications, is a good way to severely break other things
unexpectedly.

I don't know much about why IP was designed the way it was; I didn't
participate in that design.  But it's proven to be an insanely robust
design, withstanding more growth than anyone could have imagined at the
time, and I'm extremely hesitant to meddle with any of its underlying
assumptions (like the way IP routing assumes every box that moves
packets between networks exists in both the sending and receiving
networks) without (a) a fully precise spec for how the change is
supposed to work and (b) a good deal of thought about the implications.

Of course, if you want to do it to your kernel, go ahead.  A lot of
good innovations start with someone trying out an idea to see what
happens.  The Linux experience is evidence that it doesn't break most
things obviously and immediately, at least.  The first problem that
comes to mind is that it won't interoperate with traditional IP stacks
on the same layer-2 network, unless of course there is also a gateway
through which they can reply.

> The ARP code has a different problem.  You can't publish an ARP entry
> only to a specific interface, which stymied me a while back when
> trying to build a proxy-arp gateway for an office network.

Yes, I ran into this myself, and hacked on the ARP code to make ARP
entries interface-specific.  The result has some problems of its own,
but was closer to what I wanted than what I started with.  (The changes
are in my private patch tree.  I haven't tried to get them into NetBSD
because I'm not convinced they're the Right fix, and NetBSD shouldn't
take them unless they are.)

>> It's no problem at all - provided the machine you're on has an
>> address on that "other network" on the interface in question.
> Seems to me that is a tremendous waste of IP addresses.  Each machine
> "should" then have an IP address for every network that lives on that
> segment.

No, only the ones that it "should" send to directly (as opposed to
going through a gateway).

> Unfortunately, without the intuitive behaviour I'm describing,
> converts coming to NetBSD from Linux are going to be sitting there
> scratching their heads, coming here to ask questions, and then
> ultimately giving up after realizing that NetBSD isn't as capable,
> routing-wise,

Well, "...after realizing that NetBSD runs standard IP, not
Linux-mutant-not-quite-standard-IP" - though they'd probably phrase it
differently; Linux users seem to often have trouble comprehending that
Linux is not the standard and does not always comply with the standard.

> as we all claim it to be.

Where have "we" (TINW) claimed that NetBSD is capable of such routes?

> Broken behaviour or not (and believe me, I can see why it's
> considered broken) Linux can just do what you tell it to if the
> request is reasonable.

Perhaps for Linux values of "reasonable", which != NetBSD values of
"reasonable".

>> I'm running 216.46.5.0/28 and 10.0.2.0/24 on the same "cable"
>> (actually, 10baseT hub) right now.  It works fine - because each
>> machine involved has two addresses on the relevant interface, one on
>> each network.
> But intuitively, you should need only one.

For your intuition, perhaps.  Mine appears to have absorbed the IP
model a bit better; it says "huh? how can a machine be on a network
it's got no address on? that makes no sense.".

>> You can probably ping 204.152.184.116 (www.netbsd.org), too, but that
>> doesn't mean you should be able to "route add default 204.152.184.116".
> Definitely a difference--that IP address is not directly ARP'able.

You said, basically, "I can ping it, why can't I route via it" and I was
pointing out that that argument is fatally flawed.

>>> My other gripe is that NetBSD sends out the wrong interface, [...]
>> Only if that's where the route to the peer address points.
> And what about multi-homed systems?

What about them?  NetBSD doesn't yet support load-sharing for outgoing
traffic.

> Again--intuitively, if traffic comes in destined for 10.0.0.0/8, and
> the interface for the 10.0.0.0/8 is sitting there, and the 10.0.0.0/8
> is routed to that interface.. then outgoing traffic should be
> answered on that interface as well.

Perhaps, again for your intuition.  NetBSD's routing table is not
designed to make that kind of distinction.  Feel free to improve it.

> I think your source-routing interface was written to address this
> problem, wasn't it?

This and other decisions based on packet source addresses, yes.

>>> With a source address of 10.0.0.5.  That's just not right.
>> The packet should go out the interface through which the route to
>> the peer address points.  (If you can state opinion as if it were
>> fact, so can I.)
> But you don't agree with it or you wouldn't have written the
> source-routing interface that you use.

I think we are talking at cross purposes here.  My statement was a
"this is what I expect to have happen".  Yours appears to have been
something like "this is what I think would be ideal".

Whether my way, your way, or some other way (eg ToS bits) "should" be
used to make routing decisions is a question only the machine's admin
can answer.  If you want to argue that the routing table should be
capable of making routing decisions based on ip_src as well as ip_dst,
I might agree with you, though I'd want to see a spec before I think
anything should be done to NetBSD qua NetBSD along those lines.

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

> It surprises me that this capability hasn't been introduced to NetBSD
> while Linux has had it .. well as far back as I can remember anyway.
> :-)

So far, you've said nothing to make me think Linux has the "it" I'm
talking about.  What I've gathered Linux has is some kind of kludge
that sends traffic from address X out the interface with address X, if
there is one.  That is, to my mind, a very wrong thing to do, because
(a) it isn't always where that traffic should go and you've said
nothing to make me think there's any way to override it, (b) it works
only for addresses the machine has, not for traffic being forwarded
from elsewhere, for which ip_src-based routing decisions are not
unreasonable, and (c) it doesn't address the case where there are
multiple such interfaces, as is often the case in the presence of
point-to-point links.

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