Summary

  • RFC 5266 lets MOBIKE update the VPN gateway when an external access address changes while the same VPN-TIA remains the Mobile IPv4 care-of address. In that case, the internal home agent is intentionally unaware of the outer move.
  • A defensible continuity receipt must join the access change, IKE/MOBIKE update, VPN-TIA continuity or replacement, any required Mobile IPv4 registration, reverse-tunnel forwarding and application observation. Success at one layer cannot certify the others.

The move happened in only one observer's world

A mobile node left one external access network and joined another. Its public-facing address changed. MOBIKE updated the VPN gateway, allowing the IKEv2/IPsec security association to continue over the new path. From the gateway's point of view, mobility occurred and the update completed.

Inside the encrypted tunnel, however, the node still used the same VPN tunnel inner address. That VPN-TIA remained the co-located care-of address registered with the internal home agent. From the i-HA's point of view, nothing moved.

This is not inconsistent logging. It is the architecture. Each observer reports a different coordinate. The error begins when an operator promotes the gateway's success into “the enterprise session survived” or reads the home agent's silence as confirmation that nothing changed.

Three addresses describe three layers

RFC 5266 keeps a stable Mobile IPv4 home address for the mobile node wherever it attaches. Outside the enterprise, a MOBIKE-capable VPN gateway gives the node a VPN-TIA that is normally routable inside the trusted network. The node registers that inner address with the i-HA as its Mobile IPv4 care-of address.

The node also has an address on the external access network. That outer address is what IKEv2/MOBIKE updates when the node roams outside. The VPN-TIA can remain stable across that change, and the Mobile IPv4 home address remains stable above both.

Collapsing the access address, VPN-TIA and home address into one “current IP” destroys the evidence model. A receipt must name which coordinate changed, which component accepted it and which state was deliberately preserved.

The nested tunnel has two control planes

The resulting path is a Mobile IPv4 tunnel inside an IPsec tunnel. The outer security association runs between the mobile node and the mobility-aware VPN gateway. The inner Mobile IPv4 tunnel runs between the mobile node and the internal home agent. RFC 5266 requires reverse tunnelling through the home agent in this arrangement.

MOBIKE can prove that the VPN peer accepted an address update for the IKE/IPsec relationship. Mobile IPv4 registration can prove that the home agent accepted a binding from home address to care-of address. Neither response proves that packets crossed both tunnels, that reverse forwarding selected the expected route, or that an application acknowledged useful work.

The architecture therefore needs two protocol receipts and at least one data-plane observation. A single green “mobility succeeded” indicator erases the component that did—and did not—observe the move.

Stable TIA is an optimization with an observability cost

Keeping the same VPN-TIA while the outer address changes avoids an unnecessary Mobile IPv4 binding update. The i-HA need not process movement that the VPN layer has already hidden. That reduces signalling and keeps the inner coordinate stable.

The same property means the home-agent log cannot reconstruct the physical sequence of external attachments. Its unchanged binding is evidence of inner-address continuity, not evidence that the access path stayed still. For incident review, the outer MOBIKE history and the inner binding history must be joined by the VPN security-association identity and the TIA assignment.

If the TIA changes after reconnection, or the node uses a different VPN gateway, the optimization boundary ends. RFC 5266 says the node should send a Registration Request to update the i-HA with the new co-located care-of address. At that moment both layers have changed, but their commits remain separate.

Boundary crossing creates parallel work, not one verdict

When connectivity changes, RFC 5266 combines the trusted-network detection inherited from RFC 5265 with MOBIKE. If a VPN tunnel exists and the outer address changes, the node sends a MOBIKE message to the VPN gateway while also sending an unencapsulated Mobile IPv4 Registration Request directly to the i-HA.

A response from the gateway without a response from the internal home agent supports the outside path. A protected i-HA response satisfying the TNC conditions supports the inside classification. The node should not send ordinary traffic while it is deciding.

These parallel operations are not interchangeable. The gateway can be reachable from both sides of the boundary; an IKE mobility response therefore does not identify the network as trusted. Conversely, a direct i-HA response can justify dropping the VPN path, but does not prove that an earlier application flow has already migrated without interruption.

Moving out requires a second commit

The most revealing sequence begins inside. The node is using Mobile IPv4 directly and no VPN for data. It moves to an untrusted network. It begins an IKE mobility exchange—or establishes a new VPN—and simultaneously tests direct i-HA reachability.

If no direct home-agent reply arrives but the VPN is established, the node sends a new Mobile IPv4 Registration Request through the VPN. Only after the home agent replies can it communicate through the tunnel using its home address.

A successful VPN establishment at step one is therefore not the final readiness event. It creates the protected path on which the inner registration can occur. Reporting the outer commit as service restoration starts the clock too early and can hide a failed or delayed inner binding.

Some traffic sits outside both continuity claims

RFC 5266 notes that some VPN clients allow direct Internet traffic from an untrusted network, bypassing the enterprise tunnel. The document does not forbid it, but that traffic receives no mobility or session-continuity support from this solution. Traffic carried in the Mobile IP tunnel, by contrast, always traverses the VPN gateway.

This distinction matters for telemetry. Seeing packets from the new access address does not show that enterprise traffic resumed. A direct flow, a VPN outer flow and a Mobile-IP-inside-IPsec flow can coexist on the host. Evidence must classify the flow before using it as proof of continuity.

NAT adds another layered translation. In mc mode IPsec NAT traversal may operate outside, while Mobile IPv4 NAT traversal may also be needed inside if the TIA uses private address space. A successful NAT binding at one layer does not describe the other.

Build a layered mobility receipt

For consequential continuity claims, retain:

  • device, interface and old/new access-network addresses with link-change time;
  • IKE security-association identity, VPN gateway, MOBIKE request and response, and outer path commit;
  • old/new VPN-TIA, its allocator, lifetime and whether it remained stable;
  • Mobile IPv4 home address, care-of address, registration request/reply and binding version;
  • whether the direct i-HA probe or the VPN-carried registration path was used;
  • TNC, authentication and replay results when classifying the security boundary;
  • reverse-tunnel state, IPsec selectors, NAT traversal state and gateway forwarding evidence;
  • packet counters at entry and exit of both tunnels, with loss and reordering windows;
  • transport reconnection or continuity evidence; and
  • application acknowledgement and user-visible outcome, if that is the claim.

The receipt should tolerate a legitimate asymmetry: MOBIKE changed while the i-HA binding did not. It should flag a different asymmetry: the TIA changed but the home-agent binding never followed.

Sources