Windows – Why is there a difference between ping “localhost” and ping “local IP address”?

Using cmd and ping on Windows gave me the following results:

• Pinging “localhost”:

• Pinging “192.168.0.10” (local IP address):

Aren’t both situations exactly the same?

I mean, I’m pinging the same interface, the same machine and the same address. Why do I get such different results?

EDIT: Here is my ipconfig /all screen:

Solution:

You are not pinging the same interface, without any physical interfaces you still have a "local host".

Your localhost is used to refer to your computer from its "internal" IP, not from any "external" IPs of your computer. So, the ping packets don’t pass through any physical network interface; only through a virtual loop back interface which directly sends the packets from port to port without any physical hops.

You might still wonder why localhost is resolving to ::1, while traditionally we would expect it to resolve to the IPv4 address 127.0.0.1. Note that .localhost is traditionally a TLD (see RFC 2606) which points back to the loop back IP address (for IPv4, see RFC 3330, especially 127.0.0.0/8).

Looking up localhost using nslookup gives us:

nslookup localhost

...Name:    localhostAddresses:  ::1          127.0.0.1

Thus Windows prefers to use the IPv6 loop back IP address ::1 (see RFC 2373) as it is listed first.

Okay, so, where does it come from, let’s look at the hosts file.

type %WINDIR%System32DriversEtcHosts

...# localhost name resolution is handled within DNS itself.#       127.0.0.1       localhost#       ::1             localhost...

Hmm, we have to look at the DNS settings of Windows.

This KB article tells us about a setting that affects what Windows prefers, emphasized in bold:

1. In Registry Editor, locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip6Parameters

2. Double-click DisabledComponents to modify the DisabledComponents entry.

   Note: If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:

   1. In the Edit menu, point to New, and then click DWORD (32-bit) Value.

   2. Type DisabledComponents, and then press ENTER.

   3. Double-click DisabledComponents.

3. Type any one of the following values in the Value data: field to configure the IPv6 protocol to the desired state, and then click OK:

   • Type 0 to enable all IPv6 components. (Windows default setting)
   • Type 0xffffffff to disable all IPv6 components, except the IPv6 loopback interface. This value also configures Windows to prefer using Internet Protocol version 4 (IPv4) over IPv6 by modifying entries in the prefix policy table. For more information, see Source and Destination Address Selection.
   • Type 0x20 to prefer IPv4 over IPv6 by modifying entries in the prefix policy table.
   • Type 0x10 to disable IPv6 on all nontunnel interfaces (on both LAN and Point-to-Point Protocol [PPP] interfaces).
   • Type 0x01 to disable IPv6 on all tunnel interfaces. These include Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo.
   • Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.

4. Restart the computer for this setting to take effect.

What is this prefix policy table?

netsh interface ipv6 show prefixpolicies (or prefixpolicy on earlier versions)

Precedence  Label  Prefix----------  -----  --------------------------------        50      0  ::1/128        45     13  fc00::/7        40      1  ::/0        10      4  ::ffff:0:0/96         7     14  2002::/16         5      5  2001::/32         1     11  fec0::/10         1     12  3ffe::/16         1     10  ::/96

This table decides what prefixes get precedence over other prefixes during DNS resolves.

Ah, so using that KB we could add entries here that denote that IPv4 has higher precedence than IPv6.

Note: There is no reason to override this behavior, unless you are experiencing compatibly problems. Changing this setting on our Windows Server broke our mail server, so it should be handled with care…