In message <20050423100504.GA755@antioche.eu.org>,
Manuel Bouyer writes:

>> Or more like this, where lets pretend you have 203.98/16, which is
>> locally subnetted it into mulple /22s, lets say:
>> 
>> 
>> 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.
(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.

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.