On Wed, Apr 13, 2005 at 07:14:05PM +0200, Manuel Bouyer wrote:
> Hi,
> I have the following setup:
>                 _______________                     _________
> --- public IP | NetBSD 3.0 box |10.1.1.1----10.1.1.2| Router|Internet-------
>                 ---------------                     ---------
> 
> That is, the NetBSD box has a public IP, on a public IP network, but it's
> not the network connecting it to the default router (its default route is
> 10.1.1.2).
> This works mostly fine, exept that for outgoing connections from the NetBSD
> box, the source address is 10.1.1.1.
> Is there a way to force it to use the public IP for outgoing connections ?
> I tried playing with the -ifa modifier to route, without results.

Back to the problem at hand: the kernel chooses a more-or-less arbitrary
IPv4 source address on the nexthop interface.  An arbitrary choice does
not suit all applications: tech-net has seen two or three questions
about source-address selection in as many months.  I believe there is
room for some improvement in IPv4 source-address selection.

Here are two heuristics that will help NetBSD select IPv4 source addresses
that I believe will satisfy most askers on tech-net:

        (1) Prefer a source address on the nexthop interface that
            belongs to the same global/link-local/private category as
            the destination address.  For example, prefer a source in
            169.254/16 over all others for destinations 169.254.0.1
            and 224.0.0.1; do not pick a source in 10/8, 192.168/16,
            or 172.16/12 for a globally-routable destination.

        (2) Prefer the source addresses that have the longest prefix
            in common with the destination address.

The patch I sent to the list earlier is a start on heuristic (1).
I will be happy to program both the heuristics.

ISTR one asker wants to prefer one source address over another on the
same interface.  Both the source addrs were in the same subnet.  He will
be better served by source address preference numbers than by heuristics
(1) and (2).  I think a natural place to store a preference number is
the heretofore unused 'metric' field in ifaddr.

Thoughts?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933