I thought that the loopback IP address of my machine is 127.0.0.1.
I do not understand why am I able to ping IP addresses until 127.255.255.254.
2 Answers
The entire address block 127.0.0.0/8 is the block of loopback addresses for a host. There are RFCs that explain this.
The goes back at least as far as RFC 990, ASSIGNED NUMBERS:
The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere.
RFC 1122, Requirements for Internet Hosts -- Communication Layers:
(g) { 127, }
Internal host loopback address. Addresses of this form MUST NOT appear outside a host.
Also RFC 3330, Special-Use IPv4 Addresses:
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].
answered Oct 2, 2017 at 8:10
To answer the OP's Q: "why am I able to ping IP addresses until 127.255.255.254"? (which is a dup of https://serverfault.com/questions/360283/loopback-interface-on-linux-catches-all-loopback-traffic)
A: the early RFCs were ambiguous, Linux and apparently Windows interpreted them to mean "the host should respond on all loopback addresses. BSD - and thus macOS - use the "only 127.0.0.1/32" interpretation.
Aside: Linux's systemd relies on this behaviour - its systemd-resolved local stub listener receives requests via the loopback interface and filters out anything other than 127.0.0.53 or 127.0.0.54 (ref. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html). At no point are the IP addresses 127.0.0.53 or 127.0.0.54 configured on lo.
-
RFC 1700 was not the original source for the entire block being the loopback block. It goes back at least as far as RFC 990 ("...a datagram sent by a higher level protocol to a network 127 address should loop back inside the host.") where it is clear that a packet sent to any address in the old Class A
127(127.0.0.0/8) is to loop back inside the host. See my answer on this.– Ron Maupin ♦Aug 24, 2022 at 11:41 -
Ack; I'll amend the answer's second para to "The early RFCs were ambiguous, Linux and apparently Windows interpreted them to mean "the host should respond on all loopback addresses"; BSD - and thus macOS - use the "only 127.0.0.1/32" interpretation.– Ben LAug 25, 2022 at 12:33
-
systemd relies on this behaviour: Why? It would also be possible that only the "used" addresses (127.0.0.1, 127.0.0.53 and 127.0.0.54) respond to an ICMP echo request - or even to implement TCP/IP in a way that
pingis not supported for localhost at all. Sep 1, 2022 at 12:52 -
Your last paragraph doesn't match the behaviour of systemd-resolved (v250.8) on my system.
systemd-resolvedbind()s only to those two specific addresses, so it never gets to see any other traffic going to 53/udp on the loopback interface. I have just verified that usingstrace.– TooTeaSep 12, 2022 at 11:05 -
TBH, I didn't reverse engineer this, rather I'm going mainly by a cursory examination of systemd's source: if I'm reading it right systemd-resolved has a "bind to interface and filter only valid addresses" approach. e.g. github.com/systemd/systemd/blob/v251/src/basic/…, and github.com/systemd/systemd/blob/v251/src/resolve/… There's also use of IP_FREEBIND in there too. So, "it's complicated" ;-) The main point I was trying to make was that at no point are the IP addresses 127.0.0.53 or 127.0.0.54 configured on the
lointerface.– Ben LSep 13, 2022 at 12:49
localhostresolves to 127.0.0.1 which is the most commonly used IPv4 loopback address.loopback IP addresses, NOT local.