Back to Basics: Unnumbered IPv4 Interfaces

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)1
  • 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.
Using LAN addresses for remote nodes

Using LAN addresses for remote nodes

  • 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)2.

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.

Using LAN addresses on point-to-point router links

Using LAN addresses on point-to-point router links

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 fails3.

Unlike hosts, most traditional network devices don’t use the 127.0.0.0/8 subnet on loopback interfaces. The loopback interfaces usually use regular IP addresses.

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 address4. 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

Revision History

2024-08-13
Explained the reasons behind borrowing an IP address from a loopback interface

  1. Instead of pre-reserving IP addresses, the dial-in server could get the on-LAN IP address based on the user dialing in and try to grab it with ARP. ↩︎

  2. I found an ancient document describing how SLIP and PPP worked over “high-speed modems” with bandwidth “typically less than 20 kbps”. Enjoy ;) ↩︎

  3. As long as the network device works, after that, you have bigger problems. ↩︎

  4. Or whatever hack they’re using to generate what looks like a MAC address for virtual interfaces like tunnels – OSX uses some random **** ↩︎

Latest blog posts in Unnumbered IPv4 Interfaces series

2 comments:

  1. Hey Ivan, thank you for this series on unnumbered interfaces! Can you please say more about the "loopback interface hack" you mentioned in this post (and also in Back to Basics: The History of IP Interface Addresses and Packet Forwarding and Routing over Unnumbered Interfaces)?

    I may be totally off the mark here, but is the "loopback interface hack" about repurposing an address from the 127.0.0.0/8 space as a routable address for a point-to-point link, and modifying the corresponding routing table entries to route traffic to such address(es) differently?

    Here's an illustration of what I mean: https://excalidraw.com/#json=9GRLGN0jn6N6kqMtFL0Aq,KX21Aet2Luct85DDPbhPPw

    Replies
    1. No, I had something completely different in mind. Will add the explanation(s) to the blog posts.

  2. Thank you for adding the explanation! For posterity, I'm cross-referencing it from this comment thread: The "loopback interface hack" is explained in the August 13, 2024 addition to Back to Basics: The History of IP Interface Addresses.

Add comment
Sidebar