[PATCH] Added so_freebind and so_transparent to the listen directive

[Trygve Vea]

----- Opprinnelig melding -----
> Hello!

Hello!

> On Thu, Mar 27, 2014 at 04:34:37PM +0100, Trygve Vea wrote:
> > # HG changeset patch
> > # User Trygve Vea <trygve.vea at redpill-linpro.com>
> > # Date 1395933815 -3600
> > #      Thu Mar 27 16:23:35 2014 +0100
> > # Node ID 13e6a37c2f57443b0d5dd0abce8d9d4ab00e31e3
> > # Parent  2411d4b5be2ca690a5a00a1d8ad96ff69a00317f
> > 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.
> 
> Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
> 
> It is expected to work fine and allows to accept connections on
> all addresses currently available on a host without any
> non-portable tricks.
----- Opprinnelig melding -----
> > IPv4 has a sysctl available (ip_nonlocal_bind), which is not available for
> > IPv6 - thus making these patches necessary.
> 
> Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
> 
> It is expected to work fine and allows to accept connections on
> all addresses currently available on a host without any
> non-portable tricks.

That would be sufficient for HTTP - and my preferred option, since we can handle routing after the end-user have provided us with the Host-header, and thus know where to send the user.

However, with SSL enabled - while we have end users that still do not support SNI (http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side), and using multiple SSL-certificates, for multiple applications - we will need to bind each certificate to its own dedicated service address.  From here, we can do routing / forward the connections further down the stack.

After I submitted the patch, I noticed that it will probably not build on Linux versions prior to 2.4, so I intend to create a new one addressing that issue tomorrow when I'm back at the office.

Are there any issues with the patch that I should take into consideration when making changes?


Regards
-- 
Trygve Vea