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 often 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 that 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 out 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 use the regular routing tables to forward them.
• The remote computer would appear to be attached to the LAN segment. Any upstream server or router would send an ARP request, get the MAC address of the dial-in server as the final MAC address, and send the packet to the dial-in server.
• The dial-in server would use one of the static host routes to forward the packet to the remote computer.

Once we got that hack in place, it was easy to extend it to point-to-point router links. 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, 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…

Why Do We Care?

It looks like we’re discussing ancient history, but it’s 2021, and unnumbered IPv4 interfaces are as popular as they ever were. 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 those small subnets and keep track of them. Having duplicate subnets scattered around an extensive network makes for 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 it wants 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.