← All Posts

Point-to-Point Links: /30 vs /31 vs Unnumbered

Most networks are full of point-to-point links: short connections that sit between exactly two devices, such as a cable joining two routers, or a circuit running from your office to a data center across town. They're the plumbing of any larger network, and every one of them needs IP (Internet Protocol) addressing to function. The interesting question is how many addresses each one actually deserves.

It's a small question with surprisingly large consequences. Multiply it across a network with hundreds of links and you can either save a substantial chunk of address space or waste an embarrassing amount of it. There are three common approaches: a /30, a /31, or an unnumbered interface. Each one is correct in some context, and each one comes with tradeoffs worth understanding before you commit.

A point-to-point link is exactly what the name suggests: a network segment with only two devices on it. The classic example is a circuit between two routers, but the same pattern shows up between firewalls, between switches operating at Layer 3 (the routing layer of the network), and across most wide-area network (WAN) connections.

Because only two devices ever live on the wire, you don't need much from the addressing scheme. You need an address for one end, an address for the other end, and a way for each side to recognize the other. That's it. No clients to assign, no broadcast domain to build out, no DHCP (Dynamic Host Configuration Protocol) server to feed.

The tricky part is that the way IPv4 (Internet Protocol version 4) traditionally allocated addresses was built around the idea of subnets with many hosts on them. Stretching that model down to a two-host link forces a few uncomfortable design choices, which is why three different conventions ended up coexisting.

A /30 is a subnet with four total addresses, written using CIDR (Classless Inter-Domain Routing) notation, the modern shorthand for describing the size of a subnet. Of those four addresses, only two are usable for actual hosts. The first is the network address, used to identify the subnet itself, and the last is the broadcast address, used for messages aimed at every host on the segment. Both are reserved by the rules of IPv4, even when the segment only has two devices on it.

For a long time, this was the standard way to address point-to-point links. If you cracked open any router configuration written before about 2010, you'd find /30 subnets sprinkled liberally across every interface. A typical pair of routers connected by a /30 might have 192.0.2.0 as the network, 192.0.2.1 on Router A, 192.0.2.2 on Router B, and 192.0.2.3 as the broadcast.

The problem is the math. To address one cable with two hosts on it, you've consumed four addresses. Half of every /30 you allocate is structural overhead, never carrying traffic. On a single link this barely matters. On a network with five hundred WAN circuits, you've spent two thousand addresses to wire up one thousand interfaces, which adds up quickly when you're working in a constrained block of public space or trying to keep an internal plan tidy.

In December 2000, the IETF (Internet Engineering Task Force, the group that publishes the standards the internet runs on) released RFC 3021, a short and elegant document that solved the waste problem. RFC stands for "Request for Comments," the format the IETF uses to publish formal specifications. The key insight in RFC 3021 is that on a true point-to-point link, the concepts of "network address" and "broadcast address" don't really do anything useful. There's nobody else on the segment to broadcast to. So the document defined a way to use a /31 instead: a subnet with exactly two addresses, both usable, both assigned to actual interfaces.

That same pair of routers wired up with a /31 looks like this: 192.0.2.0 on Router A and 192.0.2.1 on Router B. Two addresses, two devices, zero waste. You've cut the address consumption in half compared to a /30, and on a network with hundreds of links the savings are dramatic.

For years, the catch was hardware support. Older platforms simply didn't understand /31 addressing and would refuse to bring the interface up. By the mid-2010s, however, every major router and switch vendor had implemented it, and today /31 support is essentially universal on equipment less than a decade old. Cisco IOS, Cisco IOS-XR, Juniper Junos, Arista EOS, Nokia SR OS, and the major Linux-based platforms all handle /31s without complaint.

The third option takes the efficiency idea one step further. An unnumbered interface doesn't get its own IP address at all. Instead, the router borrows the address from another interface, almost always a loopback (a virtual interface internal to the device, typically used as the device's stable identity for routing protocols). When traffic needs to leave the unnumbered link, the router uses the loopback's address as the source.

This trick has been around for decades and shows up especially in service provider networks running BGP (Border Gateway Protocol, the protocol that connects different networks together across the internet) and OSPF (Open Shortest Path First, a common routing protocol used inside a single organization) across many locations. With unnumbered links, a network can have thousands of point-to-point connections without spending a single additional address on any of them. Every router has its loopback, and every link rides along on those loopbacks.

The tradeoff is operational. Unnumbered links can be harder to troubleshoot at first glance because each end of a link doesn't have a unique address to ping. Tools and runbooks built around the assumption that every interface has its own IP need adjustment. Modern network monitoring handles unnumbered just fine, but for a small team running a simple network, the operational simplicity of having a numbered interface on each side is sometimes worth the address overhead.

For most networks, the answer is straightforward: use a /31 whenever the hardware and software on both ends of the link support it, and only fall back to /30 if you're forced to interoperate with a legacy platform that doesn't. On any modern equipment built in the last ten years or so, /31 works reliably and saves real address space. The only common reason to keep using /30 is interoperability with old gear. If you have a router from 2003 terminating a serial circuit, you may not have a choice. Outside of that situation, sticking with /30 in 2026 mostly burns address space for no benefit.

Unnumbered links are excellent in the right environment, particularly large service provider or hyperscale networks with strong automation, mature monitoring, and many hundreds of point-to-point connections. For a typical enterprise or mid-size deployment, /31 hits the right balance. You get the address efficiency without giving up the operational habit of having a unique address on each interface.

Approach Addresses used per link Best for Watch out for
/30 4 (2 usable, 2 reserved) Legacy platforms that don't support /31 50% address waste; rarely necessary today
/31 2 (both usable) Modern enterprise and service provider links Requires RFC 3021 support on both ends
Unnumbered 0 (uses loopback) Large-scale networks with strong automation Slightly trickier to troubleshoot; tooling must understand it

A good IPAM (IP Address Management) tool will let you pick the prefix length you want for each link without fuss, track which addresses are in use, and warn you when you're about to collide with another assignment. If your IPAM treats every subnet like it has to be a /24, point-to-point planning becomes painful. If it understands /31s and unnumbered conventions, you can lay out a clean WAN plan in minutes and watch your address utilization actually reflect reality.

Point-to-point addressing is one of those small choices that quietly shapes the cleanliness of an entire network plan. Pick /31 by default, reach for unnumbered when scale calls for it, and leave /30 behind unless legacy hardware forces your hand. Future you, looking at a clean and well-utilized address plan, will be glad you did.