[PATCH] Added so_freebind and so_transparent to the listen directive

[Trygve Vea]

----- Opprinnelig melding -----
> Hi Trygve,
> 
> > Added so_freebind and so_transparent to the listen directive
> >
> > This solves a Linux/IPv6-specific problem.
> >
> > To be able to listen to an IPv6 address that is not yet available on the
> > host,
> > one need to use the IP_FREEBIND and IP_TRANSPARENT socket options.
> >
> > The use case in question is for a failover setup with several service-
> > addresses in a IPv6-only environment.
> >
> > IPv4 has a sysctl available (ip_nonlocal_bind), which is not available for
> > IPv6 - thus making these patches necessary.
> 
> Non-local bind() isn't Linux-specific feature. FreeBSD has
> IP_BINDANY/IPV6_BINDANY options and OpenBSD has SO_BINDANY option, so
> it would be good to add support for all of them.

That makes sense.

> Also, requiring user to add both: "so_freebind" and "so_transparent"
> options to enable single feature doesn't look very user friendly,
> especially because according to your description, non-local bind()
> would work just fine with only "so_freebind" for IPv4 addresses, but
> it would fail for IPv6 addresses... I don't think that the "so_"
> prefix is necessary, how about just "bindany" or "nonlocal"
> ("freebind" is just stupid name)?

The so_-prefix was something I took from the existing so_keepalive option.  Are there any conventions I should follow when I name these values?

I agree that creating a single option that can handle multiple platforms the same is a good idea.

What if I do something like;

* Create a configuration variable for the listen-directive named 'nonlocal'.
* If IPv6 and Linux >= 2.4, attempt to set the socket options in question. (I'm not sure if I would need to deal with dual stack in a certain way, here - I'll check with one of the IPv6-evangelists at work tomorrow)
* If IPv4 and Linux >= 2.4, set the IP_FREEBIND socket option.
* Else, throw warning that the parameter will be ignored because running on an unsupported platform.

Adding support for more platforms for the configuration option can be easily added by someone with access and knowledge about the platforms.  I have actually never used FreeBSD/OpenBSD, so my knowledge is fairly limited.

Would that be acceptable?

-- 
Trygve