Summary

  • RFC 1476 described a five-stage local procedure between an incoming route and its later fate: receiver filtering, metric and option processing, aggregation, active selection for the forwarding database, and peer-specific transmitter filtering.
  • Its option classes, source restrictions and policy tags let a route be used locally, stripped, withheld, discarded or exported differently without making any advertisement proof of forwarding, delivery or deployment.

The announcement entered a machine of choices

In RFC 1476, routing information did not fall directly into the forwarding table. It arrived from RAP peers, static configuration, interfaces and other protocols. The RAP process first built a database of candidates. From that database it selected active routes for the IP forwarding database. Only after that did it choose which active routes to advertise to each peer.

The document drew the architecture as a flow. Incoming routes encountered proximity filtering and aggregation. The resulting route database fed a set of selected active routes. Output filtering then produced the routes advertised. Static routes and routes learned from protocols such as RIP entered at different points. The diagram is historically useful because it denies one of the most persistent errors in network evidence: treating a message received on the control plane as proof of a state installed in the data plane.

RAP was published in June 1993 as Experimental, not as an Internet Standard. It proposed one open distance-vector protocol for scales ranging from isolated LANs to international carriers. The design avoided a fixed interior-versus-exterior boundary except where policy imposed one. It encouraged wide distribution of topology information and aggregation only when bandwidth, processing capacity or administrative policy required it.

This was an ambitious design claim. The RFC Editor record preserves its documentary status. Neither the ambition nor the record supplies a receipt from an operating router.

First decision: whether the offer survived reception

Receiver filtering asked whether an offered route was too distant or too specific. A router needing universal connectivity had to admit all finite routes and reduce them through aggregation, or depend on a default route to a router that did. A resource-limited router could tighten the filter dynamically.

The text also recorded an irreversible edge. If an operator later opened the filter, routes discarded earlier might never become available because the peers that had announced them were under no obligation to repeat them. A wider aperture did not reconstruct an absent message.

That distinction matters beyond RAP. Configuration state can say a route would now be accepted. It cannot prove the route is present. To establish that, an observer needs the later offer, a retained pre-filter record or a refresh mechanism. The policy revision and the candidate route are separate evidence objects.

Second decision: what attributes changed the route

After reception, RAP updated the route's metrics and options. Distance increased. Delay and cost accumulated. MTU and bandwidth took the minimum along the path. Known policy options could cause rejection. Unknown options invoked a compact but consequential class rule.

Except for distance in the RAP header, an implementation was not required to understand any particular metric or option. Each option carried a class telling an unknowing implementation what to do. Class 0 meant use and propagate the route while preserving the option unchanged. Class 1 meant use and propagate but omit the option. Class 2 meant use locally but do not propagate. Class 3 meant discard the route.

These were not trust bits. They did not authenticate the sender, validate the value or prove that the instruction was safe. Class and option type were independent; two implementations could attach different classes to the same type. The format field could make an unknown value printable for troubleshooting without making its meaning understood. RFC 1476 even warned that class 1 offered no confidentiality: an implementation could replace the type with a null option and forward the rest.

This mechanism differs from IPv6's later unknown-option action bits and from BGP's opaque optional-transitive attributes. The useful historical point here is the position of the rule inside RAP's larger decision chain. An unrecognised attribute could change whether the route remained local, crossed a peer boundary or disappeared entirely.

Three policy claims that did not mean the same thing

RFC 1476's attribute catalogue makes the distinction concrete. A Source Restriction option described which packet sources were allowed to use a route. The specification said forwarding-layer security filters had to be represented in route information; otherwise traffic might select an apparently better route and be silently discarded at the filter.

The cure carried its own exposure. Propagating the restriction could reveal confidential information about the security configuration. The document relied on careful propagation toward the network authorized to use the route. It specified the intended boundary; it did not prove that every implementation or topology preserved it.

The AUP option did something else. It could mark a route as usable only under an organization's acceptable-use policy, for example to avoid carrying commercial traffic across a restricted network. The RFC explicitly said this was cooperative information, not a security barrier like a forwarding filter.

The Public option marked a route that crossed a broadcast medium where receivers other than the destination might read the traffic. Its purpose was to stop attractive bandwidth from being mistaken for private carriage. Source authorization, cooperative use policy and exposure to listeners were three separate claims. Combining them into a generic “policy attribute” would lose the decision each one was meant to inform.

Third decision: whether detail could be aggregated

RAP next considered aggregation. Routes through the same peer could sometimes be subsumed under a containing route, but the RFC rejected automatic aggregation in every possible case. More detail could improve the effectiveness of the companion forward-route identifier. Policy attributes might prohibit aggregation or cause a route to be discarded rather than summarized.

Aggregation therefore changed the evidence surface. A downstream peer receiving a broad route could not assume that every more-specific contributor had the same attributes, or even that the contributors remained individually visible. Conversely, the presence of a more-specific candidate in the local database did not prove it crossed the next boundary.

RFC 1338 supplies the contemporary address-aggregation pressure. RFC 1476 added its own policy-aware choice. That does not make RAP a deployed form of later inter-domain routing, and it does not make every summary semantically neutral.

Fourth decision: whether the route became active

After aggregation, the router combined the remaining candidates with routes learned through other mechanisms such as RIP. It then selected which routes would enter the IP forwarding database and actually be eligible to forward datagrams. Local policy could use any combination of attributes and options.

This is the decisive boundary between a route database and an active forwarding state. A RAP process could retain several candidates yet install one. It could prefer an unrestricted route while keeping a restricted alternative. It could reject a route whose cost, medium, source condition or administrative tag conflicted with local policy.

RFC 1058 and RFC 1247 were period reference points for distance-vector and link-state routing. RFC 1476's authors proposed interaction with such routes without making receipt from any protocol equivalent to selection. A control-plane database snapshot still would not prove that a packet matched the installed entry, left an interface or reached its destination.

Fifth decision: who was allowed to hear it next

Transmitter filtering came after active selection. RAP could advertise only a subset of active routes, and it could choose a different subset for every peer. Arbitrary local policy controlled those decisions.

The ordering is important. A route could be active for local forwarding yet deliberately absent from one peer's view. Another route could be exported with an attribute removed. A third could be withheld because an unknown class prohibited propagation. The externally visible routing surface was a projection of active local state, not a mirror of it.

The transmitter also had to represent packet filters in the offered route so that peers would not send traffic into a black hole. That was a normative obligation. Evidence that an advertisement existed would not prove the representation was complete, the downstream selection was correct or a packet escaped the filter.

A live TCP connection was not a live routing process

RAP's transport machinery contained the same caution at another layer. Peers used one symmetric TCP connection on port 38 and exchanged route commands in both directions without acknowledging each command. An application-layer Poll and No Operation exchange reset per-peer timers.

RFC 1476 discouraged relying only on TCP keepalive because it showed merely that remote TCP accepted data, not that the remote RAP process was alive. If the connection broke, each side was to purge all routes learned from the peer. The wire, the TCP endpoint, the RAP process, the route database and the forwarding state were again separate.

Loop recovery was bounded too. RAP used distance limits and optional trace attributes, and described its last-resort loop breaking as eventual rather than rapid. A continually recurring error could regenerate the loop. “Self-healing” was not a convergence-time measurement.

What this experimental design can establish

The companion RFC 1475 and its RFC Editor record describe the TP/IX setting and forward route identifier. A previous commission owns that identifier's hop-private meaning and RAP Add/Purge timing. The present evidence is different: RFC 1476 specified a sequence of authority surfaces through which an offer could change state and visibility.

RFC 2026 helps read the standards label without turning it into operational proof. The proposal deserves attention because it made the gaps explicit, not because publication settled them.

That is the connection to Heng Lu's essays on running-code primacy, minimum initial specification and localized future decision, and reality layers. A route announcement can trigger local consideration. It cannot borrow the authority of the later filter, selector, forwarding table, peer export or observed application result.

Sources