IPv4 & IPv6

Jim Ohlstein jim at ohlste.in
Sat Apr 6 20:44:22 UTC 2013


On 4/6/13 4:05 PM, B.R. wrote:
> That's exactly what I tried first, and if there are multiple servers
> listening to same ports, I get the following error:
> nginx: [emerg] duplicate listen options for [::]:80 in
> /etc/nginx/conf.d/***.conf:3
> See follow-up messages or (through the forum archive on this subject):
> http://forum.nginx.org/read.php?2,238147,238152#msg-238152


Please do not top post just because that's where the insertion point is
in your email client. It makes following, and, more importantly, later
searching through a thread, rather difficult. Think of it this way - you
don't shit in your pants just because that's where your asshole is. It's
annoying enough that you use HTML mail. Plain text is preferable.

> 
> I have the feeling we entered a loop back to the top of the subject...
> 
> Let me summarize :
> *Attempt #1*
> listen 80;
> listen [::]:80 ipv6only=on;
> 
> Only works if a /*single*/ server contains those directives.
> Produces error 'nginx: [emerg] duplicate listen options for [::]:80 in
> /etc/nginx/conf.d/***.conf:3' if several servers use them to listen to
> the same ports.
> 
> *Attempt #2*
> listen [::]:80;
> 
> 'Wrong approach' said Maxim, since it won't work in 1.4 stable due to
> changes in the 1.3 dev branch.
> However, in 1.2, that's the only working way I have to decide on
> per-server level which protocol and ports they need to listen to.
> 
> I'm stuck.

Why not try to use specific IPv6 addresses in your vhost config files?
This may be a band-aid for your system. It also works because it's what
we do.

Most hosts allocate a large block of IPv6 addresses at a time. We get a
/48 or a /64 at a time, depending on the provider. That's hundreds of
thousands of addresses. So we give each vhost a unique IPv6, even if
we're not using SSL.

For instance, I host the nginx forum. The first few lines of the config
file are:

server {
	listen [2001:49f0:1018::5]:80;
	listen 80;
	server_name forum.nginx.org;
	 ...
}

For a vhost with both standard and ssl ports, we use something like this:

server {
	listen  80;
	listen  ip.v4.add.ress:443 ssl;
	listen [2001:49f0:1018::a]:80;
	listen [2001:49f0:1018::a]:443 ssl;
	server_name domain.tld;
	...
}

This way there is no competition for what is listening on IPv6 addresses
and you should not see that error. I've been doing it this way for at
least a couple of years now, certainly before 1.0.x series came out. It
may not be the "recommended" approach but it's what I had to do to get
it back then. One caveat - I am using FreeBSD and IPv6 may be
implemented differently in GNU/Linux.




> ---
> *B. R.*
> 
> 
> On Sat, Apr 6, 2013 at 11:23 AM, Igor Sysoev <igor at sysoev.ru
> <mailto:igor at sysoev.ru>> wrote:
> 
>     server {
>          listen 80;
>          listen [::]:80 ipv6only=on;
>          server_name  one;
>          ...
>     }
> 
>     server {
>          listen 443 ssl;
>          listen [::]:443 ssl ipv6only=on;
>          server_name  one;
>          ...
>     }
> 
> 
>     --
>     Igor Sysoev
>     http://nginx.com/services.html
> 
>     On Apr 6, 2013, at 19:01 , B.R. wrote:
> 
>>     Add-on:
>>
>>     Besides, as I explained earlier, having generic 'listen'
>>     directives implies some difficulties.
>>
>>     For example, I am using 2 virtual servers to serve content for the
>>     same server_name, one listening on port 80, the other on port 443,
>>     allowing me to serve cotnent for HTTP and HTTPS in different fashions.
>>     Using generic 'listen' directive breaks that system and I'm stuck.
>>
>>     What would be an acceptable solution?
>>     Thanks,
>>     ---
>>     *B. R.*
>>
>>
>>     On Sat, Apr 6, 2013 at 10:52 AM, B.R. <reallfqq-nginx at yahoo.fr
>>     <mailto:reallfqq-nginx at yahoo.fr>> wrote:
>>
>>         But as I noticed earlier, these configuration directives
>>         conflict with each other across multiple virtual servers...
>>         That's a huge step backwards.
>>
>>         H
>>         ​aving to specify them only once across every configuration
>>         file is counter-intuitive.
>>         Why isn't nginx able to ​summarize all the needs for listening
>>         sockets across configuraiton files before attempting to open them?
>>         Having to define those listening directives in a 'generic
>>         default server' is awkward and looks ugly.
>>
>>         ---
>>         *B. R.*
>>
>>
>>         On Sat, Apr 6, 2013 at 6:39 AM, Maxim Dounin
>>         <mdounin at mdounin.ru <mailto:mdounin at mdounin.ru>> wrote:
>>
>>             Hello!
>>
>>             On Sat, Apr 06, 2013 at 02:25:54AM -0400, B.R. wrote:
>>
>>             > Hello,
>>             >
>>             > It seems I solved the problem...
>>             > It was indeed by reading a little more carefully the doc
>>             > http://wiki.nginx.org/HttpCoreModule#listen, thanks
>>             @Lukas! ;o)
>>             >
>>             > The '*:80' syntax is used for IPv4 listening, I don't
>>             understand why it
>>             > works as-is for you Ted. Maybe Maxim will be of a better
>>             help on that case.
>>             >
>>             > It is said that the IPv6 syntax will make Nginx listen
>>             for the 6to4 IP
>>             > address syntax, making the websites reachable through
>>             IPv4, even if no
>>             > specific IPv4 binding exist for the listening sockets.
>>             > Using:
>>             > listen [::]:80;
>>             >
>>             > I have:
>>             > $ sudo ss -lnp|grep nginx
>>             > 0      128                           :::80
>>             > :::*      users:(("nginx",***,11),("nginx",***,11))
>>             > 0      128                           :::443
>>             > :::*      users:(("nginx",***,12),("nginx",***,12))
>>             >
>>             > You shall *not* have 2 'listen' directive if you did not
>>             separate you IPv6
>>             > and IPv4 stacks (with the sysctl net.ipv6.bindv6only
>>             directive set to 1).
>>
>>             This is wrong aproach and it will no longer work for you after
>>             1.3.x upgrade.  As I already suggested, use
>>
>>                listen 80;
>>                listen [::]:80 ipv6only=on;
>>
>>             instead as a portable solution, which doesn't depend on a
>>             system
>>             configuration.  (In 1.3.x, the "ipv6only=on" part can be
>>             removed
>>             as it's now the default.)
>>
>>             --
>>             Maxim Dounin
>>             http://nginx.org/en/donation.html
>>

> 


-- 
Jim Ohlstein



More information about the nginx mailing list