Summary

  • RFC 2002 let a mobile node keep a stable home address while registering a temporary care-of address with its home agent; the resulting mobility binding had a finite remaining lifetime.
  • An authenticated successful Registration Reply proved that the home agent accepted a particular request. It did not prove the node’s physical location, end-to-end delivery, data confidentiality, or broad deployment.

In RFC 2002, mobility began with a refusal to make identity follow attachment. A mobile node retained its home address—the address by which other nodes identified it—even while it operated away from its home network. Delivery moved through a different object: the care-of address, described as the end of a tunnel and associated with the node’s current point of attachment.

That split created a precise evidence boundary. The protocol could establish that a home agent had accepted a temporary forwarding instruction. It could not turn that instruction into proof of geography, possession of a building, or successful delivery of every packet.

A stable name and an expiring instruction

RFC 2002 defined a mobility binding as the association of a home address with a care-of address, together with the binding’s remaining lifetime. The home address was durable. The care-of address was operational and replaceable. It could belong to a foreign agent serving the visited network, or it could be a co-located address acquired by the mobile node itself.

Agent advertisements helped the node discover whether it was at home or away, find an available care-of address, and detect movement. But their timing must not be confused with registration state. The advertisement’s ICMP Router Advertisement Lifetime governed the advertisement; the Mobile IP Registration Lifetime offered a ceiling for registration. Discovery was also not required to be authenticated under RFC 2005. Hearing an agent was therefore not equivalent to an authenticated home-agent commitment.

The commitment came through registration. A Registration Request carried a requested lifetime, the home address, the home agent, the care-of address, a 64-bit Identification field and extensions. The mandatory Mobile-Home Authentication Extension protected the request and reply between the mobile node and home agent. The Identification value had to match in the reply and supported replay protection. Timestamp-based replay protection was mandatory; nonce-based protection was an optional alternative.

If the home agent accepted a valid request, it created or modified the mobility binding. A successful reply could return code 0 or code 1, the latter recording that simultaneous mobility bindings were in force. The granted lifetime could be shorter than the requested one, but not longer. Zero requested deregistration; 0xffff represented infinity. When a finite binding expired, the home agent deleted it without sending an unsolicited reply.

These mechanics make the evidence narrow but useful. An authenticated success reply, considered with its Identification value, addresses and lifetime, is evidence that the home agent accepted that request and installed the corresponding state. It is not merely a statement of intent in an RFC. It is also not an attestation of physical location. A care-of address identifies a tunnel endpoint or attachment context; the protocol does not certify the human, room or jurisdiction behind it.

Acceptance, forwarding and arrival are different events

Once the binding existed, a correspondent could continue sending to the stable home address. The home agent intercepted datagrams on the home network and tunneled them to the care-of address. In the basic model, packets sent by the mobile node could follow ordinary IP routing directly to their destination. The two directions therefore need not traverse the same control point.

That asymmetry matters for historical claims. A binding proves accepted forwarding state at the home agent for a period. It does not prove that the correspondent transmitted a packet, that the tunnel carried it, that the foreign agent or mobile node decapsulated it, or that the application consumed it. Each proposition needs its own observation.

RFC 2005 drew a similar security boundary. The Mobile IP authentication mechanisms addressed the registration protocol; confidentiality and authentication of application data required separate protocols. A valid Registration Reply should not be promoted into a claim that traffic was private, that a correspondent was authenticated, or that the visited network was trustworthy.

What the documentary record supports

RFC 2002 was published as a Proposed Standard in October 1996. RFC 2005 recorded that independent implementations had demonstrated the listed features during 1995 interoperability testing. That is evidence of implementation diversity for the tested functions at that time, not a deployment census and not a guarantee about a current network.

The specification was later obsoleted through RFC 3220, RFC 3344 and ultimately RFC 5944. IANA’s Mobile IPv4 registry preserves message types and reply-code assignments. Those later records show specification and registry continuity; they do not retroactively prove that any particular operator maintained a binding or delivered traffic.

Lu Heng’s “Minimum Initial Specification” offers a useful interpretive lens: the common layer can define a small, interoperable contract while leaving future choices local. “Running-Code Primacy” adds the necessary discipline: published syntax is not operating state. His account of reality layers sharpens the final distinction—documented permission, accepted protocol state and observed network behavior are related, but they are not interchangeable.

The historical achievement of RFC 2002 was not that it made location certain. It made a limited change of reachability expressible, authenticated and temporary without changing the node’s public identity. Its strongest evidence was a timed binding. Its integrity depends on stopping the claim exactly there.

Sources