Subject: Re: [patch] source-address selection
To: None <tech-net@NetBSD.org>
From: Pavel Cahyna <pavel@netbsd.org>
List: tech-net
Date: 09/06/2006 20:40:45
On Wed, Sep 06, 2006 at 01:26:44PM -0500, David Young wrote:
> On Tue, Sep 05, 2006 at 10:26:33AM +0200, Pavel Cahyna wrote:
> > On Sat, Sep 02, 2006 at 04:22:44PM -0500, David Young wrote:
> > > For review, here are my latest patches adding a mechanism
> > > for enforcing an IPv4 source-address selection policy,
> > > <ftp://cuw.ojctech.com/cuw/netbsd-e3b075d7/pristine-selsrc-patch>.
> > > Below, I document the impact of the patches a bit.  I will turn this
> > > text into a manual page.
> > > 
> > > The patches let an operator set the policy by which the kernel chooses a
> > > source address for any socket bound to the "wildcard" address, INADDR_ANY.
> > > Note that the policy is applied *after* the kernel makes its forwarding
> > > decision, thereby choosing the output interface; in other words, this
> > > mechanism does not affect whether or not NetBSD is a "strong ES".
> > 
> > My impression is that it introduces a quite complicated interface to
> > achieve only limited results.
> 
> Can you suggest any less complicated interface to achieve the same or
> better result?

I would be quite happy with your complicated solution, if it is a bit more
powerful. It should be possible to mark an address as being a candidate
for source address selection on other interfaces, for example.
(ok, I can add this later.)

Also, do you have any similar plans for IPv6 ? There is a standard
algorithm for source address selection, it would be good to keep v4 and v6
in sync.

> > Namely, you can't apparently request a
> > source address from a different interface.
> 
> As Mihai said, you can still bind any address you like.  It would be easy
> to extend the source-selection patch so that it considered addresses on
> interfaces other than the output interface, however, I leave that up to
> somebody else.

Well if we can bind any address, we don't need any source address
selection mechanism in the kernel, no? :-)

Pavel