4 ms·

Great article, thank you for enlightening us. > While there are somewhat ongoing efforts to see 0.0.0.0/8, 127.0.0.0/8 become routable unicast space I am curi

Great article, thank you for enlightening us. > While there are somewhat ongoing efforts to see 0.0.0.0/8, 127.0.0.0/8 become routable unicast space I am curious about this statement. How can 127/8 ever become internet routable? It is after all used for the local host. Or am I misunderstanding something here?

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 ago
  MacOS 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 ago
    The 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 ago
        Yes, 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 ago
  systemd'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 ago
    My 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 ago
    Give it to someone like Google and I’m sure every corporate ceo will demand that Google.com loads from their infrastructure.
    - tgsovlerkhgsel 2y ago
      Except 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 ago
  Docker desktop also uses 127.0.0.11 for dns
- toast0 2y ago
  I'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 ago
    What'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.
themoonisachees 2y ago
I think the intent comes from the fact that most people never use any other address that 127.0.0.1 (yes, I know about docker DNS). It sort of comes across as if you were "wasting" a large block of adresses on functions that are seldom used. In reality though, this isn't a solution and we should really just go forwards with ipv6.
zie 2y ago
Where there is a will, there is a way. Off the top of my head, most localhosts stay within 127.0.0.X/24, so one could slowly peel off the top parts of the /8 until we start encroaching too closely on the /24 most people tend to stick to. Sometimes you see 127.0.1.X/24. I've even seen 127.1.X.X around, but I've never seen 127.254.X.X around. I'm sure someone somewhere did it just for grins and giggles or something though.
bewaretheirs 2y ago
The same way that 240/4 can become internet routable: a global effort to change defaults and push code and configuration changes everywhere over the next two decades. It isn't all in use on most machines. Many hosts only use 127.0.0.1/32 and do not use the rest of the space; changing the default netmask on the loopback interface from /8 to something like /24 would be one step of the transition. Like 240/8 it's probably not worth the effort.
obscurette 2y ago
The current proposal is to reduce loopback subnet size from /8 to /16 - https://github.com/schoen/unicast-extensions/blob/master/127.md https://github.com/schoen/unicast-extensions/blob/master/127... I think that it's the most problematic proposal from all these – unlike 240/4 etc every ip stack on earth has hardcoded knowledge about 127/8 for sure and it will took at least decades to deprecate all these. And I also have seen addresses other than 127.0.0.x used in wild. As far as I understood, some orchestration systems use generated 127.x.x.x addresses to avoid conflicts between applications. Linux makes it very easy – you just bind an application to 127.45.2.189 for example and it just works. There is no need to add it to the interface or something.

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 ago
MacOS 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 ago
  The 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 ago
      Yes, 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 ago
systemd'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 ago
  My 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 ago
  Give it to someone like Google and I’m sure every corporate ceo will demand that Google.com loads from their infrastructure.
  - tgsovlerkhgsel 2y ago
    Except 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 ago
Docker desktop also uses 127.0.0.11 for dns
toast0 2y ago
I'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 ago
  What'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.

themoonisachees 2y ago

I think the intent comes from the fact that most people never use any other address that 127.0.0.1 (yes, I know about docker DNS). It sort of comes across as if you were "wasting" a large block of adresses on functions that are seldom used. In reality though, this isn't a solution and we should really just go forwards with ipv6.

zie 2y ago

Where there is a will, there is a way. Off the top of my head, most localhosts stay within 127.0.0.X/24, so one could slowly peel off the top parts of the /8 until we start encroaching too closely on the /24 most people tend to stick to. Sometimes you see 127.0.1.X/24. I've even seen 127.1.X.X around, but I've never seen 127.254.X.X around. I'm sure someone somewhere did it just for grins and giggles or something though.

bewaretheirs 2y ago

The same way that 240/4 can become internet routable: a global effort to change defaults and push code and configuration changes everywhere over the next two decades. It isn't all in use on most machines. Many hosts only use 127.0.0.1/32 and do not use the rest of the space; changing the default netmask on the loopback interface from /8 to something like /24 would be one step of the transition. Like 240/8 it's probably not worth the effort.

obscurette 2y ago

The current proposal is to reduce loopback subnet size from /8 to /16 - https://github.com/schoen/unicast-extensions/blob/master/127.md https://github.com/schoen/unicast-extensions/blob/master/127... I think that it's the most problematic proposal from all these – unlike 240/4 etc every ip stack on earth has hardcoded knowledge about 127/8 for sure and it will took at least decades to deprecate all these. And I also have seen addresses other than 127.0.0.x used in wild. As far as I understood, some orchestration systems use generated 127.x.x.x addresses to avoid conflicts between applications. Linux makes it very easy – you just bind an application to 127.45.2.189 for example and it just works. There is no need to add it to the interface or something.