A ping to responds from However, if I shutdown the localhost loopback and keep another interface up with another ip, then ping gives an error

$ping connect: Invalid argument

Isn't supposed to listen to all interfaces? So basically, how exactly does a binding work from network perspective? how does ping work only for loop-back and not for other interface?

  • Update I have read it elsewhere and got similar answer here (you cannot ping
[anshup@s2 ~]$ ping PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.010 ms
64 bytes from icmp_seq=2 ttl=64 time=0.009 ms
64 bytes from icmp_seq=3 ttl=64 time=0.009 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2551ms
rtt min/avg/max/mdev =
0.009/0.009/0.010/0.002 ms

So what exactly is happening here if we cannot ping, and (re-iterating the question) why does response back only from loop-back and not any other interface on the host?

3 Answers 3

20 is not an address but an network Identity (used for routing, and means 'All Networks'). as such you cannot ping it. if you wanted to ping every system you would use Every network has two special addresses, the Identity, and the Broadcast, usually at .0 and .255 respectively.

for instance on the network, the Identity =, and the broadcast = the first host is, and the last is note that no host may use the Identity or the Broadcast address as their own IP address.

the host default gateway is by definition the route you utilize to reach all unknown networks, so is just a reference to All Networks.

Edit: The reason the loopback is responding is 'undefined' behavior not specified in RFC1700. Per the RFC, an address starting with 0 (when expressed in Decimal) is never allowed as a destination (only as the source of a broadcast packet), so the author of your network stack choose to have the loopback respond.

When I attempt to ping from a Win7/powershell prompt, I simply get the message 'PING: transmit failed. General failure.' so this is clearly behavior specific to a given OS stack, or perhaps even driver-specific. If you provide your OS, we might be able to find more, but it would answer no meaningful questions since its implementation specific behavior not governed by networking standards. My guess is your OS is simply aliasing all invalid addresses as 127.x.y.z addresses.

  • @frank: Thanks for answering. Updating the question to add more info in view of your answer. May 8, 2013 at 12:02
  • @Frank: Thanks for the update/edit answer. That helps. Am on fedora 17. Will check into its implementation. May 9, 2013 at 2:52
  • 9 years later - Just a comment here to confirm for future readers that I'm still seeing the same behavior under Windows 10/11 that you saw under Win7. Nov 30, 2022 at 13:13
  • I should add RFC1700 defines as "this host this network". While it's not a valid destination address for the IP protocol, as per RFC1700, that only matters for packets transmitted on the wire. It does not dictate how an OS handles the address internally. IE the OS can safely allow as a destination address as long as those packets are never emitted by the kernel over the network with as the destination address. May 7 at 18:17

Actual definition of

The address is reserved by IANA for it's definition in RFC 1122 as:

IANA IPv4 Special-Purpose Address Registry... This host on this network [RFC1122], Section

RFC 1122 Section

        (a)  { 0, 0 }

            This host on this network.  MUST NOT be sent, except as
            a source address as part of an initialization procedure
            by which the host learns its own IP address.

Linux's Interpretation

Based on the RFC definition, Linux's use of this address as a target address makes a lot of sense. "This host on this network" has near identical meaning "localhost" (address So when you set as the destination address, Linux will always treat that as being addressed to

Linux is also in keeping with the standard because RFC 1122 says "MUST NOT be sent". Linux isn't sending it. No packet will ever be emitted on the wire with this destination address.

What about meaning all addresses?

That is an alternative interpretation also used by many OS to mean bind to all [my] addresses. This is specifically only used local (source) address when creating listening sockets. Again this never results in packets on the wire.

The connection between "all [my] addresses" and "this host this network, does appear to be a little stretched. However it is common to almost all OS.

The Myth

There is a horrible myth that is:

⚠️ Wikipedia Myth: non-routable meta-address used to designate an invalid, unknown or non applicable target

This seems to have come from an incorrect wikipedia page (now corrected) and appears to have gained a lot of traction through people copy-pasting the same words into blogs and Stack Exchange answers.


In the Internet Protocol version 4 the address is a non-routable meta-address used to designate an invalid, unknown or non applicable target.

  • 1
    I've read this same set of words so many times across many blogs and answers. Yet I can find no reference in any RFC to the words "invalid, unknown or non applicable target". I'd love to know what documentation uses these words, or if they're just a pervasive myth spread by many blogs. To be clear, in the Internet Protocol version 4, is named this host on this network (RFC 1122) Nov 30, 2022 at 22:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .