Services listening on IPv6 and IPv4 (or maybe not?)

The other day I wanted to verify whether a service running on my Linux server was listening on IPv6 as well as IPv4. It turned out that it wasn’t that easy to answer – if at all.

Note that this post is one of many related to IPv6. Click here for a structured list.

Which ports are in the listening state? –> For this question I used netstat -tulpen for a couple of years now. It turned out, that netstat is kind of deprecated and that I should use ss for this. Same options: ss -tulpen:

  • t: TCP
  • u: UDP
  • l: listening
  • p: show the corresponding process
  • e: extended (important, see below)
  • n: numeric, that is: not resolving IP addresses (DNS PTR records) nor service names (“22” instead of “ssh”)

So, what’s the deal now?

While some processes/services are opening an IPv6 socket and an independent IPv4 socket, some others are opening one single socket shown as IPv6, while listening on both Internet Protocols.

In my case, I was trying to verify whether or not syslog-ng is listening on both IPs. I already knew that my SSH daemon was listening on both protocols. So this was the output (sorry, you have to scroll horizontally):

–> At a first glance, it looks like ssh is running for IPv4 and IPv6, while syslog-ng shows only one line here. In fact, it IS listening on both Internet Protocols as well. Note the “v6only:0” at the end which implies that this socket is also capable of IPv4. The IPv6 line from ssh reads “v6only:1” at the end. (This is what the -e option is all about.)

In case you’re using netstat, this is the output there. It shows “tcp6” for syslog-ng which is even more inaccurate as it implies “only v6” to my mind:

It’s even getting weirder when listing IPv4 services only, because it does not show the “v6only:0” line at all, hence omitting the syslog-ng daemon completely, while it IS listening on IPv4:

Twitter user Flüpke gave the following explanation: “Sockets bound to in6addr_any on Linux will receive IPv4 mapped traffic if the sockopt IPV6_V6ONLY is not set”. Uh, okay.

Note that this is not a specific “problem” from syslog-ng, but a generic approach on how to open sockets. Some years ago I encountered the same behaviour with ntopng.

By the way: Since I was really unsure whether the ports are open or not, I used Nmap from a machine in the same layer 3 subnet to check for both Internet Protocols:

To top it off

I wanted syslog-ng to listen on UDP and TCP on both Internet Protocols. Using this source statement:

I was able to get this:

But in the meantime, I recognized that my IPv4 machines (that send syslog message) were listed as “::ffff:” and so on in my syslog folders. Twitter user Armin brought me to this RFC section “Compatibility with IPv4 Nodes”.

Then I tried to open the IPv4/IPv6 ports independently, which succeeded for UDP but not for TCP:

Ouch. To my mind, this was incorrect anyway, since the second line shows “v6only:0” hence there were two different UDP sockets opened, both capable of IPv4.

Thanks to Twitter Users!

Thanks to my Twitter followers, who helped me out with this question. In the end, “I know that I know nothing”. Even after figuring it out for a couple of hours, I am not quite sure whether I understood it correctly… Any concerns from your site? Please leave a comment!

Photo by Franco Antonio Giovanella on Unsplash.

2 thoughts on “Services listening on IPv6 and IPv4 (or maybe not?)

  1. Johannes,

    Thank you for documenting the inability of different applications to successfully document:
    – Single application mapping to
    – Multiple L2 mappings to
    – Multiple L3 protocol(s) to
    – Multiple L4 protocol and ports

    The problems fall into three categories:
    – The developer’s choice of library, sockets options code implementation and the trusting in existing code
    – Different applications were developed based on older RFC’s and not rewritten to the IETF IPv6 standard 86. Also known as RFC8200.
    – Confusion and inconsistency on how relationships map between the application, multiple interfaces, L2, L3, multiple L3 identifiers, and L4 protocols in a way that makes it easy to understand.

    This impacts network and security applications which depend on these operating system commands. It also creates incomplete data representations, increasing the complexity and confusion in NOC’s, SOC’s and the help desk.

    Little bit of background, for the last 18 years I have attended multiple network and security conferences, walking booth to booth discussing IPv6 findings on their products. I have now given up, providing free help to security companies including the unicorns.

    Interesting enough, one of the companies attempted to contact me about how great their product is. A unicorn company which does not support IPv6 on their own Internet services, nor in their helpdesk documentation. Sad, spoke to them multiple times about the issue.

    Again, thank you for being exposed this long ignored problem!

    Joe Klein

  2. I’d like to add that the default setting for ip6only is controlled via the kernel tunable net.ipv6.bindv6only (the default being 0).

    The idea is to simplify configuration: many applications simply listening on port X will work dual-stack out of the box.

    What catches many by surprise as well is that one has to maintain a dedicated list of firewall rules for IPv6, see ip6tables. If traffic is dropped by default in iptables, the same does not automatically apply to ip6tables.

Leave a Reply

Your email address will not be published. Required fields are marked *