3 ms·
Most deployments only use 127.0.0.1/32. Some niche cases use 127.0.0.0/24. Vanishingly few use more than that. Keep the /24 reserved for local use, and repur
by greyface- 2y ago
Most deployments only use 127.0.0.1/32. Some niche cases use 127.0.0.0/24. Vanishingly few use more than that. Keep the /24 reserved for local use, and repurpose the rest for global unicast.
- loeg 2y agoMacOS gives the loopback 127.0/8: inet 127.0.0.1 netmask 0xff000000 As does Linux (Fedora): inet 127.0.0.1 netmask 255.0.0.0
- greyface- 2y agoThe whole /8 is "on-net" for the loopback interface, but that doesn't mean it's usable to applications. On macOS, I can't ping or bind to 127.0.0.2, for example. Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here.
- akira2501 2y ago> I can't ping or bind to 127.0.0.2, for example. You can as soon as you define it as an alias. > Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here. Per the RFC: "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."
- greyface- 2y agoYes, exactly. If I connect a physical loopback adapter to a network interface, I can't just ping any on-net address and expect a response. I need to add it as an explicit interface address/alias first. Just because the packet loops back on the interface doesn't mean that it will then be treated as if it were addressed to the host. Linux special-cases 127/8 on the virtual loopback interface and will treat all looped-back packets as if they were addressed to the host, even when the destination isn't explicitly configured as an alias. This behavior is not required by the quote from RFC3330.
- RKearney 2y ago> On macOS, I can't ping or bind to 127.0.0.2 uname -a Darwin LT-JT6692XPXJ 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64 ~ ifconfig lo0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD> ~ ping -c 1 127.0.0.2 PING 127.0.0.2 (127.0.0.2): 56 data bytes --- 127.0.0.2 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss ~ 11s sudo ifconfig lo0 add 127.0.0.2 Password: ~ ping -c 1 127.0.0.2 PING 127.0.0.2 (127.0.0.2): 56 data bytes 64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.824 ms --- 127.0.0.2 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.824/0.824/0.824/nan ms ~ ifconfig lo0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.2 netmask 0xff000000 nd6 options=201<PERFORMNUD,DAD> ~
- benjojo12 2y agosystemd's resolved commonly uses 127.0.0.53, Given the deployment of systemd I would not really call that a niche cases in terms of volume, but I do agree in general that 127.0.0.0/24 would in theory be enough. However the whole discussion on repurposing 127.0.0.0/8 is mostly academic as it will be basically impossible to use reliably
- greyface- 2y agoMy plot to pretend systemd doesn't exist has been foiled once again! Agreed that it would be impractical to actually use these. Maybe for linknets?
- itchyouch 2y agoGive it to someone like Google and I’m sure every corporate ceo will demand that Google.com loads from their infrastructure.
- tgsovlerkhgsel 2y agoExcept someone like Google would likely also want their site to work, and thus I expect them to be unwilling to use such a problematic IP. If any big site (or even better, many big sites together) were willing to go that far, a much better measure would be announcing that they'll go IPv6-only on the next IPv6 day. Just for that day. And then again the next year, but for a week. Then for a month the year after. Then permanently. That would give ISPs the kick in the butt to fix it, because nobody wants their hotline to field a day full of "my Internet doesn't work" calls, only to then have to fix it anyways because otherwise it'll be a week next time.
- hinkley 2y agoDocker desktop also uses 127.0.0.11 for dns
- toast0 2y agoI've used 127.0.0.0/16 for real work[1]. Keeping a /16 is not much cost and helps out a few more niche cases. Although, I guess if it wasn't available, I could have used a /16 in private space that didn't overlap with my existing network. [1] I needed a lot of localhost connections to run a TLS terminator separate from the underlying service which didn't support unix sockets. Using the 127.0.X.0 bits in addressing was very helpful for diversity in the hash used for kernel socket tables, otherwise most slots had few sockets and some slots had way too many and perf was bad. Configuring multiple loopback interfaces using more address space was a lot more tractable than changing the kernel hashing behavior, adding unix socket support to the underlying service, or adding good TLS to the underlying service. Although probably since then all three things have happened.
- nick238 2y agoWhat's the use for multiple local loopback IPs? I'm not a networking guy, just backend dev, so 99.99% of my 127.0... use is running applications locally. For your TLS thing, is it whatever application you were using expected to use a whole swath of TCP ports at whatever IP address, so expected separate IPs? Feels like dedicating some range of addresses to "private use" would have been useful, then if you needed a bunch of local loopbacks, could configure it so, or if your local network wants some magic, tada.