I'm running the example in hiredis, which is using "127.0.0.2" as the redis server IP, and it is running properly. Actually, the redis server is running on the same machine. I know that "127.0.0.1" is the IP address of "lo", but how about "127.0.0.2"? Is it the same as "127.0.0.1"?
IPv4 network standards reserve the entire 127.0.0.0/8 address block for loopback purposes. That means any packet sent to one of those 16,777,214 addresses (127.0.0.1 through 127.255.255.254) is looped back. IPv6 has just a single address, ::1.
Various Internet Engineering Task Force (IETF) standards reserve the IPv4 address block 127.0.0.0/8, in CIDR notation and the IPv6 address ::1 for this purpose. The most common IPv4 address used is 127.0.0.1. Commonly these loopback addresses are mapped to the hostnames, localhost or loopback.
or from the RFC itself:
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].
For fun, try by pinging:
$ ping 127.127.127.127 PING 127.127.127.127 (127.127.127.127) 56(84) bytes of data. 64 bytes from 127.127.127.127: icmp_req=1 ttl=64 time=0.110 ms 64 bytes from 127.127.127.127: icmp_req=2 ttl=64 time=0.065 ms ^C --- 127.127.127.127 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.065/0.087/0.110/0.024 ms
- “Are all
127.x.x.xaddresses restricted to the local machine?” Yes
- “Are all
127.x.x.xaddresses bound to the
127.x.x.xaddresses routed over the network?” No
- “Are all 127.x.x.x addresses the same?” No (depending on operating system)
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 loops back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback. As described in [RFC1122], Section 220.127.116.11, addresses within the entire 127.0.0.0/8 block do not legitimately appear on any network anywhere. — RFC5735 Emphasis mine.
127.0.0.2the same as
127.0.0.1?” NO According to rfc5735 it may be, but it does not have to be. This is an implementation defined behaviour. See your operating system manual. In any case the whole range is reserved, and must not be routed over a network.
127.255.255.254 are all local addresses bound to interface
lo. They are not the same. You can use each address to bind a different service onto the same port. E.g 16 Million web-servers on port 80, only accessible from the local machine (If you don't run out of memory, or other resource first)
I have just set up a docker service to bind to
127.0.0.2:80. I have then added an alias to
/etc/hosts. Now I can connect to it via
http://myserver, but not via
http://localhost. However it is only available to this machine. As it is, only, on the
I then set up another docker service to bind to
127.0.0.3:80, and a python service on
localhost:80 and another on
This may not work on all operating systems.
I am using Debian(9) Gnu/Linux, Linux kernel 4.9.0-3-amd64. Some OSs may treat all addresses
127.255.255.254 the same. Some may only work with
Note services such as ping will be listening on 0.0.0.0 (ipv4) so
ping 127.127.127.127 will be received by the listener, because
127.127.127.127 is one of your addresses. However if a service listens on a specific address, then you need to use this specific address to connect to it (Depending on operating system used).
Not a comprehensive general answer (there's one already). This answer of mine shows an example where
127.0.0.2 was used to solve the problem.
The OP there attempted to test some software in a case when its connection to a server was rejected. This was done on the server by a temporary
iptables rule that rejects all traffic from the client IP. The client was immediately able to "see" the connection was rejected.
The problem appeared when this person moved the server software to the same machine as the client and tried to use loopback interface. The rule was set to block communication from
127.0.0.1 but the information a connection was rejected underwent the same rule and never got to the client software which hanged (presumably till timeout).
The solution was to use
127.0.0.2 as the server address and set a rule that rejects connections to it. The information about a rejection went to
127.0.0.1 and was able to pass to the client software.