Summary

  • RFC 4957 treats link-layer notifications as inputs to detecting network attachment, not as a completed IP or service outcome.
  • A new attachment can leave a host on the same subnet; a configuration change can also occur without a new attachment event.

“Link up” is an attractive operational label because it sounds final. A radio association completed, a Wi-Fi station joined an access point, or an Ethernet interface became capable of sending frames. In incident dashboards and handoff analytics, that state is easily promoted into a claim that connectivity has returned. The promotion is often wrong.

RFC 4957, Link-Layer Event Notifications for Detecting Network Attachments, makes a narrower contribution. Edited by Suresh Krishnan and published as an Informational RFC, it catalogues the signals that access technologies can give IP when a device changes its attachment point. Its purpose is to make an IP stack investigate configuration quickly; it is not to certify that a usable network service has been obtained.

That distinction appears early in the document. A new link-layer connection may tell a host to seek more evidence, for example by sending a router solicitation. The document says that a link-layer notification alone does not supply all the input required by the Detecting Network Attachment process. Prefixes, default-gateway reachability and other IP-layer evidence still matter. The useful event is therefore a prompt for a state machine, not the terminal state of that machine.

The boundary becomes sharper in ordinary Wi-Fi roaming. A station can disconnect from one access point and associate with another while remaining on the same IP subnet. Treating every association as a need to reconfigure IP produces needless work and misleading measurements. The reverse case also exists: IPv6 renumbering can require IP-layer change with no new link-up notification. The absence of a local event is not a clean bill of health either.

RFC 4957 also acknowledges a more awkward state. An implementation may report a non-deterministic link up when the interface is ready but data transmission could still be blocked somewhere in the network. Even a later deterministic indication describes the link-layer condition defined by that implementation. It does not establish that address configuration completed, that policy admitted traffic, that DNS resolved, that a remote service accepted a request, or that a user saw a response.

For operators, this is a measurement-design issue before it is a protocol-history issue. A handoff telemetry stream should preserve its evidence class. link_up can be a strong local observation: interface, attachment point, time and perhaps technology-specific context. It should not be renamed online, counted as application recovery, or used as the sole closure condition for an outage ticket. Each of those labels makes a broader assertion than the signal can carry.

The better model is an evidence ladder. A link event can trigger neighbour discovery, address-configuration checks and a gateway probe. A usable gateway can trigger resolver checks. A resolver result can support a service probe. A service response can still fall short of proving a customer transaction or a human outcome. Every rung has a different observer, failure domain and accountability value.

This matters most when dashboards cross organisational boundaries. The access operator may be able to attest to attachment; the host may attest to its own configuration; a resolver logs a lookup; the service operator observes an authenticated request. None should silently speak for the others. The RFC’s modest framing keeps those claims separable.

Suresh Krishnan’s broader IETF record spans mobility, IPv6 and network architecture. In RFC 4957, the lasting lesson is deliberately limited: a link event is evidence about a link event. It is valuable because it starts the next test. It becomes dangerous when it is presented as a receipt for a path, a service or a customer experience it never observed.

Sources