Summary
- RFC 5121 requires the mobile station and base station to negotiate at most one convergence sublayer for IPv6 on a link. The receipt proves the selected carriage method, not the complete IPv6 topology.
- Multiple transport connections and CIDs can sit beneath one MS-to-access-router link; where base station and access router are separate, per-station or finer tunnels help preserve the point-to-point model.
- A trustworthy readiness record joins—but does not collapse—capability, selection, service flow, CID, tunnel, prefix, router advertisement, MTU, multicast state and observed packet outcome.
Imagine the first green line after an access upgrade: IPv6 IP CS negotiated. It is reassuring because it closes a real ambiguity. IEEE 802.16 offered more than one way to carry IPv6, including the IP-specific part of the Packet Convergence Sublayer and an Ethernet-specific path. RFC 5121 says that when both endpoints support IP CS, it is the default; when both IP CS and Ethernet CS are available, they use IP CS; and on a given link they negotiate at most one convergence sublayer.
That rule is a thin interoperability rule. It prevents two peers from treating the same link as two incompatible encapsulations. It does not appoint the negotiation record as authority over the rest of the network.
Selection is narrower than delivery
The distinction begins inside the MAC. RFC 5121 notes that the generic MAC header does not carry a field that announces the payload type. Classifiers examine packet properties and select a service flow and transport connection. The dynamic service exchange identifies which convergence sublayer the connection uses. An IPv6 packet then receives the six-byte generic MAC header and travels on the chosen connection.
If the endpoints cannot agree on a common convergence sublayer, the transport connection is not established and IPv6 cannot travel through that path. Agreement is therefore necessary. But a necessary receipt is not a complete receipt. The classifier can be stale. A service flow may not be created. The wrong connection may be selected. A packet may leave the station but enter the wrong access-router context. None of these later events is encoded in the fact that two capability messages overlapped.
The same limit applies to implementation support. RFC 5121 requires a base-station implementation to support the Standards Track encapsulations defined for 802.16, while permitting modes to be disabled by configuration. “Supported by the software,” “enabled on this base station,” “selected for this link” and “used by this packet” are four separate states.
One L3 link can contain several CIDs
Operational dashboards often count the artifact that is easiest to query. In this design that artifact may be the CID, the identifier for a MAC transport connection. Yet RFC 5121 explicitly allows multiple transport connections between the same mobile station and base station. It defines the IPv6 link at Layer 3, not by equating it with one IEEE Layer 2 connection.
When the access router and base station are co-located, the collection of transport connections to one mobile station forms one link. If the access router sits beyond the base station, the specification recommends a tunnel no coarser than per mobile station or per service flow. The tunnel or tunnels, together with the station's transport connections, form the point-to-point link between that station and the access router.
This is not vocabulary polish. If a control plane counts every CID as an IPv6 link, it invents links that the protocol model does not contain. If it aggregates several stations behind one coarse tunnel while claiming the per-station model, it erases isolation that the model relies on. A useful ledger must be able to traverse both directions: from station and access-router link to every service flow and CID, and from any observed CID back to exactly one intended station context.
Radio proximity does not create a shared prefix
Stations may share a radio technology and a base station while belonging to different IPv6 links. RFC 5121's chosen point-to-point model assigns a unique prefix or prefixes to each MS/host link. One or more /64 prefixes should normally be advertised, with the on-link flag set. A customer-premises device may sit at the endpoint and serve several hosts, but that does not turn neighboring subscribers into one subnet.
The prefix receipt therefore has to name the link. A prefix visible in an address-management system is not enough. The evidence should show which access router advertised it, which station context received it, what flags and lifetimes applied, and whether the packet path remained in that context. DHCP or AAA-based delegation is an alternate delivery mechanism, not an alternate truth about which link the prefix belongs to.
Duplicate Address Detection exposes the cost of skipping these details. RFC 5121 says DAD may be redundant for a qualifying global address only when the advertised prefix is unique to that link and the access router does not form its own global address from the same prefix. “Point-to-point” alone does not satisfy those conditions. If an optimizer suppresses DAD without recording both facts, it has transformed a conditional optimization into an unsupported assumption.
Address identity is not link identity
The original document said that the station's 48-bit MAC address must be used to construct a modified EUI-64 interface identifier, while also allowing privacy-oriented random identifiers. RFC 8064 later updated RFC 5121 and recommends against embedding stable link-layer addresses in stable IPv6 interface identifiers.
The update is a useful demonstration of modular authority. The interface-identifier policy changed; the per-station link and unique-prefix model did not thereby disappear. A system that has fused address identity, device identity and link identity will find such an update difficult to apply. A thinner design keeps the prefix-to-link record, IID-generation policy and observed address set separate.
Silence is ambiguous in dormant mode
The air interface creates another temptation to misread absence. A mobile station can enter idle mode and tear down its radio link. Periodic router advertisements could wake it and consume scarce air-interface resources, so RFC 5121 allows much longer advertisement intervals than ordinary assumptions might suggest. It also advises an access router not to send periodic MLD queries while the host is idle or dormant.
Less control traffic can be correct. It can also look identical to stale state from the wrong observation point. A quiet link is not self-proving. The record needs the dormant transition, paging state, last router information, multicast memberships and the event that should revalidate them. Otherwise a dashboard may label intentional sleep as failure—or label lost state as healthy sleep.
The MTU needs its own receipt
RFC 5121 recommends a default IPv6 MTU of 1500 octets. If a different value is used, the access router must advertise it in the Neighbor Discovery MTU option, and Path MTU Discovery may refine what the path can carry. Those are already three layers: configured link MTU, advertised MTU and observed path behavior.
There is also a custody warning in the source itself. The RFC says an 11-bit length field makes the total MAC PDU size 2048 bytes. Errata ID 1768 argues that an 11-bit maximum value is 2047. The erratum is marked “Held for Document Update,” not Verified. A careful report records the arithmetic and the procedural status together. Quietly substituting one number destroys the evidence trail; blindly repeating the printed number discards a known qualification.
The same discipline applies to packet tests. A 1500-byte configuration entry does not prove that a 1500-byte IPv6 packet survives the complete path. Capture Packet Too Big messages, successful probes at controlled sizes and the ingress and egress observations. The packet—not the configuration form—settles the operational claim.
A minimal receipt stack
The result is not a demand for one giant controller. It is a demand for modest claims. Record the capability bits. Record the convergence sublayer actually selected. Record the service-flow and CID bindings. Record whether the access router is co-located or reached through a per-station or per-flow tunnel. Record the unique prefix, router advertisements, IID policy, DAD basis, MTU and MLD state. Finally, record packets and outcomes.
These records can be joined for investigation without becoming one status field. The common layer should say only what must be common: which representation was selected, which endpoints form the link and which identifiers bind the packet path. Local systems may choose their own automation and operating policy, but they must not rename an early negotiation receipt as proof of later reality.
Sources
- https://www.rfc-editor.org/rfc/rfc5121.html
- https://www.rfc-editor.org/rfc/rfc5121.txt
- https://www.rfc-editor.org/info/rfc5121
- https://www.rfc-editor.org/errata/rfc5121
- https://datatracker.ietf.org/doc/rfc5121/
- https://datatracker.ietf.org/doc/rfc5121/history/
- https://www.rfc-editor.org/rfc/rfc4968.html
- https://www.rfc-editor.org/rfc/rfc5154.html
- https://www.rfc-editor.org/rfc/rfc5181.html
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc4862.html
- https://www.rfc-editor.org/rfc/rfc4291.html
- https://www.rfc-editor.org/rfc/rfc4941.html
- https://www.rfc-editor.org/rfc/rfc8064.html
- https://www.rfc-editor.org/rfc/rfc8200.html
- https://www.rfc-editor.org/rfc/rfc2473.html
- https://www.rfc-editor.org/rfc/rfc3810.html
- https://www.rfc-editor.org/rfc/rfc3315.html
- https://www.rfc-editor.org/rfc/rfc2119.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
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
