Summary

  • RFC 1475 proposed a 64-bit forward route identifier that was meaningful to the next router, opaque outside the router that issued it and normally replaced at every hop.
  • A zero or invalid identifier sent the router back to ordinary destination lookup; aggregation, route change, flow state and protocol conversion could all force a new interpretation.
  • Publication as an Experimental RFC, later participation in the CATNIP lineage and eventual Historic status describe documents and decisions, not an observed implementation or packet journey.

The attractive misreading

In June 1993, RFC 1475 presented TP/IX, also called Internet Protocol version 7. The proposal enlarged addresses, changed transport fields and tried to combine hop-by-hop datagram forwarding with faster path or flow mechanisms. One field made that ambition concrete: every datagram would contain a 64-bit forward route identifier.

The name invites an easy mistake. If a route identifier sits inside the packet, perhaps the packet knows its route. Perhaps a capture at one point reveals the path that was selected. Perhaps repeated values show that two packets followed the same road.

The procedure in the RFC denies all three shortcuts. The value did not describe a complete road. It was a handle created in one router's private routing state for use by the neighbour sending traffic to that router. Its meaning was local to the machine that would receive it next. The upstream system carried the handle without owning its interpretation.

This was not a defect hidden behind terminology. It was the mechanism.

Three routers, three meanings

RFC 1475 explains the design with routers A, B and C between hosts X and Y. C announces a route toward Y to B and includes an identifier internal to C. The text allows that identifier to be a table index or even an actual memory address. B uses C's value as an opaque object. B then creates its own route through C and announces a different identifier, internal to B, to A.

When X sends the first datagram, it has no route information and places zero in the field. A performs a normal destination lookup. It finds the route through B, writes B's private identifier into the datagram and forwards it. B receives a value it can interpret directly, finds the route through C, replaces the field with C's identifier and sends the packet on. C consumes its own identifier, clears the field and forwards to Y. Y recognises its destination address and ignores the route identifier.

The field name remains constant while its authority changes at every hop. At A's egress it is evidence about what B previously told A. At B's ingress it may be a usable key into B's state. At B's egress it has been overwritten with something belonging to C. At the destination it carries no necessary meaning at all.

A packet capture that records only the 64 bits cannot reconstruct those private tables. A log that calls the value “the route” erases the issuing router, the validity interval, the destination check and the rewrite that follows. The same numeric value could have unrelated meanings in two routers; two different values could advance datagrams along the same physical link. The bit string is real. The global interpretation is not.

Zero was a request for a decision

Zero did not mean “no route exists.” It meant that the current router had no usable borrowed identifier in the datagram and must use ordinary route discovery. A found the destination in its own table and seeded the next local hand-off.

Invalid identifiers had a similarly modest consequence. RFC 1475 expected routers to validate a received value, especially if it resembled a memory address, and probably to check that the referenced route described the datagram's destination. If validation failed, the router silently ignored the identifier and did what it would have done for zero.

That fallback separates performance from correctness. The identifier could accelerate a lookup, but the destination address and local routing table remained the recovery authority. A token hit was not enough. The router still controlled the admissible range, alignment, object type, destination consistency and current route state.

It also separates absence from failure. Zero can be normal at origination or conversion. A stale value can be rejected without declaring the destination unreachable. Only the later lookup and forwarding result can establish what the router did next.

Aggregation broke the illusion of a fixed path

Route aggregation made the scope boundary unavoidable. An incoming identifier might locate only an aggregate. At the router where component routes diverged, the machine still had to choose a specific route and place the corresponding downstream identifier in the datagram. The fast path ended exactly where its borrowed knowledge became too coarse.

Routing change imposed another decision. RFC 1475 said that if routes changed while datagrams were in flight, some router would have to decide how to “re-rail” each datagram. A packet-carried value therefore did not freeze a route. It arrived inside a moving system whose local tables could invalidate the assumption that created it.

This is the central historical lesson. The proposal put routing state closer to the packet without pretending that state had escaped routing. A field could preserve knowledge between consecutive routers. It could not turn a distributed sequence of changing decisions into one durable end-to-end fact.

A flow used the same boundary

TP/IX also allowed a flow identifier to replace a route identifier. Each router could hold a private flow object pointing to the route on which the flow was built. Datagrams might enter or leave the flow, and a host or nearby cooperating router could insert them.

Again, the field remained opaque to the sender and implicitly meaningful only to the next hop. The RFC left a router to distinguish its route IDs from flow IDs by a private method. The protocol did not need to expose that internal classification globally.

So the presence of a nonzero value would not, by itself, prove that a reserved flow existed. The observer would need the issuing router's state, the value type, its generation, the associated route, the time of use and the forwarding result. Even then, reservation, capacity and service outcome would require their own evidence.

The companion routing protocol supplied a time-bounded claim

RFC 1476 described RAP, the companion route-distribution proposal. Its Add Route command had to offer a route actually loaded in the sender's forwarding database at the time of announcement. The receiving peer would put the offered 64-bit identifier into datagrams sent back toward that peer.

That rule was stronger than a free-floating promise, but it was still time-bounded. “Loaded when offered” did not mean loaded forever. RAP therefore used the same identifier in Purge Route. A purge required the receiver to delete the route and revoke it from peers to which it had been propagated. The document preferred sending the purge before local deletion, yet admitted that the ordering could not be required.

Between deletion, purge transmission, propagation and an in-flight datagram, several clocks existed. The identifier could be perfectly authentic as a record of an earlier offer and useless for the current forwarding state. Evidence of the announcement, token, validation, purge and egress had to remain separate.

Conversion exposed custody boundaries

TP/IX aimed to let IPv4 and IPv7 systems be upgraded in arbitrary order. That ambition introduced conversion points. The proposal's “Don't Convert” option constrained routers performing IPv7-to-IPv4 conversion, but it also acknowledged a hard boundary: a protocol can specify bits on the wire, while a receiving host may convert internally as part of its own procedure.

The conversion section recorded more limits. Fragments that travelled by different paths and reached different conversion points could be lost. Neighbour capability might be inferred from receiving an IPv7 datagram, an echo exchange or explicit configuration. A hybrid system could possess an IPv7 address without being a native IPv7 implementation. IPv4-to-IPv7 conversion set the forward route identifier to zero.

That last reset matters. A converter did not manufacture continuity by copying an uninterpretable handle across architectures. It required the next routing domain to make a fresh decision. The address, version, identifier, converter action, fragments and subsequent delivery were different records.

The document's later history answers a different question

The RFC Editor record now marks RFC 1475 Historic. RFC 1752 later recorded that the TP/IX effort became CATNIP, judged CATNIP too incomplete for selection and recommended 128-bit SIPP as the basis for IPng. RFC 6814 formally obsoleted RFC 1475 while cleaning up deprecated IPv4 options.

Those facts close the documentary status line. They do not tell us that no one ever implemented a component, that every idea was technically worthless, or that a packet traversed a particular path. Conversely, the confident 1993 specification and its “Next Internet” title did not make deployment real. RFC 791 remained the IPv4 baseline; the later recommendation selected a different foundation.

RFC 1475 also said security issues were not discussed. Its validation suggestions cannot be promoted into authentication, authorization, integrity or protection against a hostile token. A local handle can be checked without becoming a security credential.

Sources