RFC 3102: When a Gateway Lent a Public Address

Summary

RFC 3102 let a private-realm host use a public address—or a shared address plus ports—inside its own stack, while the boundary gateway retained the resource pool, bind, lease and policy.
Making the assignment visible did not remove ambiguity. The host now had to decide whether a destination was local or required the public tunnel, and the RFC recorded no general solution for mixed-realm multi-party applications.

The host acquired a second public presence

Traditional network address translation made its bargain at the boundary. A private host constructed a packet with private addressing; a translator rewrote fields on the way out and tried to reverse the change on the way back. The host could remain unaware, but protocols that carried addresses or depended on unmodified headers exposed the cost of that transparency.

Realm Specific IP moved the bargain. In the architecture published as RFC 3102 in October 2001, the host first asked a gateway for parameters from another addressing realm. The gateway could lend a complete public address or a public address paired with selected ports. The host then used those parameters in its own networking stack and tunneled the packet to the gateway. The gateway removed the outer wrapper and sent a packet whose public-realm source had not been rewritten in transit.

This was more than a different packet trick. The private host temporarily acquired a presence at the public boundary. Its ordinary private address still reached the gateway; the borrowed public parameters represented it beyond the gateway. The packet could carry that public source end to end, yet the gateway still controlled the pool from which it came.

The distinction was formalized in two modes. RSA-IP assigned one public address uniquely to a host for a time. RSAP-IP allowed several hosts to share an address while each received a unique set of ports. Both made the external parameters visible to the host. Neither transferred durable ownership of the address.

A grant created several records, not one fact

RFC 3103 turned the idea into a protocol. A host registered and received a client ID. It requested resources; the gateway answered with an address, perhaps ports, a bind ID, a lease interval, a tunnel type and any applicable flow policy. The host could request an extension, query state, ask to listen for inbound traffic, free a bind and deregister.

Those messages exposed a chain that transparent translation often collapsed into one appliance state. Registration said the gateway recognized a client. Assignment said particular resources were available under particular conditions. The bind connected those resources to the host's private-side identity. The lease limited the grant in time. Flow policy limited the remote addresses or ports for which it could be used. The tunnel carried packets across the realm boundary.

None of those records alone proved the next. An assignment response did not prove that the host installed a route. A bind did not prove that the tunnel was functioning. A packet leaving the host did not prove that the gateway admitted it. An admitted outbound packet did not prove that a reply returned to the same bind. RSIP made the state machine inspectable, but only running observations could establish the assembled path.

Control therefore remained asymmetric. A host could suggest an address or port, but the gateway could refuse because the resource was unavailable, already in use or prohibited by policy. A packet using an unassigned address, tuple, remote endpoint or tunnel was to be dropped. The host wrote the public source into the packet; the gateway decided whether that use belonged to a live grant.

Locality became a decision the host had to make

Host awareness solved one class of hidden rewriting and created another question: which address realm should a packet use? A destination on the private network might be reachable directly. A public destination required the RSIP interface and tunnel. The same host now needed enough topology knowledge to choose.

On a single subnet, a mask could answer. In a more complex private network, RFC 3102 proposed that the gateway keep lists of private networks and answer queries. When routing information changed faster than an RSIP session, the host might have to ask about every destination. The document was unusually candid: a robust general solution had proved difficult, and the severity of the problem was not known.

That uncertainty mattered most when applications treated an IP address as a global endpoint identifier. In a multi-party exchange, one participant could pass an address to another without knowing whether the receiver belonged to the private or public realm. An RSIP host might advertise its private address to a public party, or force local peers through the public representation and gateway. RFC 3102 said there was no known general solution.

The problem was not simply an implementation bug. A single application conversation was trying to use one address as topology, reachability hint and identity across participants with different views of the realms. RSIP could make the borrowed parameter explicit, but it could not make locality universal.

A lease bounded authority but complicated reuse

Time made the grant intelligible. Each bind was meant to carry a lease. The host could extend or free it; the gateway could let it expire or deallocate it. That bounded stale authority and allowed scarce addresses and ports to return to the pool.

Transport state did not obey the administrative clock so neatly. TCP could retain a closed tuple in TIME_WAIT. If a host returned an address-and-port pair and the gateway immediately lent it to someone else, packets or collision protections from the old connection could overlap the new grant. A lease end therefore did not automatically mean immediate, risk-free reuse.

Failure exposed the same separation. After a host reboot, the gateway might still remember binds the host had forgotten. After a gateway reboot, the host might continue to hold parameters the gateway no longer recognized. RFC 3103 described registration and error exchanges for reconstructing the relationship, but the protocol could not pretend that either side's memory was the whole truth.

Useful evidence would preserve both timelines: client ID, bind ID, granted tuple, lease start and expiry, extensions, free or deallocation event, host reboot, gateway reboot and the first packet accepted after reconciliation. An expired lease, a forgotten bind and a late packet are different events even when they refer to the same address.

Sharing an address separated location from identity

RSA-IP could interact with dynamic DNS much like a temporary DHCP address because one host held the whole address during the lease. RSAP-IP was harder. Several fully qualified domain names could resolve to one address even though different hosts controlled different ports. A public peer might reasonably assume that the services at one address belonged to one logical host. The RFC warned that shared-address RSIP and dynamic DNS should be combined cautiously, if at all.

IPsec made the identity problem sharper. RFC 3104 allowed multiple RSIP clients behind one public address to initiate IKE and IPsec sessions toward a peer that did not understand RSIP. The visible source address could not identify the real peer. IKE client identifiers had to carry that role instead.

Return traffic also needed richer keys. IKE responses could be separated by destination port, initiator cookie and destination address. AH or ESP packets used protocol, Security Parameters Index and destination address. The SPI had to be unique in both the client's and the gateway's spaces. A shared address was still useful as a locator, but it was no longer sufficient as a principal.

Even this extension had limits. It focused on client-initiated sessions, required coordination with IPsec implementations and warned that bump-in-the-stack designs would not simply work unchanged. End-to-end packet headers survived the gateway, yet application and security behavior still depended on explicit accommodation.

Discovery selected a control point; it did not authorize one

A host could not request a lease until it found an RSIP server. RFC 3105 used the Service Location Protocol for that step. A gateway advertised a service:rsip URL, capabilities, a lifetime and optionally its load. Directory Agents or multicast discovery returned candidates. Scopes could steer particular clients toward particular realms, and a client could prefer the server reporting fewer connections.

Those records were selection inputs. An SLP scope was explicitly not access control. A service advertisement showed what a server claimed to offer, not that the client was entitled to resources. A load value could become stale before selection and did not guarantee that the chosen gateway remained least loaded. Discovery, authorization, assignment and successful forwarding stayed separate.

This layering completed the control surface. An administrator influenced which gateway a host found. The gateway decided which resources it granted. The host decided how to use a valid grant and which destinations appeared local. Remote peers decided how to interpret the address and identifiers they received. Packet observations decided whether the chain worked.

The experiment was valuable because it exposed its cost

RFC 3102 described RSIP as a kind of fix for NAT, not a long-term solution to address shortage. The entire series remained Experimental. Its IESG note warned of significant host and gateway modifications, applications harmed by floating ports and operational complexity. The selected sources provide no census showing broad deployment or evidence that RSIP displaced ordinary NAT.

That does not make the episode a failed footnote. RSIP exposed what transparent translation concealed: address sharing is an allocation and state-distribution problem before it is a packet-rewriting problem. Moving public parameters into the host made the grant visible, but visibility required a protocol for registration, leases, policy, discovery, failure recovery and locality.

Its deepest historical lesson is the limit of an address. A borrowed public address could identify a packet's presence in one realm. It could not by itself identify one durable host, prove authorization, choose the correct local path, authenticate an IPsec peer or demonstrate delivery. The gateway lent the address. The rest of the Internet still had to assemble—and observe—the chain that made it useful.

The Gateway Lent the Address. Locality Became a Protocol: RFC 3102

Why it matters

Summary

The host acquired a second public presence

A grant created several records, not one fact

Locality became a decision the host had to make

A lease bounded authority but complicated reuse

Sharing an address separated location from identity

Discovery selected a control point; it did not authorize one

The experiment was valuable because it exposed its cost

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing