Summary

  • Predictive fast handover can resolve a candidate access point, provision a prospective care-of address, authorize forwarding and prepare a tunnel before the mobile node leaves its previous link. Those receipts prove preparation, not arrival.
  • Actual attachment, Duplicate Address Detection or explicit address assignment, Unsolicited Neighbor Advertisement processing, buffered-packet release, ordinary Mobile IPv6 binding and application continuity remain separate evidence layers.

The tunnel reached the new router before the device did

The attractive story of fast handover is temporal: do tomorrow's network work today. A mobile node learns that it may move, asks its previous access router about a candidate access point, forms a prospective new care-of address and authorizes traffic to be redirected. The previous access router coordinates with the new one. A tunnel can be ready and packets can be waiting before the radio or link-layer transition completes.

That is real value. Movement detection, address configuration and Binding Update can otherwise make Mobile IPv6 handover slow. But the same chronology creates an easy category error. Because the downstream route is ready first, a dashboard can display the prepared route as though the device has already reached it. The faster the preparation works, the more convincing the false compression becomes.

RFC 5268 does not permit that compression. It explicitly excludes link-switching latency from what it optimizes. It prepares IP-layer forwarding around a movement whose trigger and physical execution remain outside the protocol. RFC 5568 later obsoleted RFC 5268 and is the current standards-track reference, but it retains the important separation between preparation and attachment.

The management question is therefore not whether “fast handover succeeded.” It is which boundary succeeded, for which handover generation, and what remained unproved.

A candidate is coordinates, not a destination fact

Before moving, the mobile node may send Router Solicitation for Proxy Advertisement, or RtSolPr, to its previous access router. It names one or more access-point identifiers. The Proxy Router Advertisement response supplies access-router information: link-layer address, router IP address and a prefix valid on the candidate interface.

These tuples turn a radio-side hint into coordinates usable by the IP layer. They can support creation of a prospective new care-of address. Yet the trigger that selected the candidate is link-specific and outside the specification. The node may choose another access point, fail to attach to the expected one or reverse course before leaving.

A safe system records the distinction. “Candidate AP resolved” means the proposed AP-ID was mapped to a router and prefix under a particular observation. It does not mean “device located at new router.” A prospective NCoA similarly means an address has been formed for a possible future link; it is not yet an operational identity confirmed on that link.

This is where generation identity matters. A later movement may reuse the same access point or prefix. If the database stores only the apparent destination, stale preparation from the first attempt can be mistaken for proof about the second.

Predictive mode ends exactly where attachment begins

In predictive mode, the mobile node sends Fast Binding Update, or FBU, while it is still on the previous access link. The message asks the previous access router to bind the previous care-of address to the prospective new care-of address and redirect traffic. The FMIPv6 Binding Authorization Data option lets that router verify that the sender is entitled to act for the previous address.

The previous access router then exchanges Handover Initiate and Handover Acknowledge with the anticipated new router. The new router may accept the proposed address, replace it or refuse the preparation. A Fast Binding Acknowledgement returned before movement can tell the mobile node that the forwarding tunnel is already being established.

Every one of those facts is meaningful. None says that the node has switched links.

Reactive mode exposes the line from the other side. If the node attaches before predictive preparation completed—or if it sent an FBU on the old link but did not receive FBack before leaving—it sends an Unsolicited Neighbor Advertisement after attachment and sends or resends the FBU. Lack of FBack leaves the node unable to know whether the previous router processed the earlier request.

The correct state machine therefore cannot use FBack as an arrival receipt. It is a preparation receipt in the scope of the previous link. Nor can HI/HAck stand in for device presence: that exchange describes router-to-router disposition, protected by a security association established outside the fast-handover specification.

The address has more than one truth state

Address handling supplies another set of boundaries that broad status fields tend to erase. The mobile node can formulate a prospective NCoA from the advertised prefix. The new access router can test it with Duplicate Address Detection, accept it, or assign an alternate address in HAck and FBack. After the node arrives, the router can still reject a duplicate through NAACK, requiring another FBU for the replacement.

RFC 5268 acknowledges that collision probability can be very low without being zero. DAD may be disabled only as an explicit deployment choice—for example, where address management makes collision negligible—not because prediction itself proves uniqueness. RFC 4862 remains the relevant address-autoconfiguration boundary.

At minimum, an evidence model needs to separate: locally proposed address; router-tested address; alternate address assigned by the router; address announced after attachment; and address ultimately used by ordinary Mobile IPv6 binding. It also needs the DAD result or the policy under which DAD was bypassed.

Calling all of these “the NCoA” loses both authority and chronology. If an alternate address is returned, the earlier prospective value is still useful evidence of what was attempted, but it must not continue to authorize forwarding or attribution.

UNA converts presence into forwarding eligibility—not delivery

RFC 5268 makes its sharpest statement at the tunnel boundary: establishment of the tunnel alone does not ensure that packets will be received after attachment unless the new access router can detect the mobile node's presence.

After link connectivity is established, the node sends an Unsolicited Neighbor Advertisement with the Override bit cleared. This lets the new router remove a proxy neighbour-cache entry or move an incomplete entry to STALE. It can then begin forwarding packets that arrived through the tunnel, including packets retained in the handover buffer.

UNA is therefore strong attachment-side evidence. It links the mobile node to the new link and unlocks neighbour and buffer processing. But it still does not prove that every buffered packet survived, that later traffic reached the device, that a transport session continued, or that an application remained usable. Those outcomes require their own observations.

The layers are reversible when named precisely: link attachment produced UNA; UNA changed neighbour-cache eligibility; that transition released a named buffer; forwarding emitted particular packets; downstream telemetry showed receipt; application signals showed continuity. Replacing that chain with “handover complete” makes failure analysis impossible precisely when preparation and reality diverge.

A buffer can relocate the loss

Predictive forwarding creates a timing problem. Packets may reach the new router before the device can receive them. Without buffering they can be lost there. In reactive mode, packets can continue arriving at the previous router before it processes the FBU, moving the vulnerable interval upstream.

Buffering narrows that interval but adds capacity and pacing constraints. Releasing a large queue at once can overload the router, the mobile node or the intervening link, creating congestion, jitter and a second wave of loss. RFC 5268 specifies a default drain behaviour based on the original arrival rate and limits the initial burst to no more than five packets back-to-back before metering the remainder.

An operator consequently needs more than a boolean “buffered.” Admission, retained packet range, overflow, release trigger, release rate, forwarded range and receiving-side outcome are different measurements. A smooth application trace might result from successful buffering, but the buffer's existence cannot predict that trace. Likewise, a completed drain only proves that the router emitted what it retained.

The obsolete packet format is itself a generation boundary

RFC 5268 replaced experimental RFC 4068, and RFC 5568 then obsoleted RFC 5268. The replacement is not merely editorial. RFC 5568 changes HI and HAck from the ICMPv6 message forms used by RFC 5268 to Mobility Header messages. Current implementations must not send the old ICMPv6 forms, although compatibility handling can interpret received RFC 5268 messages.

That change matters operationally. Historical captures, device claims and conformance evidence must identify which specification generation they implement. A message called “HI” without its packet format and protocol generation is ambiguous. The old RFC is valuable evidence for the preparation-versus-arrival distinction, but not authority to deploy its superseded encoding.

Ordinary Mobile IPv6 work remains outside the fast-handover shortcut as well. After attachment, binding and Return Routability obligations still have to be observed under the applicable Mobile IPv6 specification. An optimized pre-positioning path does not confer permanent binding authority.

Running code is the boundary sequence

Lu Heng's Running-Code Primacy suggests a less flattering but more useful object of management. The running system is not the product phrase “seamless mobility.” It is a sequence: candidate observation, proxy advertisement, prospective address, FBU authorization, router-to-router disposition, tunnel and buffer preparation, physical attachment, UNA, address confirmation, buffer release, ordinary binding, packet receipt and application outcome.

Reality-layer discipline prevents a receipt in one stage from impersonating the next. Prediction is not preparation. Preparation is not attachment. Attachment is not address uniqueness. Forwarding eligibility is not delivery. Delivery is not application continuity.

Fast handover works by deliberately letting one layer run ahead of another. That lead becomes safe only when the organization preserves the gap instead of erasing it. Every claimed success should be reversible to the exact handover generation, mode, address lineage and last proved boundary. When the trace stops at a prepared tunnel, the honest state is “ready and awaiting arrival,” not “moved.”

Sources