Summary
- RFC 5142 defines Mobility Header type 12, allowing an authorised home agent to tell a mobile node to stop using one home agent and acquire another.
- The trigger for moving a node is deliberately outside the protocol; maintenance, overload and balancing are possible motives, not facts carried by the message.
- A switch can list preferred alternate home agents, or carry an empty list that sends the mobile node into discovery.
- IPsec protects the switch message, but does not prove that an alternate has capacity, accepted a registration or installed a working data path.
- A Binding Update deleting the old binding acts as acknowledgement when the sender is the current home agent.
- That acknowledgement records departure from the old control state, not arrival at a new operational state.
- Discovery, Home Address continuity, security bootstrapping, new registration and tunnel installation remain separate steps.
- If the mobile node does not respond, the old home agent should not infer its status and should continue service until the binding lifetime expires.
- Switch traffic needs destination-capacity feedback or a conservative rate limit; the default maximum is one message per second.
- Moving across home prefixes can change the Home Address and break existing connections, so same-prefix alternatives are preferred for balancing.
- An accepted new binding is still control-plane evidence. Packet flow and application continuity require later observation.
- Leadership should measure the handoff as a staged evidence chain and preserve the old path until replacement service is proven whenever policy and state allow.
The cleanest receipt closes the wrong question
Suppose an old home agent sends a protected switch instruction. The mobile node validates it and replies with a Binding Update that deletes its old binding. The home agent stops retransmitting. A dashboard turns green: switch acknowledged.
What exactly became true?
The old home agent knows that the mobile node processed enough of its instruction to send the expected control message. It does not know whether the node found a suitable alternative, established new IPsec security associations, received an acceptable Binding Acknowledgement, obtained the same Home Address, installed a tunnel, or delivered one packet through the replacement path. The most legible receipt in the exchange closes the old relationship. It does not certify the new one.
That is the useful tension inside RFC 5142. The protocol is not careless about handoff. It is careful about what one small message can coordinate. The operational mistake begins when a monitoring or workflow system expands that narrow acknowledgement into a claim about service continuity.
A switch carries candidates, not capacity
Home Agent Switch is Mobility Header type 12. It allows a home agent to tell a mobile node to stop using its current home agent and acquire a new one. The RFC names maintenance, load balancing, functional load balancing and renumbering as scenarios. It deliberately leaves the trigger to a backend system or local policy.
The message may include a list of alternate IPv6 home-agent addresses. Preference rules inherited from Mobile IPv6 order the candidates, with equal-preference entries randomised. If the first candidate cannot provide service, the mobile node tries the next. A list with zero addresses means the node must perform home-agent discovery instead.
Nothing in the address list reserves capacity. It does not say that the first alternate has admitted this particular node, that the second is reachable from the node's present attachment, or that any candidate can preserve the current Home Address. The list is a structured proposal. Selection and admission happen later.
A Binding Refresh Advice option can also state how long remains before the old binding is deleted, in four-second units. That deadline makes coordination more explicit. It does not convert the deadline into a guarantee that the downstream work will finish in time.
Authentication stops at the instruction
The switch message uses the IPsec security relationship between home agent and mobile node. ESP integrity protection is required, and confidentiality can hide the alternate-address list. A sender need not be the current home agent if it possesses the appropriate security association; a non-current sender will ordinarily propose itself as the new destination.
These controls answer important questions. Did the message come from a peer with the configured cryptographic relationship? Were the protected bytes altered? Was protected traffic replayed? They do not answer whether the sender's balancing decision was wise, whether a candidate is under pressure, whether credentials for the new relationship can be established, or whether forwarding will work.
Cryptographic identity is not resource admission. Integrity is not continuity. A system that stores only authenticated=true discards the distinctions on which a safe move depends.
One name, two kinds of acknowledgement
RFC 5142 uses the mobile node's next Binding Update as the switch acknowledgement, but the update's meaning depends on who sent the switch.
When the current home agent sends it, the mobile node stops using that agent and sends a Binding Update that deletes the old binding. This proves a control-plane exit. When a non-current home agent sends the message, the mobile node's Binding Update creating a home binding with that sender acts as acknowledgement. This is an attempted control-plane entry.
Collapsing the two into a single metric called “handoff success” removes the most important semantic difference in the protocol. An old-binding deletion can arrive before an alternate is ready. A new-binding request can arrive and be rejected. Even an accepted binding can precede route installation or reveal nothing about packet delivery.
The evidence model should therefore name the receipt: old_binding_deleted, new_binding_requested, new_binding_accepted, new_tunnel_active, packet_observed, application_continuity_observed. The sequence may differ by deployment, but the claims must not be merged.
Silence is explicitly non-diagnostic
The sender retransmits a switch until it receives the applicable Binding Update. The backoff begins at five seconds and rises to a cap of twenty seconds; a home agent may continue more slowly for an indefinite period.
The stronger operational instruction appears after the maximum timeout. If the home binding still exists, the home agent should not infer the mobile node's status. It should continue providing service until the binding lifetime expires.
That boundary matters because silence has many explanations: the switch or response may have been lost; the node may be unreachable; discovery may have failed; key establishment may be delayed; an alternate may have rejected registration; or the node may not have acted. Timeout does not identify which one occurred. Deleting early on the theory that “no response means gone” manufactures an outage from missing evidence.
Binding expiry is not a positive outcome either. It is simply the end of an old lease. A lifecycle event cannot prove that a replacement exists.
The missing middle is the handoff
When an alternate list is absent or exhausted, the mobile node needs discovery. The surrounding Mobile IPv6 specifications separate acquisition of a home-agent address, a Home Address and the credentials or IPsec security associations required for registration. RFC 5026, RFC 6610 and RFC 6611 describe ways to discover or provision pieces of that state. RFC 4640 explains bootstrapping as a larger acquisition problem.
Those steps form the missing middle between the switch and service:
- discover or select an eligible alternate;
- confirm that the alternate can serve the node and preserve the required address context;
- establish the new security relationship;
- send a Binding Update and receive an acceptable status;
- install tunnel and forwarding state;
- observe packets on the new path; and
- verify the application or subscriber outcome that the operator intends to claim.
A Binding Acknowledgement belongs in this chain, but it is not the final receipt. It can say that a Binding Update was accepted. It cannot see a stalled tunnel farther along the path or an existing transport session damaged by a path change.
Home Address continuity deserves special treatment. An alternate on another home prefix may require the node to change its Home Address. Existing connections can then lose connectivity even if the new registration succeeds perfectly. RFC 5142 advises against using the mechanism in that situation and recommends same-prefix alternatives for load-balancing cases. “Registered” and “continuous” are different outcomes by design.
Rate limiting is an admission problem
A home agent that can emit many switch messages can transfer more work than a prospective destination can absorb. RFC 5142 therefore calls for a feedback loop from the new home agent's resources to the sender, or a maximum switch rate set far below the rate at which the destination can accept new registrations. The default maximum is one message per second.
That limit is not merely anti-congestion etiquette. It reveals the governing dependency: the pace of departure must be controlled by evidence about arrival capacity. Counting outgoing switch messages is easy. Measuring IKE work, binding admissions, tunnel creation and packet-path pressure at the destination is harder and more useful.
The path itself can change the result. A new home agent may be healthy while its route adds latency, loss or reordering that disturbs transports. A balancing operation can therefore succeed in its control plane and fail in the experience it was supposed to protect.
Sources
- RFC 5142, HTML
- RFC 5142, text
- RFC Editor record
- IETF Datatracker
- Document history
- RFC 5142 errata search
- IANA Mobility Parameters
- RFC 3775: Mobility Support in IPv6
- RFC 6275: Mobility Support in IPv6
- RFC 4301: IP Security Architecture
- RFC 4303: IP Encapsulating Security Payload
- RFC 4877: Mobile IPv6 with IKEv2 and IPsec
- RFC 5026: Mobile IPv6 Bootstrapping
- RFC 6611: Mobile IPv6 Bootstrapping for the Integrated Scenario
- RFC 6610: DHCP Options for Home Information Discovery
- RFC 4640: Problem Statement for Mobile IPv6 Bootstrapping
- RFC 4192: Renumbering IPv6 Networks
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- 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
