Summary

  • RFC 3344 allowed a Mobile IPv4 Registration Request to set the S bit, asking the home agent to accept a new care-of address while retaining prior mobility bindings.
  • When the home agent supported that option, it copied each arriving datagram to every active care-of address; a successful new registration therefore did not prove one exclusive current path or the retirement of the old one.

A binding table is easy to imagine as a single line: home address, current care-of address, expiry. RFC 3344 made that mental model unsafe. The table could contain several live rows for the same home address. Each row aged independently, and the forwarding behavior was not selection among them. The home agent replicated traffic across them.

This was not an accidental race left vague by the specification. The Registration Request carried an explicit S bit for simultaneous bindings. A mobile node set it when it wanted the home agent to preserve earlier mobility bindings. Without the bit, the new binding replaced the old set. With the bit and a capable home agent, the old entries stayed.

One address did not mean one tunnel endpoint

Mobile IPv4 separated a stable home address from the care-of address used as a tunnel endpoint while the node was away. A care-of address could belong to a foreign agent that decapsulated traffic, or be co-located on the mobile node itself. Registration associated the home address with a care-of address for a granted lifetime.

That association was a forwarding instruction, not a geographical certificate. It did not establish where a person stood, whether a radio link remained healthy, whether a foreign agent still had matching visitor state or whether an application received a byte. Authentication protected the registration exchange; it did not enlarge the meaning of the stored address.

The S bit changed the cardinality of that instruction. RFC 3344 anticipated a node within wireless range of more than one foreign agent. If simultaneous bindings were allowed, a single home identity could fan out to several registered endpoints. The home agent intercepted a datagram addressed to the home address, encapsulated a separate copy for each care-of address and sent them all. Duplicate arrival was a stated consequence of the design, consistent with IP's permission to duplicate datagrams.

Two success codes told different stories

The Registration Reply prevented “accepted” from collapsing into one outcome. Code 0 meant registration accepted. Code 1 also meant registration accepted, but simultaneous mobility bindings were unsupported. IANA's current Mobile IPv4 registry still preserves those two successful meanings.

For a node that requested retention, code 0 allowed the old and new entries to coexist. Code 1 said the new registration succeeded without the requested simultaneous capability. Neither code proved that a particular tunnel subsequently worked. A third result, code 135, denied a request because the home agent already had too many simultaneous bindings. Capability, admission and delivery remained different decisions.

The distinction matters in logs. A dashboard that converts every 0 or 1 into the same green “registered” state loses the fact needed to interpret later duplicates or gaps. Conversely, seeing two copies is not enough to accuse the network of replay. The operator must first know the accepted S request, the reply code, the binding list and the lifetime of each entry.

The entries died one at a time

RFC 3344 also defined three deletion scopes. A zero lifetime with the home address removed every mobility binding and ended mobility service. A zero lifetime naming a particular non-home care-of address deleted only that row. The other active rows remained. A nonzero registration added the requested address; prior entries survived only when S was set and supported.

Expiry followed the same set logic. When one binding's lifetime ran out, the home agent deleted it but had to retain the other non-expired simultaneous bindings. It sent no Registration Reply merely because time expired. A foreign agent's visitor-list entry could age out naturally. The absence of a fresh reply was therefore not evidence that all paths had ended, just as deletion of one row was not evidence of total unreachability.

Even retransmission was bounded. A duplicate current Registration Request could not extend the lifetime beyond the original grant. The Identification field matched requests to replies and helped prevent replay, but it did not turn a retransmission into a new lease.

Later protocols made the plurality more explicit

RFC 3344 was published in August 2002, replacing RFC 3220 in the line that began with RFC 2002. RFC 5944 replaced it in 2010 and retained the ability to maintain multiple registrations and send a copy to each active care-of address. The RFC Editor lists one held editorial erratum and one rejected technical erratum for RFC 3344; neither changes this mechanism.

Other mobility work made multiple paths easier to name and control. Mobile IPv6 RFC 3775 distinguished a primary care-of address and allowed an earlier primary address to remain temporarily for smoother handover. RFC 5648 added Binding Identifiers for independently managed multiple IPv6 care-of addresses. Experimental RFC 7629 later gave Mobile IPv4 explicit binding identifiers, several tunnels and per-flow policy.

That evolution exposes what the old S bit did not prove. RFC 3344's simultaneous mode was blanket replication, not path selection, load balancing or a health judgement. An active old entry could be useful redundancy, wasted bandwidth or a black hole; the registration record alone could not decide which.

The durable historical lesson is to keep a set-shaped ledger for set-shaped control. Record the requested retention, reply capability, accepted addresses, individual expiry, tunnel copies and observed delivery separately. The newest address is not automatically the only address, and the same payload on two paths is not automatically a fault.

Sources