Summary
- RFC 5309 separates network type from media type: two routers may run point-to-point IS-IS or OSPF over broadcast-capable LAN media, but control packets still require correct multicast MAC and VLAN encapsulation.
- Both ends must make the same no-fallback configuration choice. Even after adjacency forms, unnumbered IP forwarding still needs a valid next-hop IP and a working ARP, ND, static or gleaned MAC binding.
The topology changed before the wire did
Broadcast and point-to-point circuits produce different link-state models. A LAN normally brings a designated router or DIS, a pseudonode or virtual network representation, and flooding procedures suited to multiple participants. A point-to-point circuit advertises the connection between two routers directly.
RFC 5309 allows an operator to choose the second model even when the physical medium remains broadcast-capable. The intended cases have two routers on the physical segment or on a VLAN. The gain is reduced protocol state: no DR/DIS election, no pseudonode, no OSPF reflection through a DR, and no periodic IS-IS CSNP behavior associated with a LAN.
This is a configuration statement about what the IGP should believe. It does not convert Ethernet into a dedicated serial wire. The MAC header must still reach the other side. In a VLAN environment the tag must still select the same logical segment. For IS-IS, the link-layer frame is still a LAN frame; AllISs is recommended among the defined multicast destinations.
The first evidence boundary is therefore simple: configured topology type and physical delivery type are not the same record.
Mismatch fails closed
Both routers must support the extension and configure the segment as p2p-over-LAN. A point-to-point-configured circuit that receives LAN Hellos must discard them. A LAN-configured circuit that receives point-to-point Hellos must also discard them. If an incoming Hello names a system ID or router ID different from the established peer, it must be discarded.
There is no automatic fallback when the ends disagree. The adjacency does not form until a person or automation corrects the configuration. The design prefers visible failure over a silent downgrade into a different topology model.
That property should shape change control. “Enabled on router A” is not completion. Completion requires a paired configuration record, matching Hello type, expected peer identity, explicit discard counters at baseline and the adjacency transition. A rollback must restore both ends to the same traditional LAN model rather than leave one end waiting for a packet the other will never send.
RFC 5309 recommends logging and debugging for mismatch events. Those events are not incidental noise: they are the protocol's evidence that the two ends disagree about the contract.
A Hello can arrive before an IP packet can leave
An ordinary point-to-point interface does not need an IP next-hop identifier because there is only one possible destination on the medium. P2p-over-LAN is different. The data-link frame still needs a destination MAC address, so the IP next hop is not optional. It must identify a valid interface or internal address on the adjacent router.
For unnumbered IPv4, the interface borrows an address independent of the physical port. ARP must resolve that internal address. An ARP implementation that insists the request source belongs to the local interface subnet needs to relax that check for this circuit type. In IPv6, Neighbor Discovery resolves the peer's link-local address.
RFC 5309 also describes static destination-MAC configuration and MAC gleaning from a frame carrying a routing-protocol packet. Gleaning is an economical bridge between planes: the control frame reveals a source MAC that forwarding can reuse. But a learned MAC is still a binding, not a packet-delivery receipt. It can age, change, point into the wrong VLAN context or fail to appear in the forwarding object used by traffic.
This explains how an IGP adjacency and the data path can diverge without contradiction. The Hello may use a multicast destination accepted by both routers, while unicast IP forwarding depends on a separate next-hop-to-MAC resolution. Control-plane reachability is evidence for the peer relationship, not for every later frame.
Unnumbered saves addresses and removes a familiar probe
Separating network type from media type lets Ethernet links use the unnumbered model. The operator saves address space and may simplify configuration. The trade-off is inherited from unnumbered serial links: a specific interface between the routers may no longer have an address that can be pinged or monitored directly.
That is not merely a tooling inconvenience. It shifts what counts as proof. Per-link health may need adjacency telemetry, VLAN counters, neighbor-cache entries, interface state, forwarding-table recursion, synthetic packets and remote return evidence. A loopback that responds does not isolate the link, while an adjacency counter does not prove IP unicast forwarding.
Likewise, splitting a multi-access LAN into many two-router VLANs simplifies each logical adjacency but sacrifices the scaling benefit of one shared segment. The link-state database grows, more packets are flooded, and route computation increases. Simpler local semantics can create a larger global control surface.
Scope and uncertainty
RFC 5309 is Informational and explicitly not an Internet Standard. It describes a technique and its implications. It does not prove that a current product implements every check, that an operator uses p2p-over-LAN, that a VLAN contains only two devices, or that a proprietary MAC-resolution method interoperates.
RFC 5303 provides a three-way handshake for IS-IS point-to-point adjacency state. That mechanism is adjacent but different: stronger reciprocal state does not resolve the Ethernet next-hop binding described here. RFC 5304 can protect accepted routing messages; authentication does not manufacture the missing MAC. RFC 5305 can advertise link attributes; those attributes do not prove this frame traversed the link.
To establish a live result, inspect both configurations, captured Hellos and their IDs, VLAN and multicast delivery, adjacency state, next-hop IP, ARP/ND or static/gleaned binding, installed route and FIB, packet capture and service observation. The logical model becomes useful precisely when its remaining dependencies stay visible.
Sources
- RFC 5309: Point-to-Point Operation over LAN
- RFC 5309 plain text
- RFC Editor information for RFC 5309
- IETF Datatracker record for RFC 5309
- IETF Datatracker history for RFC 5309
- IETF Datatracker references from RFC 5309
- IETF Datatracker documents citing RFC 5309
- RFC Editor errata for RFC 5309
- RFC 1195: Use of OSI IS-IS for Routing in TCP/IP
- RFC 2328: OSPF Version 2
- RFC 5340: OSPF for IPv6
- RFC 5303: Three-Way Handshake for IS-IS Point-to-Point Adjacencies
- RFC 5304: IS-IS Cryptographic Authentication
- RFC 5305: IS-IS Extensions for Traffic Engineering
- RFC 5308: Routing IPv6 with IS-IS
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
- IANA IS-IS TLV Codepoints
- Heng Lu: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu: Running Code Primary
- Heng Lu: On the Agency Problem at the Core of Internet Governance
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
