Opened 10 years ago

Closed 6 years ago

Last modified 2 years ago

#623 closed defect (invalid)

IPv6 link-local addresses with zone id not usable in proxy_pass

Reported by: launchpad.net/~lotheac Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.6.x
Keywords: Cc:
uname -a: SunOS www 5.11 omnios-8c08411 i86pc i386 i86pc
nginx -V: nginx version: nginx/1.6.1
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-ipv6 --with-http_ssl_module --with-ld-opt=-m64 --http-client-body-temp-path=tmp/client_body --http-proxy-temp-path=tmp/proxy --http-fastcgi-temp-path=tmp/fastcgi --http-uwsgi-temp-path=tmp/uwsgi --http-scgi-temp-path=tmp/scgi

Description

nginx doesn't like IPv6 link-local addresses with zone identifiers (addresses like 'fe80::8:20ff:fe6a:64de%www1'; the zone identifier 'www1' here refers to the network interface).

First I tried with a literal address:

proxy_pass http://[fe80::8:20ff:fe6a:64de%www1]:5232/;

but that resulted in

invalid IPv6 address in upstream "[fe80::8:20ff:fe6a:64de%www1]:5232/"

As an aside: I could work around this if it was possible to tell nginx to use getaddrinfo to resolve upstreams. If I put the address in /etc/hosts as 'foo' and use 'http://foo%www1:5232/' both curl and wget resolve the address correctly (because they just pass it to getaddrinfo), but nginx fails with:

no resolver defined to resolve foo%www1

and if I do define a resolver, it will try DNS queries, which is the wrong thing here. Is it not possible to use the system resolver?

Change History (7)

comment:1 by Maxim Dounin, 10 years ago

Resolution: invalid
Status: newclosed

There is no support for IPv6 literals with zone ids in nginx, though it works fine for names as resolved by the system resolver. Just tested with:

fe80::a00:27ff:fedf:4d9b%em1 foo

in /etc/hosts, and

proxy_pass http://foo;

in nginx config.

Some additional comments:

The "foo%www1" in your example looks wrong to me, as "%www1" is part of the address, not the name. Not sure about Solaris, but FreeBSD's getaddinfo() just fails to lookup such a name.

The fact that nginx complains about "no resolver defined" means that you are trying to use proxy_pass with variables and hence nginx own event-driven DNS resolver have to be used instead of blocking getaddrinfo(). This needs resolver, hence the error (but for obvious reasons, DNS resolution of names won't allow you to use IPv6 addresses zone identifiers).

If you want nginx to resolve names during using getaddrinfo() during configuration parsing while still using variables in proxy_pass, you may force this by explicitly defining upstream{} blocks with appropriate names, like this:

upstream foo {
    server foo;
}

set $backend "foo";
proxy_pass http://$backend;

Alternatively, just avoid using variables in proxy_pass. See http://nginx.org/r/proxy_pass for details.

Note well that RFC 3986 syntax of IPv6 address literals doesn't allow use of zone identifiers. The RFC 6874 tries to extend the syntax by allowing the http://[::1%25zoneid]/ (yes, with %25 instead of %), though this proposed standard was published less than a year ago and seems to have various major problems, see errata list.

in reply to:  1 comment:2 by launchpad.net/~lotheac, 10 years ago

Replying to Maxim Dounin:

fe80::a00:27ff:fedf:4d9b%em1 foo

in /etc/hosts

You may be interested to know that rhis doesn't work on illumos - getaddrinfo
for foo returns EAI_NONAME if the entry in the hosts file includes the zone id.
But maybe this is a bug in illumos, I don't know.

The "foo%www1" in your example looks wrong to me, as "%www1" is part of the
address, not the name. Not sure about Solaris, but FreeBSD's getaddinfo()
just fails to lookup such a name.

It appears to be the opposite on illumos (and I assume Solaris). If the hosts
file doesn't include the zone id, 'foo%www1' works with getaddrinfo.

The fact that nginx complains about "no resolver defined" means that you are
trying to use proxy_pass with variables and hence nginx own event-driven
DNS resolver have to be used instead of blocking getaddrinfo(). This needs
resolver, hence the error (but for obvious
reasons, DNS resolution of names won't allow you to use IPv6 addresses zone
identifiers).

Ah, thanks, that makes sense - removing variables did the trick. Thanks, and
sorry for the noise.

Version 0, edited 10 years ago by launchpad.net/~lotheac (next)

comment:3 by https://stackoverflow.com/users/11113143/birajpaul600, 6 years ago

Resolution: invalid
Status: closedreopened
'''
== '''''[
{{{
[[BR]]
[[Image(
----
)]]
}}}
]''''' ==
'''

comment:4 by Maxim Dounin, 6 years ago

Resolution: invalid
Status: reopenedclosed

comment:5 by Maxim Dounin, 2 years ago

See also #2413.

comment:6 by Maxim Dounin, 2 years ago

For the record, upcoming RFC 6874bis looks somewhat more promising than the original RFC 6874.

comment:7 by Maxim Dounin, 2 years ago

See also #1422.

Note: See TracTickets for help on using tickets.