Do 0.0.0.0:0 and *:* represent the same thing?

Solution 1:

It has been pointed out that my answer was in error. Since I cannot delete it, I will instead provide the correct one.

The expression *:* means "Any Address, Any port". All UDP listeners will display this signature. This is due to the connectionless nature of UDP.

Original (incorrect) answer. Yes and no. *:* refers to ANY IPv6 address. The distinction between an unknown/unspecified address is vague in IPv4, so we use 0.0.0.0/0 to represent any host on the network, but in IPv6 there is a subtle difference.

For the most part however, people use :: to represent a contiguous string of 0's.

In an IPv6 address, any sequence of contiguous zeros can be replaced with :: so:

• 0.0.0.0/0 => 0000:0000:0000:0000:0000:0000:0000:0000 => :: => *:*
• fe80:0000:0000:0000:2000:0aff:fea7:0f7c => fe80::2000:0aff:fea7:0f7c

The representation using wildcards however allows a finer control of address patterns. For instance, :: would not match fe80::2000:0aff:fea7:0f7c, but *:* will.

This difference isn't really meaningful to any device that isn't performing routing, but when it comes time to select optimal routes to aggregated address spaces, the wildcard notation allows more flexible selection of destination networks.

Solution 2:

The / refers to the subnet netmask, which is part of the IP Layer.

The : refers to a port which is part of the Transport Layer.

For TCP it makes sense that there is a remote end for a connection.

UDP, since it is connectionless, it doesn't make any sense for it to show a foreign address.

My gut feeling is that it would always show the wildcard for UDP and that it is potentially there to make parsing the output a little more friendly, or to show if you are using IPv4/6:

IPV4 "*:*" vs IPV6 "[::]:*"

Solution 3:

In both cases the information is basically meaningless, but indicates more-or-less the same thing.

Your first line is a TCP listen socket. The local address column indicates the address and port that it's accepting connections on, and the remote address column means nothing because a listen socket has no remote end of the connection yet. A connected TCP socket would show the address of the other end of the connection in that column, but for a listen socket it decides to display an all-zero address and port.

Your second line is a UDP socket. UDP is a connectionless protocol, meaning that it sends and receives packets without any notion of who connected to who, whether the packet is part of an existing conversation, or whether the data just arrived out of the blue. The local address column has the same meaning as it does for TCP, and the remote address column is meaningless because a UDP socket could have one peer, many peers, or no peers at any moment. (Actually POSIX has the notion of a "connected UDP socket" but that's getting a bit far afield).

Now the question: why do they display differently? It seems to be nothing more than a quirk of the Windows netstat code. Linux (net-tools) netstat displays 0.0.0.0:* for the remote end of both TCP listen sockets and UDP sockets (for IPv4; it displays :::* for IPv6), which is different from either example on Windows, but at least it's consistent within the same program. Perhaps Windows is going for a semantic distinction between "to be filled in later" in the case of TCP and "open to anything" in the case of UDP, but just as likely the two bits of code were written by two different people with no particular concern for consistency.

Solution 4:

The difference is simply notational.

Netstat in Windows uses 0.0.0.0:0 to represent an abstract idea of "any remote address and port" for a local IPv4 TCP listener and *:* for a UDP listener. For IPv6, the remote address is denoted by [::]:0 for TCP and *:* for UDP.

In OS X, *.* is used for both TCP and UDP, whether IPv4 or IPv6 (note that OS X uses dots to separate address and port). Linux uses 0.0.0.0:* for IPv4 and :::* for IPv6, with the first two colons representing the abbreviation for all IPv6 address and the third colon the separator between the address and the port.

IIRC from something I heard or read long ago, I think UDP pairings can show up, but usually don't because they are torn down upon completion and UDP connections are usually very short, lasting milliseconds or less. I've never seen this myself, though, so it could be incorrect.