In the previous blog post in this series, we explored some of the reasons IP uses per-interface (and not per-node) IP addresses. That model worked well when routers had few interfaces and mostly routed between a few LAN segments (often large subnets of a Class A network assigned to an academic institution) and a few WAN uplinks. In those days, the WAN networks were frequently implemented with non-IP technologies like Frame Relay or ATM (with an occasional pinch of X.25).

The first sign of troubles in paradise probably occurred when someone wanted to use a dial-up modem to connect to a LAN segment. What subnet (and IP address) do you assign to the dial-up connection, and how do you tell the other end what to use? Also, what do you do when you want to have a bank of modems and dozens of people dialing in?

The history of networking is full of dirty hacks (I’m looking at you, long-distance vMotion), and the initial dial-up solutions were no different:

• Grab a bunch of LAN IP addresses, and enter them as RESERVED in the shared Excel spreadsheet (or whatever we were using in those days)¹
• Pretend all these addresses belong to the dial-in server and are connected directly to the LAN segment. Whenever someone asks for the MAC address of one of those addresses, respond with the MAC address of the dial-in server (we might call that proxy-ARP today).
• Assign an IP address from the RESERVED range to each modem port. Create an equivalent to host routes pointing to modem ports for those IP addresses, either in advance or when a user dials in.

• Somehow communicate to the remote end what IP address it should use after dialing in. PPP had proper network-layer negotiation, and SLIP clients used all sorts of dirty hacks parsing the text printed by the dial-in server before it started SLIP (hint: screen scraping of CLI printouts has been around forever)².

Let’s see how the traffic would flow between a remote computer (dial-in client) and a server somewhere on the Internet:

• The remote computer would have a default route pointing to the dial-up connection. All packets generated by that node would be sent over the dial-up connection to the dial-in server, which would forward them using the regular routing tables.
• The remote computer would appear to be attached to the LAN segment. Any upstream server or router would send an ARP request, get the dial-in server’s MAC address as the final MAC address, and send the packet to the dial-in server.
• The dial-in server would forward the packet to the remote computer using one of the static host routes.

Once we got that hack in place, extending it to point-to-point router links was trivial. Just borrow an IP address from another interface and use it when sending packets to the WAN link. If needed, use static routes pointing to WAN links. Problem solved.

Later iterations of the same hack included support for loopback addresses as the source of the shared IP address[^WWNL], routing protocols running over unnumbered serial interfaces, dynamic address assignment from local or shared address pools, unnumbered VLAN interfaces, unnumbered point-to-point LAN links, running routing protocols over unnumbered LAN links, establishing BGP sessions over them…

Digression: Why Do We Need Loopback Interfaces?

Linux happily accepts the same IP address configured on multiple interfaces. Most network devices don’t like that idea; you have to configure an IP address on an interface and then tell the device that other interfaces are using the IP address from that other interface.

That’s dangerous; if the interface carrying the original IP address fails, all related interfaces lose their borrowed IP addresses. The only way to make this approach stable is to configure the shared (global) IP address on a loopback interface, as the loopback interface never fails³.

Linux-based network devices use various approaches to deal with the built-in Linux loopback interface. For example, Arista cEOS containers:

• Keep the built-in lo interface, but do not show it to the user. The Loopback0 EOS interface maps into the Linux lo0 interface.
• Keep the 127.0.0.0/8 subnet in the underlying Linux kernel routing table, but do not copy it into the EOS routing table.

Why Do We Care?

It looks like we’re discussing ancient history, but it’s 2021, and unnumbered IPv4 interfaces are as popular as ever. Here are just a few reasons why we still use them:

• We still need dynamic IP addresses for dial-up connections (PPPoE, LTE…)
• Sometimes, we care about the amount of IPv4 address space used, and wasting subnets on point-to-point links seems… wasteful.
• Even if we don’t care about IPv4 address utilization, we still have to allocate and track those small subnets. Having duplicate subnets scattered around an extensive network often results in a marvelous troubleshooting exercise.
• Not having IPv4 addresses assigned to interfaces simplifies device configuration, reduces network state (including routing tables), and simplifies network automation.

Meanwhile, on Planet IPv6

IPv6 designers tried to do things THE RIGHT WAY (for whatever direction they thought RIGHT was pointing to). For example, there are no unnumbered interfaces in IPv6 – an IPv6 interface always has a link-local address generated from a fixed prefix and the interface MAC address⁴. As for router-to-router links, RFC 7404 made the obvious conclusion: you should use only link-local addresses inside a routed network.

Wonder how they solved the dial-up challenge? With the “we have an infinite number of bits to play with” mentality, it wasn’t hard to decide that every dial-up connection deserves a dedicated /64 prefix (or worse).

You know, your phone might decide to change its IPv6 address, and it wouldn’t be fair to give it less than a gazillion options to choose from. Some people went as far as suggesting we should give more than one /64 prefix to every dial-up connection (/48, anyone?) because it would look horrible to use the proxy-ARP (now proxy-ND) tricks from the 1980s to implement tethering.

Even More Details

• Want to explore the world of network addressing? Watch this part of How Networks Really Work webinar.
• Interested in IPv6 details? You might find them in our IPv6 webinars and blog posts.

Revision History

2024-08-13

Explained the reasons behind borrowing an IP address from a loopback interface