⚡ TL;DR

For the foreseeable future, you can likely use 127.0.0.0/8 freely (or at least 127.0.0.0/16).

Introducing 127.0.0.0/8, the Loopback Range

If you have ever done web development or otherwise set up a local server, you have most likely used the IP address 127.0.0.1 to communicate with a local server. Often, localhost is even internally translated to that address. But what if you want to run another server on the same computer? Easy, make the first one use, say, port 8080 and the second one, port 8181!

Something more difficult now: say you can convince¹ your browser that your local service is serving a valid HTTPS connection only if you use port number 443. How can you run many of those services? In turns out in IPv4, you have many such local addresses: 127.0.0.1, 127.0.0.2, 127.0.0.3, 127.0.0.4… So you just need to spawn the various servers on the same 443 port number with different addresses and packets will go straight to your localhost.

But how many such addresses do we have? According to RFC990 from 1986:

The “class A network” translate to a /8 in CIDR notation, so that’s all addresses between 127.0.0.0 and 127.255.255.255. A quite sizeable 2²⁴ or 16,777,216 addresses²!

Note the wording of the RFC: IPs are not “owned”, there are just “allocated”. For addresses routable on the wider Internet, it’s usually done by Regional Internet Registeries. And allocations could change, as we will see at the end of this article.

Other Use Cases

What can you do with so many IPs? A couple of things.

Multiple Servers on the Same Port Number

As we have seen earlier with the port number 443 example, the 127.0.0.0/8 range is handy to run multiple local services on the same port. Thus, it’s not surprising to see systemd-resolved – a local DNS resolver that needs to listen on port 53 – use a couple addresses from that range. The man page reads:

In this case, systemd-resolved has to bind on the default port, because one of the main ways (on Unix-like systems) that DNS resolution is configured is through the file /etc/resolv.conf. This file does not widely support setting a port number, forcing the configured server to be reachable on the default port. Thanks to the use of a loopback addresse though, systemd-resolved can become the default resolver just by adding this line to resolv.conf:

nameserver 127.0.0.53

Naming Things

On Unix-like systems, the /etc/hosts file associates IP addresses with names, like so:

127.0.0.1	localhost
::1		localhost

That’s how localhost is associated with 127.0.0.1 (and IPv6 ::1).

You can edit this file and add useful aliases to other IPs (not necessarily in the local range by the way). Then, you just bind your multiple services to their default ports and access to them by name. No more complicated ports to remember! This benefit comes as a byproduct of using default ports but with different IPs for different services.

For instance, you could name one of the aforementioned systemd-resolved IPs by adding this line to /etc/hosts:

127.0.0.1	localhost
::1		localhost

127.0.0.53	sd

And then query it like so:

dig @sd s.cj.rs

instead of

dig @127.0.0.53 s.cj.rs

if you did not have the setting.

I’m using this trick to make the Syncthing web interface accessible on a memorable port on an address with a memorable name in my web browser.

Future of 127.0.0.0/8

Even if the ability to give various services different IPs is handy, 16 milion addresses is huge. Given how IPv4 is sometimes called “internet real-estate”, there have been discussions to drastically limit the size of this loopback range, and use some of it as “normal” IPs. For instance, this IETF draft proposes to cut the loopback range to 127.0.0.0/16 (so only addresses between 127.0.0.0 and 127.0.255.255) and make the rest (addresses between 127.1.0.0 and 127.255.255.255) routable on the public internet. The 65536 addresses in 127.0.0.0/16 should to be enough for almost everyone on a local machine and nearly 16 million IPs could be used as a fresh supply of IPv4 addresses³.

And IPv6?

Even though IPv6 has a huge namespace, your IPv6 loopback only has one address ::1. And that’s quite a shame because, as we have just seen, multiple loopback addresses are quite handy.

1. Make sure you are on the branch of the pull request (for instance, by reading the output of git status)
2. Edit and save your file, removing the white space.
3. Then in your terminal, use:

   git commit --amend -a -v -C HEAD
   

   This edits (--amend) your last commit, adding all the changes made to files (-a) and reusing the last commit message (-C HEAD). Once this is done, a summary is printed (-v).
4. You can now push your changes with:

   git push --force-with-lease
   

   We need --force-with-lease to “confirm to the server that we really want to edit the last commit”.

Caution

Two words of caution with this technique:

• you are rewriting history, if anyone has made changes on top of yours, they will face a confusing situation when they try to merge your changes again. force-with-lease protects us somewhat, as the push will fail if someone else has pushed changes on top of ours, but it won’t help if the other person’s changes are local.
• in most situations, commit messages (and their content), should be crafted as an easy to review progression. Abusing this trick could make commits harder to review.

ℹ️ Note

2023-05-20: Updated to account for the features of NeoVim 0.9 and obsolete plugins

You have found a (Neo)Vim plugin that you want to fiddle with, either to contribute changes upstream or for your own use. Sounds familiar? Here are some tips and tricks I use for my NeoVim plugin development. The aim of these small tricks is to iterate faster on changes, by loading your changes in a live NeoVim instance as quickly as possible.

We will use telescope-repo.nvim as an example but it is applicable to any plugin (although some sections of this post only apply to Lua NeoVim plugins).

Load Local Plugin Version

When developing, you make your changes to a local git repository, for instance ~/ghq/github.com/cljoly/telescope-repo.nvim. To test those changes, you need to tell NeoVim to load the plugin from the local repository, instead of using the location set by your plugin manager. To do this, just append the following near the beginning of your init.lua file:

vim.opt.runtimepath:prepend("~/ghq/github.com/cljoly/telescope-repo.nvim")

Note the :prepend. It will ensure that your local dev version will override anything installed by your nvim package manager. This way no need to uninstall your plugin when developing!

Reloading Changes in a Live NeoVim Instance

You have now made some changes to the plugin that you would like to test. In doing so, you start a second NeoVim instance and open a set of files, change a bunch of settings…

You then change something in the code, but you don’t want to restart you test NeoVim instance, as that would mean reopening files and altering settings all over again. But just doing require(…) is not enough, because require caches already loaded files and doesn’t reload them if they are loaded already.

If you use telescope, you can use the reloader picker. You can then select the module you want to reload, like so:

Under the hood, telescope reload uses plenary:

require("plenary.reload").reload_module(selection.value)

which handle various cases (like whether impatient.nvim is used at the time of writing). Despite this careful handling, sometimes, a plugin may not fully reload. In that case, you want to automate as much of the setup as possible on NeoVim restart.

If All Else Fails

Sometimes, a “soft” reloading is not enough and you need to restart NeoVim. For instance, if we are testing the :Telescope repo list command and need to open /tmp/file, we can do:

nvim +'Telescope repo list' /tmp/file

and even place this in an infinite loop with a sleep command, to escape the loop more easily once we are done.

Of course, you will want to replace Telescope repo list with the command you want to test. You can also add more setup by supplying multiple “+'…'” arguments)

All Set

Now that you are all set, you can go on and write complete plugins! You may find the following resources useful in your journey:

• the :help lua-guide.txt has a lot of resources to write plugins and alter NeoVim’s configuration,
  • 2n.pl walks through writing a simple plugin,
• set up a Language Server Protocol for Lua,
  • and maybe even a full-blown plugin for Lua plugin development,
• to test a piece of Lua code real quick, :=my.lua.code(here) is great. For bigger pieces of code, luapad can be useful: it provides a scratch buffer where the result of a Lua snippet is displayed as you type.