Summary

  • RFC 5380 reduced distant mobility signaling by placing a local Mobility Anchor Point between a stable Regional Care-of Address and a changing on-link address.
  • A successful Binding Acknowledgement showed that the anchor accepted state; delivery still depended on interception, a current binding cache, a usable tunnel, sufficient MTU and endpoint processing.

One green address, two changed paths

Imagine an operations display that identifies a mobile session by one IPv6 address. The address is unchanged before and after a local handover. A correspondent node sees no new care-of address. The home agent sees no local movement. Every identity panel stays green.

Under that apparently stable object, the mobile node has acquired a new on-link Care-of Address, or LCoA. It has sent a local Binding Update. A Mobility Anchor Point, or MAP, has replaced one cache entry with another. The tunnel exit has moved. Packets already in flight may still be arriving at a previous anchor. The usable packet size may have changed because encapsulation is part of the path.

RFC 5380 deliberately created this separation. It was not a mistake in the design. Hierarchical Mobile IPv6 sought to reduce the amount of signaling sent to distant home agents and correspondent nodes. The mobile node registered a Regional Care-of Address, or RCoA, outside the local domain. As long as movement stayed inside that MAP domain, the RCoA remained stable and only the RCoA-to-LCoA binding needed local repair.

Continuity therefore came from indirection. Remote stability was purchased by making a local mapping authoritative.

What the Binding Acknowledgement actually said

The MAP acts like a local home agent. A mobile node sends a local Binding Update that asks the MAP to bind the RCoA to the current LCoA. If the registration succeeds, the MAP returns a Binding Acknowledgement. RFC 5380 tells the mobile node to wait for that acknowledgement before registering the RCoA with a home agent or correspondent nodes. It also prevents those outer bindings from living longer than the binding at the MAP.

Those are strong control rules. They do not turn the acknowledgement into a packet-delivery certificate.

After acceptance, the MAP still has to intercept packets addressed to the RCoA, find the correct current LCoA, encapsulate the packet and route it to that address. The mobile node must receive, decapsulate and process it. Outbound traffic follows the reverse tunnel discipline. Security associations must work. The forwarding path must exist. The packet must fit the usable MTU after tunnel overhead. An application must survive whatever loss and delay occurred during the state change.

The acknowledgement closes one question: did the MAP accept this binding? It leaves later questions open.

This is the distinction that management systems routinely erase. They record the successful write to a control plane and infer that the resulting service exists. RFC 5380 supplies a better receipt chain: discovery, selection, address formation, registration, retained state, forwarding, path viability, endpoint processing and application continuity.

Preference was policy, not a health probe

MAP information arrives through Router Advertisements. The option carries a global address, prefix information, distance, operator preference and lifetime. A mobile node stores the options and chooses at least one anchor. The selection procedure gives preference a deliberate role and uses distance as another input.

Neither field should be promoted into evidence it was never designed to carry. Preference can express operator policy. Distance need not be the measured forwarding distance. A non-zero lifetime says the advertisement has not declared the MAP failed. None of those statements proves that the anchor has capacity, that its binding cache is current, that a tunnel route is working or that packets are reaching the application.

RFC 5380 does define a hard withdrawal signal. A MAP option with a zero valid lifetime means the MAP must not be selected. Existing bindings can be treated as lost, another MAP must be chosen, and HMIPv6 must not be used if none is available. That is an explicit negative control event. It still does not make every non-zero advertisement a positive data-plane measurement.

The operational trap is familiar: absence of a withdrawal becomes evidence of health. It is not.

The old anchor becomes temporary infrastructure

A change of MAP domain changes the RCoA and exposes the boundary that local movement had hidden. RFC 5380 allows the mobile node to update the previous MAP with a new location so packets in flight can be forwarded. An administrator may restrict forwarding beyond the old domain, although forwarding to neighboring domains is recommended under stated conditions.

This is not merely a graceful-handover feature. It creates an ownership problem. The old anchor now holds time-limited forwarding state to a location controlled through a new path. The new anchor holds the current binding. Home-agent and correspondent-node bindings may be changing on their own timers. A clean incident timeline has to say which anchor accepted which state, when outer bindings were updated, when old forwarding ended and which packets crossed each path.

Without those timestamps, “the address was reachable” is an untestable summary.

Stability has a packet-size cost

The RFC explicitly warns about tunneling and MTU. Traffic is tunneled between the mobile node and MAP in both directions. If a home agent elsewhere also participates, packets may be encapsulated twice. The mobile node must account for this overhead when calculating the MTU available to upper layers.

That warning matters because control success and packet viability can diverge cleanly. A small Binding Update and its acknowledgement can traverse a path that later fails for larger application packets. A dashboard can show a valid binding, a current lifetime and an unchanged RCoA while the useful payload experiences fragmentation, Packet Too Big handling failures or loss elsewhere in the tunnel path. RFC 5380 does not claim such an incident occurred; it identifies the dependency that operators must measure.

Authentication narrows the claim

The relationship between a mobile node and MAP must include mutual authentication, integrity protection and replay protection. RFC 6071 places the design in the broader IPsec and IKEv2 security family. These requirements answer essential questions about who is exchanging protected mobility signaling and whether a recorded update can be replayed or altered.

They do not prove that the LCoA belongs to an allowed operating domain unless the configured prefix policy says so. They do not prove that the tunnel forwards. They do not turn the MAP into the authority for the mobile node's home identity. RFC 5380 is careful here: the MAP can operate without knowledge of the home address and may reject an LCoA outside an administrator's valid on-link prefix list.

Identity, authorization, accepted state and delivered traffic remain separate.

A local optimization, not the disappearance of anchoring

Later architectural work sharpened the trade-off. RFC 7429 describes HMIPv6 as less centralized than a single distant anchor because local signaling can terminate at a MAP. It also records gaps around dynamic anchor assignment, relocation, discovery, selection and context transfer. Multiple anchors can reduce one concentration while multiplying the associations that must remain correct.

The design also permits more than one MAP or RCoA for different correspondent-node groups. But it forbids using an RCoA derived from one MAP as the care-of address registered with another, because nested encapsulation would reduce efficiency. Hierarchy is not free merely because every layer is valid.

RFC 5380 even offers a local-only use of the RCoA as an upper-layer source without global Mobile IPv6 bindings. The benefit is direct: local mobility with less Internet-wide signaling. The limit is equally direct: communication breaks when the node changes its RCoA. The stable address was always scoped to the domain that maintained it.

The receipt remote peers cannot see

Heng Lu's running-code discipline is useful because HMIPv6 separates a durable public-looking coordinate from the current machinery that realizes it. The record “RCoA unchanged” describes the interface. Running code still has to maintain the RCoA-to-LCoA binding, security context, interception rule, tunnel route and packet-size budget.

For an operator, the meaningful unit is not the stable address alone. It is a tuple: RCoA, current LCoA, MAP identity, binding sequence and lifetime, security-association state, tunnel path, usable MTU, last verified packet and application observation. For leadership, the question is whether the organization can produce that tuple during failure, not whether the protocol offers a stable label.

The address never moved. Everything that made it true did.

Sources