4

On a linux machine with a normal loopback interface:

$ ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:36621784 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36621784 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6752024976 (6.2 GiB)  TX bytes:6752024976 (6.2 GiB)

when I ping any add address in the range 127.0.0.0/8 I get a response back:

$ ping -c1 127.7.23.4
PING 127.7.23.4 (127.7.23.4) 56(84) bytes of data.
64 bytes from 127.7.23.4: icmp_seq=1 ttl=64 time=0.045 ms

--- 127.7.23.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms

This behaviour is particular to Linux as I don't see it on my Mac OS X Lion machine. I don't have any IP aliases setup for the loopback interface which is what I would have expected todo to have this work.

Why is this happening and is it the expected behaviour?

3 Answers 3

6

Windows has this behaviour too. I guess this is different interpretations of rfc 3330

127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere [RFC1700, page 5].

It looks like Linux interprets this as meaning that any (even an unconfigured address) in the 127.0.0.0/8 range should be looped back and thence you get a response from ping.

2
  • I can see that routing means that 127.0.0.0/8 should alway go to the loopback interface, but what I found strange is that Linux responds to ICMP echo requests for all of these addresses rather than just the one the interface is configured for. Feb 15, 2012 at 10:02
  • 2
    RFC 3330 was obsoleted by RFC 5735, which changes the necessity of this behavior from "should" to "does". Which means the Linux and Windows implementations are correct and everyone else is wrong. Or perhaps they defined the standard. Who knows? Apr 3, 2013 at 7:51
5

The behavior is documented in RFC 1700. 127.7.23.4 is also a loopback address and also assigned to the local machine. (What else would it be assigned to?)

IP-address ::= { <Network-number>, <Host-number> }
...
{127, <any>}
Internal host loopback address. Should never appear outside a host.

There is no requirement to make all addresses in this range work, but it's particularly handy when dealing with protocols that don't permit you to specify a port but only an IP address. Having multiple local IP addresses allows you to run multiple instances of those servers for local use.

1

This is indeed specific to Linux (and maybe other OS).

But when you read either the RFC 1700 or the lo netmask setting, the loopback network should be considered an A class.

For your information:

  • BSD boxes (as Mac OS X), are limited to 127.0.0.1/32 (that is only 127.0.0.1, as per RFC 3300 - september 2002).

  • Windows box respond to 127.0.0.0/8 (that is from 127.0.0.1 to 127.254.255.255).

So, this time it seems that Windows was right (until 2002) ;)

3
  • 127.0.0.0/24 is 127.0.0.0-127.0.0.255, despite what you have written above.
    – MadHatter
    Feb 15, 2012 at 10:01
  • My Max OS X box still has a netmask of /8 I think: inet 127.0.0.1 netmask 0xff000000 Feb 15, 2012 at 10:05
  • As per Linux with its 255.0.0.0, still you cannot ping 127.5.6.1.
    – Ouki
    Feb 15, 2012 at 10:14

You must log in to answer this question.

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