Summary

  • RFC 1504 let independently numbered AppleTalk internets meet across tunnels by carrying a tunnel-unique identity and mapping it into a locally usable network range.
  • The local range was a presentation, not a new network. If it returned through a redundant path without its domain provenance, the originating router could mistake its own mapping for an actual network, map it again and create a shadow copy.
  • A usable route, acknowledged update or visible table row therefore did not settle identity or delivery. Operators needed the original domain/range, mapping epoch, path, snapshot state and an observed payload result.

A duplicate that existed only in the table

RFC 1504 opens as a product-era routing manual preserved inside the RFC Series. Alan Oppenheimer of Apple Computer wrote it to document a protocol that might run over the Internet. It was Informational, not an Internet Standard. That status matters because the document is unusually detailed: eighty-two pages of tunnel framing, state transitions, remapping and recovery do not prove that any particular router implemented them.

The most revealing failure appears deep in the section on network-number conflicts. An exterior router can receive a range that seems to identify a newly reachable AppleTalk network. The range may pass ordinary local checks. Yet it can be the router's own earlier translation, returned through another path. RFC 1504 calls the apparent duplicate a shadow network.

The phrase is exact. Nothing in the physical world was cloned. What multiplied was a representation whose origin could no longer be reconstructed from the number alone.

Independent networks could reuse the same number

AppleTalk Phase 2 internets were often administered separately. Joining two organisations through a tunnel could expose the same network number on both sides. Rejecting either number would make local history dictate who could connect. Treating the collision as harmless would make forwarding ambiguous.

AURP supplied a two-layer answer. Across the tunnel, an exported network had a unique identifier, or UI. A router performing remapping derived that identity from a domain identifier, DI, plus the original network number or range. Inside the receiving internet, the exterior router assigned the UI a number from a reserved local remapping range.

That local number let old AppleTalk nodes operate without understanding a global namespace. To them, a remote network appeared to live at an ordinary network number. At the boundary, the router converted between the local presentation and the tunnel identity.

The distinction was architectural, not philosophical. The same local number could describe different remote identities at different routers or times. The same remote identity could receive different local numbers in different internets. Equality and inequality of the visible number were both insufficient to settle whether the underlying network was the same.

The mapping changed more than a label

RFC 1504 did not describe a transparent wrapper around untouched data. The router could rewrite the source network in a DDP header, an NBP entity address and network numbers carried in AURP routing data. If a DDP checksum was present, it first had to be verified and then set to zero after remapping. The old checksum no longer described the changed packet.

The router also could not search arbitrary third-party payloads for hidden AppleTalk numbers. A protocol might embed an address at a location the remapper did not understand. Its outer forwarding could succeed while its inner reference remained wrong. The tunnel could be up, AURP could have a route and an application could still fail because the translation boundary did not know the application's grammar.

Network management exposed the same split. A query sent across a tunnel could return original, unremapped numbers in its data. The management station had to join those numbers with the exterior router's remapping database to recover the local view. One screen showing an original number and another showing a local alias were not necessarily in conflict; they might be two views of one object.

RFC 1742 later standardized many AppleTalk management objects: ports, RTMP tables, routing counters and per-port observations. That vocabulary made execution more visible. It did not turn one counter or row into a universal identity receipt.

Static mappings spent space; dynamic mappings spent history

RFC 1504 allowed static and dynamic remapping. A static assignment made correlation predictable: a UI kept a known local number. Its cost was finite space. The reserved range might not accommodate every remote network that became reachable.

Dynamic mapping admitted more networks by assigning numbers as they appeared. Its cost was time. A number could later be reused, and a stale route, cached address or delayed packet might still carry the previous meaning.

The specification advised routers to exhaust other numbers before reuse and not immediately give a newly arrived network the UI of one that had just gone down. That advice is an early epoch rule. The number is not safe to recycle merely because the current table no longer shows its former occupant. Absence from one table is not proof that every old reference has disappeared.

This is where a mapping ledger becomes more valuable than a mapping value. The useful record is not “network 47 means remote network X.” It is “router R, on port P, during epoch E, mapped UI <DI, original range> to local range 47, and withdrew it at time T.” Without the epoch and boundary, later evidence cannot be joined safely.

The alias came home without a passport

The shadow-network sequence required a redundant path. Two AppleTalk internets were linked through a tunnel and also connected another way. A range remapped on entry could travel through the local internet, take the other path and return to the exterior router that had invented it.

At that point the range lacked the tunnel identity that would reveal its history. RFC 1504 says the router could not tell its own remapped range from an actual range. It therefore treated the route as a new network, assigned another mapping and exported it again. Multiple ranges now pointed to one physical network.

The process could repeat. Each circuit of the loop created another apparently distinct network until the apparent distance crossed AppleTalk's hop-count limit. A control intended to stop indefinite forwarding eventually bounded the multiplication, but only after the route table had learned false plurality.

The failure was not caused by translation alone. It was caused by translation combined with a path that escaped the assumed boundary and a return message that no longer carried enough provenance. The locally correct alias became globally ambiguous.

Mixed remapping made the safety property asymmetric

AURP treated a multipoint tunnel as one virtual data link and used split horizon: an exterior router did not send another exterior router's learned routes back across the same tunnel. That rule assumed the peers could communicate directly. A partially connected tunnel could be an intentional policy or a misconfiguration, and a router generally could not distinguish the two.

Remapping was configured per exterior router. RFC 1504 warned that enabling it on some peers but not others could create numbering conflicts. The deeper problem was asymmetric loop detection. Remapping routers performed the relevant checks; nonremapping routers did not. A loop between nonremapping routers could therefore return duplicated information to a remapping router, which then recorded shadow copies.

Redundant remapping routers had an even stricter consistency requirement. They needed the same DI for the local internet and the same mapping from remote UIs to local ranges. The document described manual configuration or a possible future exchange, then stated that AURP did not support that sharing function at the time. Redundancy existed in the physical design before the protocol had a transaction that made identity state redundant.

A suspicion still needed a returning witness

RFC 1504 did not treat a similar-looking route as conclusive proof of a loop. It proposed a loop-indicative test based on the size of a range and its zone list, followed by an investigation: send an AppleTalk packet out through the tunnel and observe whether it returns through a local port.

This is a disciplined evidence order. Matching attributes create a hypothesis. The path of a deliberately emitted packet supplies a stronger witness. Even then, the result belongs to the topology, configuration and time of the test. It does not establish which administrator intended the path or whether every service was affected.

The same restraint applies to security. RFC 1504 calls network hiding and device hiding weak forms of security and does not address general security. Hiding a route from ordinary presentation could reduce exposure, while network-management responses remained able to reveal information. Visibility policy was not authentication, and silence in the Chooser was not proof of nonexistence.

Snapshot, delta and delivery remained different records

AURP reduced periodic routing traffic by combining an initial exchange with update events. One-way connections carried connection IDs and packet sequence numbers. A sender waited for acknowledgement and retransmitted a routing-information response when the acknowledgement was missing.

That reliability did not make the routing view atomic. A new peer could connect while events were pending. Its initial response might describe one state and a later update might look incongruous with that state. RFC 1504 specified normalization rules: a distance change for an unknown network could be processed as an addition; an addition for a known network could become a distance change; down events for unknown networks could be ignored.

Those rules kept a receiver moving through uncertainty. They did not prove that every peer held the same table at the same instant. An RI-Ack proved receipt of one sequenced packet, not local RTMP propagation, remapping consistency or payload delivery.

Storage failure made the boundary visible. If a receiver's AURP table overflowed, missed network information was not guaranteed to arrive again as a delta. The receiver was advised to request the complete routing table. Once event history had a hole, recovery required a new snapshot, not confidence in the latest update.

The evidence chain a number could not carry

An operator investigating a suspected shadow needed several joined records:

  • the original identity <DI, original range> exported into the tunnel;
  • the local mapping, router, port and mapping epoch;
  • the peer connection ID, sequence number, snapshot or event type and receipt time;
  • the ingress path on which the returned range was observed;
  • the selected next hop and table version;
  • a probe or payload result tied to the intended service.

Two table rows with different numbers might collapse to one original identity. One number reused across epochs might refer to different originals. A route marked good might lead to a payload whose embedded address was never translated. Only the joins distinguish those cases.

That is the continuing value of this obsolete-looking story. The Internet repeatedly places local names, translated identifiers and compatibility aliases between a shared identity and old software. Such layers can be useful precisely because they conceal change. Their risk begins when the concealed change is later treated as enduring identity.

What the sources do not establish

The retained RFCs establish formats, requirements, warnings and management vocabularies. They do not establish how many AURP routers were deployed, whether a named product implemented every option, whether a real operator observed a shadow network, or whether any current network still uses the design.

RFC 1378 shows how PPP could negotiate AppleTalk and identify AURP routing-information carriage on a point-to-point link. Negotiation does not prove the AURP session ran correctly. RFC 1742 defines managed objects; it does not prove a device exposed a complete remapping database. RFC publication preserves a design; it does not certify running code.

Lu Heng's doctrine supplies the interpretive discipline: specification, local presentation, administrative choice and observed effect stay separate. Here that discipline is almost literal. The remapped number was real enough to route and too thin to remember what it was.

Sources