Why Does a Point-to-Point Handoff Use IPv4 /31 or IPv6 /127?

An IPv4 /31 or IPv6 /127 on an IP transit handoff is not too small: a true point-to-point link addresses exactly two routers. These long prefixes deliberately model that topology. Both sides must configure the same local and remote addresses, prefix lengths and handoff parameters. The networks you subsequently announce with BGP are separate from this link subnet.

Why an IPv4 /31 has two usable addresses

A conventional IPv4 /30 contains four addresses: a network address, two host addresses and a broadcast address. RFC 3021 defines a narrower interpretation for point-to-point links. In a /31, the two bit combinations represent the two endpoints; values that would otherwise be treated as network and broadcast addresses may be used as router source and destination addresses. The link therefore consumes two rather than four IPv4 addresses.

This exception applies to a link with exactly two endpoints. A shared Ethernet segment containing additional routers, servers or automatic host addressing has a different network model. Both devices must also support /31 on the relevant interface. RFC 3021 explicitly warns that a link may fail when only one end is configured for it.

Why an IPv6 /127 is not simply a tiny LAN

RFC 6164 specifies /127 for point-to-point inter-router links when explicit addresses beyond link-local scope are used. Again, exactly two endpoint addresses remain. The scope is deliberately narrow: two routers and no attached hosts. It is not a template for a server VLAN or an end-user network.

With IPv6, the long prefix is not primarily about conserving addresses. RFC 6164 describes two operational benefits among others: unused addresses in a large link prefix cannot trigger ping-pong forwarding between the ends, and Ethernet does not expose a huge set of apparently reachable destinations for which a router creates unsuccessful Neighbor Discovery entries. RFC 9099 repeats these reasons in its IPv6 security guidance.

Example: separate the handoff subnet from announced prefixes

The following example is purely illustrative. It uses the documentation ranges defined by RFC 5737 and RFC 3849; the addresses do not describe a real AS51202 handoff.

• IPv4: Router A uses 192.0.2.0 and Router B uses 192.0.2.1; their shared prefix is 192.0.2.0/31.
• IPv6: Router A uses 2001:db8:1200:1::2 and Router B uses 2001:db8:1200:1::3; their shared prefix is 2001:db8:1200:1::2/127.

There is no universal rule assigning the first or second address to a particular side; the handoff sheet is authoritative. The BGP neighbour is the address of the other router. Customer prefixes are announced separately as BGP routes. The /31 or /127 says nothing by itself about which routes you receive or which prefixes you may export.

Can IPv6 use link-local addresses only?

Yes. Routers can run infrastructure links using only IPv6 link-local addresses in suitable designs. RFC 7404 describes the benefits and caveats. The addresses have meaning only on their link, so a device with multiple interfaces must also identify the correct zone or interface. A BGP neighbour such as fe80::1 is ambiguous without that context.

Link-local-only addressing is not a silent substitute for an agreed /127. Remote interface pings, traceroute output, monitoring and ICMPv6 source-address selection may behave differently. Use the model both parties have explicitly documented and agree in advance which addresses support diagnostics and management.

Common turn-up mistakes

• One side configures /31 and the other /30, causing the routers to interpret the same address differently.
• Local and remote addresses are inferred from an assumed provider/customer convention instead of the handoff sheet.
• The VLAN, untagged handoff or MTU does not match, making the addressing symptom only a downstream effect.
• The handoff subnet is confused with customer prefixes announced by BGP or added to export filters without agreement.
• An overly broad ACL blocks IPv6 Neighbor Discovery or required ICMPv6 messages.
• The same point-to-point prefix is reused on two separate links, making diagnostics and failure behaviour ambiguous.

Checks to perform before starting BGP

1. 1Match the handoff point, port, optics, VLAN and MTU against the written handoff details.
2. 2Apply the local address, remote address and prefix length separately for IPv4 and IPv6.
3. 3Check direct reachability of the remote router and the IPv6 neighbour state.
4. 4Only then enable the BGP neighbour, local and remote ASNs, and the agreed import and export filters.
5. 5Compare received and announced routes with the agreed scope; an established BGP session alone does not prove that policy is correct.
6. 6Document the diagnostic path, technical contacts and rollback for future changes.

For a transit enquiry, include the handoff location, desired commit and port, ASN, prefixes and required route feed. If your router or addressing design constrains /31, /127 or link-local peering, identify that before configuration. Do not include credentials or private keys in the enquiry.