Summary

  • RFC 3963 let a Mobile Router move one or more Mobile Network Prefixes while nodes behind it remained unaware of the mobility; a status-zero Binding Acknowledgement carrying the R flag confirmed Home-Agent processing and prefix forwarding, not per-node reachability.
  • Explicit prefix options, implicit preconfiguration and dynamic routing created different evidence chains. The durable operational record therefore separates binding acceptance, prefix authority, installed routes, tunnel health, node probes, sessions and delivered services.

Imagine a network inside a train, aircraft or vehicle. Its cameras, terminals and sensors keep stable addresses and continue treating one gateway as home. Only the gateway—the Mobile Router—learns that the outside attachment changed. That was the economy offered by RFC 3963, published on the Standards Track in January 2005: move the network without forcing every Mobile Network Node to become a mobility participant.

The Mobile Router acquired a Care-of Address while away, sent a Binding Update to its Home Agent and asked for Mobile Router treatment by setting the R flag. The Home Agent bound the router’s Home Address to the new Care-of Address. It then intercepted packets for authorized Mobile Network Prefixes and carried them through a bidirectional tunnel to the Mobile Router. Return traffic followed the tunnel back. To the nodes inside, movement could remain invisible.

That compression was powerful precisely because its proof was narrow. A positive Binding Acknowledgement with status zero and the R flag allowed the Mobile Router to assume that the update had been processed and forwarding for its prefixes had been established. The acknowledgement did not enumerate downstream machines, open their sockets, preserve their sessions or test their applications. It was a control-plane receipt for a Home Address, a Care-of Address, a prefix set and forwarding state.

The R flag marked a request, not an identity

The Mobile Router set R in its Binding Update. A Home Agent accepting the request set R in the positive acknowledgement; a Correspondent Node was not supposed to grant that treatment. The bit changed how the receiving Home Agent processed a mobility binding, but the bit by itself did not authenticate the sender. RFC 3963 required signaling between Mobile Router and Home Agent to be authenticated with IPsec. The protected association supplied authenticity; the flag supplied semantics within that association.

This distinction matters because operational dashboards often promote a protocol bit into a broader assertion. R=1 cannot mean “this is unquestionably a router,” any more than status=0 can mean “the network is healthy.” A useful receipt preserves the Binding Update sequence number and lifetime, the H and R flags, exact tunnel endpoints, the IPsec association, the resulting acknowledgement and the route objects installed because of it.

The document’s place in the mobility family helps fix the scope. RFC 3775 supplied the contemporary Mobile IPv6 host machinery; RFC 6275 later revised that base. RFC 3963 added a network behind the mobile endpoint. It did not turn one control exchange into observation of everything inside that network.

Three ways to know which prefixes belonged

In explicit mode, the Binding Update carried one or more Mobile Network Prefix options. The Home Agent could compare those assertions with a Prefix Table recording which prefixes the Mobile Router was authorized to use. This was not best-effort assembly. If the Home Agent could not establish forwarding for every listed prefix, it was required to forward none and reject the update with status 141. A prefix the router was not authorized to use produced status 142.

The all-or-nothing rule kept the acknowledgement intelligible. Otherwise one status could conceal a partially moved network. Yet a Prefix Table match remained an authorization fact, not proof that a sensor or server using an address within the prefix was alive.

Implicit mode inverted the evidence location. The Binding Update omitted Mobile Network Prefix options; the Home Agent obtained the prefix set from information configured outside the message. If it had no such information, it rejected the update with status 143. The same positive acknowledgement could therefore rest on bytes carried in the current request or on an operator-maintained record elsewhere. A serious audit records which mode was used and the version and owner of the external data.

Dynamic routing over the tunnel offered a third path. It could adapt the prefix view, but it also changed what had to be protected and observed. RFC 3963 warned that routing exchanges might reveal internal topology and recommended ESP confidentiality for them. “The Home Agent has a route” was thus never a complete provenance statement: the route might be static, explicitly requested, implicitly configured or learned by a routing protocol.

The sharpest warning appeared in the discussion of static routes. They saved signaling, but they could remain installed even while the associated Mobile Router was unreachable. A route table could truthfully describe intended forwarding and still lie about present liveness. That sentence turns the RFC from a mobility design into an evidentiary lesson.

The tunnel concentrated both convenience and failure

Under basic support, traffic between Mobile Network Nodes and Correspondent Nodes passed through the Home Agent. Downstream, the Home Agent encapsulated packets to the Care-of Address. The Mobile Router checked the outer source as the Home Agent unless tunnel-mode IPsec already provided that protection, and checked that the inner destination belonged to a Mobile Network Prefix before forwarding it inside.

Upstream checks were shared. The Mobile Router was expected to reject inner sources outside its Mobile Network Prefixes. The Home Agent performed its own topological check before releasing tunnelled traffic. These controls limited address misuse. They did not authenticate an application user, attest a device or prove that the final service completed.

Basic support also did not define route optimization for Mobile Network Prefix traffic. The Home-Agent path could be longer than the direct path, and nesting could multiply tunnels when Mobile Routers formed a tree. RFC 4885, RFC 4886 and RFC 4887 documented terminology, goals and the network-mobility problem space. RFC 4888 analyzed route-optimization problems, while RFC 4889 mapped the solution space. Their existence is a reminder that “forwarding installed” and “path optimized” were separate milestones.

Later documents changed adjacent parts without erasing the boundary. RFC 5488 specified a DHCPv6 prefix-delegation model for NEMO; RFC 6276 supplied another DHCPv6 prefix-delegation mechanism for a mobile network; RFC 6089 described flow bindings for Mobile IPv6 and NEMO. Each creates additional evidence and policy surfaces. None makes a Binding Acknowledgement a per-node probe.

The maintained record matters too. The RFC Editor information page, RFC 3963 errata search, IETF Datatracker record and IANA Mobility Parameters registry establish publication status, reported corrections and assigned protocol values. A registry assignment establishes coordination. It does not establish adoption or correct operation at a particular site.

The operational ledger should therefore be deliberately plural. Preserve movement detection, Home Address and Care-of Address; Binding Update sequence, lifetime, flags and prefix options; explicit, implicit or routing mode; prefix evidence and authorization result; the all-or-nothing decision; acknowledgement status and R flag; IPsec and tunnel endpoints; every route installed or removed; outer and inner address checks; per-prefix probes; and independent observations for each node, session and service. The chain can then say exactly how far success travelled.

RFC 3963 moved a network by narrowing what had to move. Its lasting discipline is the converse: never widen what one successful signal is allowed to prove.

Sources