On Sat, Apr 23, 2005 at 04:13:05AM -0700, Jonathan Stone wrote:
> >> 
> >> 203.98.10.1							203.98.20.2
> >>                 ---------------                     ---------
> >> --- public IP | NetBSD 3.0 box |10.1.1.1----10.1.1.2| Router|Internet----
> >>                 ---------------                     ---------
> >> 
> >> 
> >> where both left and right halves are part of a larger 203.98/x cloud
> >> for 16 <= X < 22 ?  I'm assuming the latter, but I'm trying to be precise.
> >
> >Yes, it is the second case.
> 
> [...]
> 
> >The link between the NetBSD box and the router is a simple copper ethernet.
> 
> 
> OK. So David's patch will likely solve the problem, but only in the
> special case where your enclosing `cloud'' is globally routable.

Yes.

> (Acutally, the offered patch only fixes your problem is if you use
> zeroconf addresses or 224. source addresses(???), not rfc-1918
> addresses. Lets take the neecssary chacnes as read.)
> 
> But David's patch does not help in the (for me, common) case when the
> enclosing cloud is itself non-globally-routable, and the ``private''
> links use a *different* RFC1918 network.

Sure. In today's world, whenever RFC1918 addresses are private really
depends on the context.

> 
> So (again), it seems to me a better way to fix this, is to mark
> specific local addresses as ``second-class'', and to not use such
> ``second-class'' addresses as source addresses for non-bound outgoing
> traffic, if the traffic is to a different subnet.
> 
> >From that perspective, David's suggestion is equivalent to mine:
> except, intead of explicitly marking some addresses as ``second
> class', David implictly all zeroconf (or RFC-1918 addresses) as
> ``second-class''.  Maybe David's in_getifa() idea could be used
> (though the definition needs a redo-from-start, and I'd pick a name
> close to the RFC-1122 pseudo-code). I'd have to think about that.
> 
> Okay, it's a little more work to add an API to mark interface
> addresses as ``second-class''. But it's clearly a superior solution:
> it cleanly handles cases that David's kludge never will.

In fact, I didn't think my question would lead to such a deep analysis.
I was looking at something like a simple routing table hack, without code
change. I tried a few things here, playing with interfaces aliases and
-ifa modifier, but none did work.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--