Summary

  • A mobile node's genuine home address could fail a visited network's source-prefix check. Legitimacy of the address did not establish its topological suitability at that point of emission.
  • Reverse tunneling gave the journey to the home agent an appropriate outer source while preserving the original communication endpoints inside the packet.
  • Direct and encapsulating delivery offered different choices. Their negotiation, locality checks and binding checks remained separate from encryption, firewall traversal and successful end-to-end delivery.

An honest address at an implausible exit

The packet was addressed to its correspondent and carried its sender's home address. Nothing about the mobile node's claim to that address had changed. What had changed was where the packet entered the network. A source that made sense at home could look inappropriate when it emerged from somebody else's connection.

This was an awkward consequence of a useful separation. RFC 2002, published in October 1996, described IPv4 mobility across subnets while retaining a home address. A home agent could intercept traffic for that address and tunnel it to a care-of address representing the mobile node's current point of delivery. The correspondent did not have to treat every move as a completely new endpoint.

A care-of address could belong to a foreign agent serving several mobile nodes, or to the mobile node itself. In the first arrangement the foreign agent terminated the tunnel and delivered locally. In the second, the mobile node terminated it. The shared-agent case did not require each visitor to obtain a separate local IPv4 address.

Incoming traffic therefore had a reason to pass through the home agent. Outgoing traffic did not necessarily have the same requirement. The original model assumed routing by destination rather than source: the mobile node could send toward its correspondent from the visited network, retaining its home source address, without first returning through its home agent.

That assumption described forwarding, but it did not settle admission. A network could ask whether a packet with that source ought to be arriving over that particular connection before consulting the route to its destination.

The filter did not have to accuse the sender of theft

RFC 2827, issued as BCP 38 in May 2000, recommended restricting source prefixes accepted from downstream networks. The purpose was to reduce source-address spoofing. Knowing a route to a destination was not, by itself, a reason to accept an arbitrary source.

The mobile node could fall outside the permitted range while using its own address honestly. Its home prefix belonged somewhere else. The filter was testing topological plausibility, not adjudicating ownership of the address or the character of the person operating the computer.

The document explicitly recognised the Mobile IP difficulty and pointed to reverse tunneling. This was not a demand to abandon source validation whenever a visitor arrived. Nor did it require the application to discard stable addressing altogether. The problem could be approached by giving the communication endpoint and the current transit segment separate address fields.

Source-prefix filtering also had a limit in the other direction. Spoofing an address within an allowed prefix could still pass that check. A suitable prefix was not proof of an individual sender's identity. The reverse-tunnel design would need to preserve that distinction rather than turn one useful test into universal trust.

The detour supplied a different outside

The extension appeared in RFC 2344 in May 1998 and was revised by RFC 3024 in January 2001. Reverse described the direction relative to the conventional tunnel from home agent to mobile node. Outgoing traffic could now travel to the home agent first, then continue to the correspondent.

The mechanism relied on the distinction set out in RFC 2003. An inner IP header described the original communication; an outer header described the tunnel endpoints. On the foreign-agent-to-home-agent leg, the outer source was the foreign agent's care-of address and the outer destination was the home agent. The mobile node's home address remained the source inside.

The visited network thus saw an outer source appropriate to that departure point. The original endpoint had not been renamed. One packet carried two address relationships, each useful to a different part of the journey.

Encapsulation did not make the contents secret. Nor did preserving the inner endpoints imply that every inner bit stayed unchanged: forwarding could affect fields such as TTL. And corresponding tunnel endpoints and encapsulation in both directions did not guarantee that the packets traversed the same physical links in reverse order.

The extra wrapper solved a particular mismatch. It could not make every possible intervening policy accept the result. RFC 3024 explicitly excluded a general solution to firewall traversal from its scope.

Two ways to hand the packet to the agent

Direct delivery let the mobile node use the foreign agent as its default router and send the original packet without an additional local wrapper. The agent performed the interception and encapsulation needed to send it home. This supported unicast reverse tunneling, but not selective reverse tunneling.

Encapsulating delivery made the node perform an initial wrapping operation. It addressed that wrapper to the foreign agent, which removed it and applied another one for the home agent. There were two distinct handoffs, not one unchanged outer header travelling through both agents.

The first wrapper's source was still the mobile node's home address. Only when the foreign agent sent the second wrapper toward the home agent did the outer source become the care-of address. Collapsing the two steps would wrongly suggest that the mobile node used the foreign agent's address as its own source on the local leg.

The additional operation created a choice. After encapsulating delivery had been negotiated, the foreign agent must not reverse-tunnel the mobile node's unencapsulated packets. It handled those through ordinary forwarding instead. A mobile node could therefore attempt to reach a locally available resource, such as a printer, without first sending every exchange home.

Ordinary forwarding still depended on local routes and policy. The specification did not guarantee that the printer was reachable or would accept the request. It preserved the choice of treatment, not an exemption from the visited network's rules.

Encapsulating delivery was also required for broadcast and multicast reverse tunneling through a foreign agent. The two styles therefore differed in service scope as well as packaging. An agent could not erase that distinction by helpfully putting every recognisable mobile packet into the same return path.

An offer, a request and a narrower agreement

The T bit in an agent advertisement offered reverse-tunnel service. The T bit in a Registration Request asked to use it. An advertisement was not acceptance of a particular request, and acceptance was not observation of data arriving at the correspondent.

Encapsulating delivery used an extension of type 130 and length zero. Without it, the requested style was direct. It must not accompany a request with T clear. The extension had a specified position relative to authentication extensions, and the foreign agent consumed it rather than passing it on unchanged to the home agent.

This was a local delivery choice within a particular relationship. It was not a declaration that every downstream network understood or admitted the resulting traffic.

The implementation requirements also changed. RFC 2344 required a foreign agent advertising reverse tunneling to support both delivery styles. RFC 3024 kept direct delivery mandatory but made encapsulating delivery recommended. Code 79 could identify rejection of an unsupported delivery style.

The IANA Mobile IP registry confirms that assignment. A stale parenthesis in RFC 3024 says 79 was not yet assigned, whereas its allocation section and change appendix record the assignment. Reading the old parenthesis alone would produce a false account of the registry. Historical specifications sometimes require comparison within the document as well as across revisions.

A successful registration could leave no usable exit

If the reverse-tunnel request failed, a node could try again with T clear and obtain a registration. RFC 3024 warned that this might be useless for data transfer. Where source filtering made the reverse tunnel necessary, the successful retry had removed the very function needed to get packets out.

The reply was not lying. It had accepted a less demanding arrangement. The mistake was treating that acceptance as a promise about the entire data path. A compatibility retry could turn a precise refusal into a later failure whose cause was less visible.

Registration also had a locality check. A request had to be sent with TTL 255, and the foreign agent checked for that value. Traversing an IP router reduced it. This limited certain attempts to hijack registration from beyond the local link, but did not authenticate a hostile neighbour already on that link.

At the home agent, the specification required implementation of a decapsulation binding check and recommended enabling it by default. The outer source had to match the registered care-of address, the inner source the mobile home address, and the encapsulation the negotiated method. A missing binding or incorrect encapsulation required the packet to be discarded.

That constrained the transit service. It did not cryptographically authenticate every packet's contents. The text allowed a discouraged exception for an agent terminating unrelated tunnels, so the default recommendation should not be rewritten as a claim that the check was unconditionally active everywhere.

Even the direction of the message updating a binding matters. A verified technical erratum for RFC 3024 corrects Registration Reply to Registration Request in that passage. Copying the uncorrected sentence would give the wrong account of the input that changes state.

Private addresses still needed a place to mean something

RFC 3024's main discussion assumed a common address space. Its appendix considered constrained arrangements involving different spaces, rather than promising general NAT traversal or a cure for arbitrary overlapping private networks.

The foreign and home agents still needed to reach one another in the outer address space. Inner addresses needed the appropriate meaning in their respective communication domains. Repeated private home addresses behind different home agents could be distinguished only with the necessary context.

For local delivery, that included a secure association with the right mobile node at the link layer. The relevant security section required secure link-layer identity for this arrangement and did not recommend unauthenticated shared Ethernet. An extra header could carry context; it could not manufacture a trustworthy local identity by itself.

In November 2010, RFC 5944 still referred to reverse tunneling when discussing ingress filtering. That documents persistence of the architectural issue, not a count of deployments or a claim that all mobile networking followed this model.

The packet that went home first did so to make one part of its journey intelligible to the network carrying it. Its home address could remain stable, its outer source could fit its current departure point, and its local traffic could sometimes remain local. None of those achievements authorised it to cross every boundary. The design worked by assigning different questions to different checks, not by letting one successful check answer them all.