On Wednesday 19 February 2003 14:05, der Mouse wrote:
> >>> 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.

But the point was that it works in Linux and thus in situations where Linux 
can be dropped in, Linux wins by default. It's a bit of a blow to the ego, I 
suppose, that my favourite OS loses in patchwork networks. :(

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

I'm not good enough yet. :-) When I manage to get another machine patched 
together I'll start my attempts at kernel mangling.

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

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. Worst that can happen is someone 
shoots you down. :-)

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

A stream follows the path of least resistance. A river always flows downhill. 
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.

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

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

So far there's been no reason why not except "NetBSD != Linux." 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?

All we're doing is picking up a stone and dropping it in the river. The river 
doesn't care; It'll just flow around it.

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

All I have to do is look at the machine sitting across the office, stare at 
the wire, and see that it's connected to the same hub as mine. I have no 
problem conceptualizing the idea of two different subnets and combining that 
with a distaste for wasteful IP allocation.

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

Ah. Perhaps "ping it" should have been "The network stack doesn't appear to 
care that a foreign subnet is directly connected. Why would it care that I 
want to route all traffic through it?" However, since I knew you would 
understand what I meant, I shortened that to a simple "I can ping it" 
instead. Extrapolating from there: Should I explain down to minutia each 
argument I make to ensure my meaning is not lost in the translation from 
brain to fingers? Damn Wittgensteinian semantics anyway. He put an onus on 
the speaker to explain what he meant to excruciating detail also.

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

Load sharing is a harder problem. QoS isn't what I'm looking for. 
Functionality that doesn't require ipfilter fast routing is.

> > 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 wish! I wouldn't be here extensively discussing it if I thought I could make 
patches of quality enough that core would accept them.

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

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

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. There 
is no way to override this behaviour in the OS itself--only in a firewall 
rule, which means that ipfilter accounting is more difficult. A message from 
24.1.2.3 comes in to the 64.1.2.3 interface. The answer is made out to the 
same interface.

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. A message 
comes in from 24.1.2.3 to 64.1.2.3. The answer goes back out that interface 
similarly. Multiple default routes turn this reasonable behaviour on. 
Stripping out one single default route changes the system back into behaviour 
#1, above.

I think #2 is the more reasonable. This discussion makes me want to go delve. 
Not enough hours in the day! Doh.