/31 on point-to-point links: where it works and where it quietly does not

A /30 is the traditional size for a point-to-point link: four addresses, of which two are usable. The other two are the network address and the broadcast address, and neither does anything on a link that has exactly two ends. That is fifty percent of the block spent on two addresses that are structurally unused.

RFC 3021, published in 2000, removes the waste: on a point-to-point link, use a /31 and treat both addresses as hosts. It halves the addressing cost of every transit link in the network. It is also, in a handful of real situations, the wrong answer.

What the saving actually is

Do the arithmetic on a network with forty point-to-point links, which is unremarkable for an enterprise WAN or a service-provider access layer:

One bit of prefix, halved. The same /24 that carries 64 /30 links carries 128 /31 links, and on a network where transit links are a large fraction of the address plan this is the difference between running out and not.

Mechanically there is nothing exotic: both ends are configured with the same /31, each address is a host address, and the connected route is the /31 itself. There is no network address to ping and no broadcast address to worry about, because on a two-node link neither concept does any work. ARP still operates normally over Ethernet: the peer is simply another on-link address.

Where a /31 is the wrong answer

Four situations, and they are worth knowing before you convert a hundred links at once.

• The link is not point-to-point. A /31 assumes exactly two endpoints. On a shared segment, an NBMA service, or anything that resembles a multipoint topology, the two-address model is wrong regardless of what RFC 3021 permits, and you are back to a larger prefix.
• Something on the link needs a broadcast address. Features defined in terms of the subnet broadcast — a DHCP relay configured to forward broadcasts, subnet- directed discovery, some legacy NetBIOS and wake-on-LAN tooling — have no address to send to on a /31. Some of them can be reconfigured to a unicast helper address; some cannot.
• A platform that will not take it. Modern IOS, IOS-XE, NX-OS, EOS, Junos and Linux all accept a /31 on a point-to-point interface. But not every platform accepts it on every interface type, and it is common for an appliance — a firewall, a load balancer, a WAN optimiser — to refuse a /31 on its interface, or to accept it and then behave oddly because its own model of the subnet assumes a network address.
• Tooling that computes network and broadcast. Monitoring, IPAM and inventory systems frequently derive a network address and a broadcast address from a prefix length and do something with them. On a /31 those two addresses are real hosts, so a scanner that pings the “network address” is pinging your router, and a report that flags them as reserved is reporting nonsense. This one is annoying rather than fatal, but it is real and it tends to surface months later.

IPv6 makes the same argument, with a twist

For IPv6 the equivalent is the /127 (RFC 6164), and it is not optional housekeeping — a /64 on a point-to-point link creates two specific hazards. The first is that every /64 has a subnet-router anycast address, and on a two-node link one of the addresses can end up claimed by the wrong end. The second is neighbour discovery cache exhaustion from a /64 worth of unused addresses. A /127 has neither problem and costs 126 addresses less.

The difference from IPv4 is that IPv6 has enough space that the /127 is about correctness rather than scarcity. In IPv4 the /31 is about both.

How to decide

The decision is per link type, not per network:

• Router-to-router over Ethernet, both ends under your control: /31. This is the common case and the default worth adopting.
• Anything involving a device whose /31 support you have not confirmed: /30 until you have confirmed it. The address cost of four is not worth a circuit that comes up and then does not pass traffic.
• Public WAN links with addresses assigned by a provider: use whatever they assign. Converting a /30 they handed you into a /31 is a conversation, not a design decision.

Where to check the arithmetic

The IPv4 subnet calculator applies RFC 3021, so a /31 reports two usable addresses rather than the misleading zero a naive calculation produces. The VLSM planner has an explicit /31 toggle that sizes point-to-point links at two addresses each when you are allocating a block across a plan.

The summary: a /31 is correct whenever the link has exactly two ends and both of them understand what a /31 means — which is most transit links, and worth checking rather than assuming for the rest.