Summary
- RFC 5213 moves mobility signalling from the mobile node into the network. A Mobile Access Gateway detects attachment and sends a Proxy Binding Update on the node's behalf; a successful acknowledgement proves that the Local Mobility Anchor accepted an authorised network claim.
- It does not prove that the attachment observation is still true, that the MAG completed its tunnel and forwarding work, that the device received the Router Advertisement and configured its address, or that an application session survived. Those results require their own evidence.
The absent signature is the design
Host-based mobility asks a device to participate in preserving its address while it changes its point of attachment. Proxy Mobile IPv6 takes a different bargain. Within a managed domain, the network recognises the device, retrieves a policy profile and performs the mobility exchange for it. The node can use ordinary IPv6 behaviour without knowing that its movement caused a mobility protocol transaction.
That is the attraction of RFC 5213. Devices need no special mobility client. The operator can anchor a home-network prefix at a Local Mobility Anchor, or LMA, and use Mobile Access Gateways, or MAGs, at access edges. When a node arrives, the serving MAG sends a Proxy Binding Update. If the LMA accepts it, the LMA creates or updates a binding cache entry, associates the node and prefix with that MAG, prepares its end of a bidirectional tunnel and returns a Proxy Binding Acknowledgement.
The successful PBA is meaningful. It is not a decorative message. It says the LMA authenticated an authorised peer, accepted a transaction for a particular mobile-node identity and established its own prescribed state. The mistake is to expand that meaning until it includes observations and actions owned elsewhere.
The mobile node did not sign the PBU. The access system supplied the attachment event; the MAG derived or obtained the node identifier; policy supplied authority; the MAG spoke; the LMA acted. Proxy mobility is therefore an unusually clean case of delegated representation in running code.
A credential proves the speaker, not the scene
RFC 5213 requires trust between the LMA and MAG. Proxy binding messages must be protected, and IPsec support is mandatory. The LMA must also determine whether that MAG is authorised to update the binding of the named node. These controls answer essential questions: who sent the message, whether it was altered and whether the sender may speak for this subject.
They do not independently answer whether the scene described by the message remains true.
Attachment detection is deliberately outside the protocol. A wireless association, access authentication exchange, link event or another technology-specific mechanism tells the MAG that a node has arrived. Detachment is equally external. The PBU carries the result of that observation into the mobility system; it does not repeat the observation or make it infallible.
The security discussion makes the boundary explicit. A compromised MAG could claim that a node is attached when it is not. One mitigation is for the LMA to ask a trusted entity to confirm actual attachment before accepting the update. RFC 5213 leaves that confirmation mechanism outside scope. Authentication of the proxy and confirmation of the physical premise are separate controls because they prove separate facts.
This is not a defect unique to PMIPv6. It is the general limit of an authorised representative. A valid power to make a statement does not make every statement contemporaneously correct. Authority needs a subject, a scope, an observation source and a freshness interval.
Success at the anchor begins work at the edge
The order of operations matters. The LMA processes the PBU first. On acceptance it updates its binding cache, selects or preserves the home-network prefix, sets its tunnel endpoint and returns status zero in a PBA. Only after receiving and authenticating that success does the MAG complete its side: it updates local binding state, establishes the other tunnel endpoint, installs forwarding for the node and sends Router Advertisements on the access link.
An operations console that marks the handoff complete at the LMA's PBA has stopped at the midpoint of the protocol. It has evidence for the anchor. It may not yet have evidence for the edge.
The device then owns another part of the chain. Router Advertisements are processed under IPv6 Neighbor Discovery. Address configuration and Duplicate Address Detection follow their own rules. The intention of PMIPv6 is that the node keeps the same home-network prefix and experiences the new access link as its home link. But a design intention is not an observation that the advertisement arrived, the address remained usable, a default router was selected or packets travelled in both directions.
Extensions can sharpen the tunnel. GRE keys can distinguish flows or contexts. Later specifications can optimise handover and prefix handling. None converts an accepted registration into an application receipt. A tunnel object can exist while one end has stale forwarding, policy drops the return path, the device has not completed configuration or a session has already timed out.
The binding cache is a claim ledger
The LMA's binding cache serialises mobility claims. It maps the mobile-node identifier and home-network prefix to the serving proxy and gives the state a lifetime. On handoff, an old MAG may signal detachment and a new MAG may signal attachment. Messages can cross, observations can age and failures can prevent timely withdrawal.
The cache is authoritative for what the LMA will route. That is operationally important. It is not omniscient about where the device physically is. A still-valid lifetime says that the accepted assertion has not expired under protocol rules. It does not continuously sense the access link.
This distinction becomes valuable during incident review. If the LMA points to the new MAG but traffic dies, the right question is not whether the database is “wrong” in the abstract. The investigation should locate the first broken evidence edge: Was the attachment real? Was the identifier associated with the right device? Was the MAG authorised for that node? Did the new MAG receive the PBA? Did it install the correct route? Did the Router Advertisement reach the node? Did the old state withdraw? Did bidirectional traffic pass?
Each answer has a different owner and clock. Flattening them into one handoff timestamp destroys the very evidence needed to assign responsibility.
Build a proxy-handoff receipt
A defensible operational receipt would bind the access attachment event, observer and confidence; the identifier derivation; access authentication and policy decision; the MAG credential and per-node authority; PBU sequence and lifetime; any independent attachment confirmation; the LMA binding generation, prefix, route and tunnel state; the PBA status and its authenticated receipt at the MAG; MAG-side forwarding; Router Advertisement emission and reception; device address readiness; bidirectional packet tests; application outcome; and withdrawal of the old path.
That receipt is BTW editorial guidance, not an additional requirement imposed by RFC 5213. Its purpose is to preserve the protocol's own separation of duties when evidence reaches dashboards, automation and executive reporting.
Heng Lu's running-code doctrine provides the larger test. A record has authority over the behaviour that actually consumes it, but visibility does not become universal mandate and representation does not become execution. The LMA binding can direct packets. It cannot retroactively make the access observation true. The MAG may be authorised to represent the device. It cannot impersonate the device's reception of an advertisement or the application's experience.
The strongest mobility system is not the one that calls every successful PBA a handoff. It is the one that can show exactly which actor knew what, which actor was allowed to act, and where the running network supplied the next proof.
Sources
- RFC 5213 HTML
- IETF Datatracker: RFC 5213
- RFC 5213 information
- RFC 5213 document history
- RFC 6543 — MAG support for multiple interfaces
- RFC 7864 — PMIPv6 base specification update
- RFC 3775 — Mobility Support in IPv6
- RFC 4283 — Mobile Node Identifier option
- RFC 4832 — Mobility-related terminology
- RFC 4861 — IPv6 Neighbor Discovery
- RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 4301 — IP security architecture
- RFC 4303 — Encapsulating Security Payload
- RFC 4306 — Internet Key Exchange
- RFC 2473 — Generic IPv6 tunnelling
- RFC 5845 — GRE key option for PMIPv6
- RFC 6463 — Runtime local mobility anchor assignment
- RFC 8127 — PMIPv6 quality-of-service options
- Heng Lu — running-code primacy
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
