After the discussion we had which raised some good points, I changed my
proposal for 0.8 (0.7 has to be discussed separately) to the following:

1. Remove ipv6only and make IPV6_V6ONLY default as specified in
RFC 4038.
2. Use getaddrinfo() instead of gethostbyname().
3. Listen on multiple IPv4 or IPv6 addresses if a hostname was
given in a listen directive.
4. Add the options “ipv4” and “ipv6” to the listen directive
to set ai_family to AF_INET or AF_INET6 in struct addrinfo. This
could be useful if you want to serve a different site depending
on the address family the request came from or to simple disable
IPv6 or IPv4 even if the hostname has an associated address.

It should be discussed if there is a real demand for this
or not. If not, it shouldn't be implemented.

getaddrinfo() can resolve services and numeric addresses itself, so I
don't see need for the square bracket notation as in RFC 3986, a simple
space would be enough and would make parsing much easier:

listen 2001:db8::1 www;

What do you think about this?

Regards,
Matthias-Christian

On Wed, Aug 25, 2010 at 09:27:43AM +0200, Matthias-Christian Ott wrote:
> At the moment nignx does not allow IPv6 addresses to specified by
> hostname in a listen directive, that is the following will not work:
>
> listen ipv6.example.com;
> listen [ipv6.example.com];
> listen ipv6.example.com ipv6only=on;
> listen [ipv6.example.com] ipv6only=on;
>
> Though I see a potential security problem with hostnames here (this
> also applies to IPv4), because DNS replies can be manipulated if
> DNSSEC is not used, I think that this feature would be helpful and
> simplifies administration.
>
> Given that example.com resolves to an IPv4 and IPv6 address, simply
> binding to both addresses with the following directive would break
> backwards compatibility: listen example.com;
>
> For backwards compatibility I propose the following to resolve the
> IPv6 addresses of a hostname and listen on them:
>
> a) listen example.com ipv6only=on;
>
> b) listen [example.com];
>
> Solution b) has the disadvantage that it doesn't conform to RFC 3986.
>
> Due to the fact that IPv4 will be a legacy addressing scheme in the
> future, one could also consider to break backwards compatibility and
> introduce the option ipv4only.
>
> I would prefer this solution for 0.8 and propose solution a) for 0.7
> and 0.8. So in 0.7 IPv4 addresses would be default for hostnames and
> hostnames would only be resolved to IPv6 addresses if ipv6only is
> present and in 0.8 both addresses would be resolved and the user can
> choose between one of the address families with the options ipv4only
> and ipv6only.
>
> What do you think?
>
> Regards,
> Matthias-Christian
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel
>

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel