IPv6 & IPv4 backend with proxy_bind

[SplitIce]

An IPv6 based fallback is not the only solution we want to support,
ultimately we would like to be able to load-balance between them as well.
An error_page based solution would not assist.

I also get the feeling that such a hack would have large implications,
while either an additional parameter or another directive would be a simple
& clean solution to a real identified deficiency.

This kind of request is only going to get more common with the growing
adoption of IPv6.

Regards,
Mathew


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

> Hello!
>
> On Mon, Nov 18, 2013 at 10:24:43PM +1030, SplitIce wrote:
>
> > 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.
>
> Ok, I see what you are trying to do.  A working solution would be
> to use distinct upstream blocks for ipv6 and ipv4 addresses and an
> error_page based fallback (with proxy_bind configured to
> appropriate addresses in distinct locations).
>
> Given the fact that use of proxy_bind is uncommon by itself,
> and it's use in multi-protocol configuration even more uncommon, I
> tend to think that exisiting solution is good enough.
>
> --
> 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/20131119/813292bd/attachment.html>