IPv6 & IPv4 backend with proxy_bind

[SplitIce]

Hi,

We use proxy_bind to ensure traffic always goes out via the same address as
the incoming request i.e the bound address where a server has many
addresses. This is a hard restriction in our use case.

We are looking to add support for IPv6 backends, we would like to allocate
a single IPv6 outgoing address per client although this is not a fixed
restriction at this stage. IPv6 backends may be used in the same upstream
block as IPv4 addresses (and we encourage this, as some network providers
are prone to IPv6 related issues).

We need to be able to maintain our existing system of binding v4 addresses
while allowing for additional support for ipv6 (it is not possible to use
IPv6 at all while using a v4 bound address as it will fail with a binding
error as expected).

For one we expect to see upstreams such as

upstream customer_1 {
server 2001:...:7334
[...]
server 123.1.2.3 backup;
}

become very common in the near future with the increased adoption of IPv6.
We have already had several requests for such functionality in the past
year.

Regards,
Mathew


On Mon, Nov 18, 2013 at 10:15 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sat, Nov 16, 2013 at 11:04:20PM +1030, SplitIce wrote:
>
> > Looking at the documentation it seems there is no way to specify a proxy
> > bind address for both IPv4 and IPv6.
> >
> > You can specify one or the other, but never both. This is a particular
> > issue when a configuration is setup to allow for a failure in IPv6
> transit
> > / routing.
> >
> > Is it possible to get a proxy_bind_v6 directive?
>
> Could you please clarify the intended use case?
>
> The proxy_bind directive is expected to be used to force an IP
> address used to connect an upstream, originally - to make sure the
> outgoing address used is one allowed by upstream's security
> restrictions.  Just using distinct proxy_bind directives for
> different upstreams is usually expected to be enough (if at all
> needed).
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20131118/552f14f9/attachment.html>