Summary

  • RFC 5177 sets the main Mobile IPv4 Registration Reply to success when forwarding is established for at least one Mobile Network Prefix. Other prefixes in the same request can be unauthorized, invalid or unable to obtain forwarding resources.
  • An update is also a replacement inventory: a prefix present in the Home Agent's registration table but absent from the new explicit request must be deleted and its forwarding disabled. A green top-level result can therefore coexist with a narrower moving network.

The reply said success because one subnet made it through. A second had no authorized Home Address-to-prefix pairing. A third passed authorization but could not obtain forwarding resources. A fourth was not in the new request at all, so the Home Agent removed the old table entry and stopped forwarding it.

That is not a fictional failure mode added to a clean protocol. It is a faithful reading of RFC 5177's control model. Network Mobility for Mobile IPv4 lets one Mobile Router carry several network segments as it changes its point of attachment. The router can name those Mobile Network Prefixes explicitly; the Home Agent answers prefix by prefix. Yet the Registration Reply also has a main status, and that status becomes zero as soon as forwarding setup succeeds for at least one prefix.

A dashboard that retains only that main code has not summarized the transaction. It has discarded its scope.

One message contains two verdict layers

In explicit mode, the Mobile Router adds a Mobile Network Request extension for every prefix it wants the Home Agent to serve. Each prefix is checked against a Prefix Table indexed by the router's Home Address. No matching pair means MOBNET_UNAUTHORIZED. An authorized prefix still has to obtain forwarding state; resource or device failure produces MOBNET_FWDING_SETUP_FAILED. An invalid length receives its own code as well.

These are not explanatory annotations on one global verdict. They are the verdicts for distinct pieces of network reachability. RFC 5177 requires the reply to contain at least one Mobile Network Acknowledgement extension so the router can know that the extensions were processed rather than silently skipped.

The main reply answers a different question: did any prefix succeed? If yes, the proper code is zero. If every requested prefix fails, it becomes HA_MOBNET_ERROR. Success at that layer therefore means “non-empty accepted subset”, not “requested set reproduced exactly”.

That distinction is uncomfortable because many operational systems prefer one state per registration. But a moving network is not one Boolean object. It is a set whose members have independent authority and resource outcomes.

Omission is an action, not blank space

The more consequential rule appears during an update. The Home Agent compares the prefixes already stored for the Mobile Router with the prefixes included in the new request. Any existing prefix missing from the request must be deleted from the registration table, and forwarding for it must be disabled.

This gives omission replacement semantics. It is valuable when the router intentionally withdraws a subnet. It is dangerous when the request was constructed from an incomplete inventory. A stale configuration source, serialization limit or split-brain controller can omit a prefix without ever sending an explicit “delete” instruction. The protocol still interprets the new set as authoritative.

Suppose three prefixes were working yesterday. Today's request includes two; one succeeds, the other fails authorization. The main reply may still be successful because one obtained forwarding. Meanwhile the omitted third prefix is removed. “Registration succeeded” hides both the rejected member and the withdrawn one.

The safe receipt is the set difference: intended before, requested now, acknowledged per prefix, installed after. Without all four views, an operator cannot tell planned contraction from accidental disappearance.

Authentication does not grant every prefix

RFC 5177 protects its extensions through the Mobile IPv4 registration authentication rules. The authenticator covers the prefix extensions in explicit mode. That establishes message integrity and peer context. It does not make every named network belong to that Mobile Router.

The Home Agent must separately verify authority for each prefix before anchoring it. This is precisely why the Prefix Table exists. An authenticated router can submit a request that is valid as a message and invalid in scope. Compressing those checks into “authenticated registration” gives cryptography authority it never exercised.

The converse matters too. A failed prefix does not necessarily invalidate the router or every other prefix. The per-prefix codes preserve the narrowness of the decision. That is better coordination: admit what can be justified, reject what cannot, and leave enough evidence to reconstruct both.

Installed forwarding is not advertised reachability

Even a per-prefix success does not finish the evidence chain. The Home Agent creates forwarding toward the current Care-of Address and maintains a bidirectional tunnel. Reachability beyond that anchor can depend on aggregation under a home-network prefix or on route propagation to other networks. A tunnel can exist while route advertisement is stale; an advertisement can exist while packet forwarding is broken.

RFC 5177 is explicit about another boundary. Its mobility extensions manage movement of the Mobile Router; they are not the channel for topology changes inside the moving network or at home. A dynamic routing protocol over the tunnel may carry those changes. When routing is the prefix authority, the same subnet should not also be sent in the registration request, because two sources can produce incoherent forwarding information bases. Implicit mode is recommended for that arrangement.

Thus there are at least three inventories to reconcile: the registration table, the routing system and the forwarding plane. The top-level reply observes only a bounded part of the first transition.

A nested network can register and still fail to carry traffic

The standard permits nested Mobile Routers without imposing a depth limit. It also states two things the registration machinery does not solve: physical loops in the nesting can block datagrams, and every level adds a tunnel header that reduces usable MTU. With a Foreign Agent Care-of Address, inbound traffic can already require double tunnelling before nesting adds further overhead.

These are not reasons to call registration success false. They are reasons to keep its claim exact. The Home Agent can correctly report that it authorized and installed forwarding for a prefix while a loop, MTU failure, stale route or remote application prevents useful delivery. A correct local receipt and a failed service outcome can coexist.

Dynamic allocation keeps the same granularity

RFC 6626 later allowed a Mobile Router to request allocation by sending a zero Prefix field, optionally with a length hint. The Home Agent may return an allocated prefix or a negative result. Multiple allocation requests can share one registration. Unsuccessful assignment receives MOBNET_UNASSIGNED; successful allocations inherit the binding lifetime.

This update does not turn the bundle into all-or-nothing allocation. One returned prefix still does not prove that every requested allocation succeeded. Nor does a length hint bind the Home Agent to that size. Capacity limits also become an explicit security concern: implementations should constrain the count and size of allocations to resist address exhaustion.

The durable lesson is not “green is bad”. It is that green needs a stated denominator. For RFC 5177, the denominator is the full intended prefix set. If the system cannot display that set and its per-member results, it cannot honestly claim that the moving network survived the update.

Sources