Summary

  • RFC 1482 proposed an aggregate registry whose fields distinguished a prefix's Home AS from every Announcing AS and from the Neighbor ASs meant to receive each announcement. A registration described intended policy; it was not a live observation of a route.
  • Its proxy-aggregation example allowed the backbone to synthesize a larger aggregate after hearing any one listed component. The resulting aggregate could reduce routing detail without proving that every destination inside it was reachable.

One prefix occupied several rows for a reason

The worked registry in RFC 1482 begins with a compact fact: an aggregate such as a /17 has a Home AS. In the example, AS 100 forms the aggregate and announces it to a stated set of neighbors. The same prefix then appears on additional rows for AS 690, AS 200 and AS 201, each with its own downstream audience.

Read carelessly, the repetition can look like redundant paperwork. Read as an operating model, it is the point. The Home AS identifies the provider that initially combines the component reachability. An Announcing AS identifies a provider expected to propagate that aggregate onward. The Neighbor AS list defines the intended audience of that particular propagation step. One prefix therefore produces several claims about several actors.

The table did not say that every observer received the aggregate directly from AS 100. It did not say that every listed transit had already sent it. It did not say that a neighbor had accepted, selected or installed the route. Contacts made the intended policy maintainable, but they did not turn the registry into a packet-level witness.

This distinction was already present in the older NSFNET Policy-Based Routing Database. The database associated a network with AS numbers from which the backbone expected announcements. For network 35, RFC 1482 showed primary, secondary and still more possible sources. That list was an input to acceptance policy. A received update, the path selected by a router and a working destination were later events.

Outbound policy was a projection for one neighbor

The other half of the old database concerned what the backbone would tell each neighboring midlevel network. An announcetoAS statement belonged to one neighbor. It could permit unrestricted announcements, switch to restrictive mode, explicitly include a network, exclude another, or suppress announcements to that neighbor altogether.

The result was not one universal view of the backbone's knowledge. Different peers could receive different projections because their agreements and technical needs differed. Midlevel networks submitted these policies to Merit, and the information was incorporated into ANSnet router configuration files.

That path from submission to behavior contained several conversions. An operator's statement became a database row. Tools turned rows into reports and configuration. A parser interpreted that configuration for routing software. The running process received, selected and exported protocol updates. The forwarding plane then sent—or discarded—packets.

Every conversion could succeed, lag, reject an input or preserve an obsolete value. RFC 1482 itself anticipated changes to database tools, report formats, client parsers and configuration-generation procedures. It also highlighted the move from rcp_routed concepts to GateD. A registry snapshot and a running router were related artifacts, not interchangeable copies.

Direct receipt and proxy synthesis produced the same visible prefix differently

RFC 1482 described two ways for an aggregate to enter the backbone. A CIDR-capable regional network could announce the aggregate directly. The policy database could then list the ASs from which that aggregate was expected, much as it had listed expected announcers for individual networks.

The harder case was a regional network that could not yet announce the aggregate. The backbone could aggregate on its behalf. In the illustrative GateD syntax, three component prefixes appeared in an OR-list. Hearing any one of them was enough to make the backbone store and propagate the larger aggregate as though that aggregate had been received.

The proposed syntax was not presented as settled production grammar. More importantly, its logical condition was deliberately weak: one component could trigger a statement about a larger address block. That was useful for reducing detail. It was not evidence that the other components were present.

Imagine three smaller routes beneath one /17. If the first remains visible while the second is withdrawn and the third was never correctly configured, the proxy rule can still cause the /17 to be announced. A remote table then contains the aggregate. From that fact alone, an investigator cannot infer which component activated it, whether the other components existed, or whether packets to their addresses would reach a destination.

RFC 1482 separately noted the possibility of holes: traffic for an uncovered part of an aggregate could cross an AS before being discarded. Route compression could therefore move the point of failure. It did not abolish failure or give the aggregate a universal delivery guarantee.

No de-aggregation meant that detail was not promised downstream

The initial NSFNET plan would not convert aggregates back into more-specific routes for outbound announcements. A peer that needed full routing information was expected to use a CIDR-capable protocol. A peer using a default route could still send traffic toward destinations covered by aggregates, but it would not receive a reconstructed inventory of every component.

This boundary matters when reading old routing evidence. A less-specific route at one observer does not prove that the exporting system knew nothing more specific. It may reflect a deliberate export contract. Conversely, a system's more detailed internal view does not prove that every downstream neighbor was entitled to receive it.

RFC 1338 and its successor RFC 1519 explain why allocation and routing aggregation had become urgent. They establish the architectural pressure to compress. They do not make every compressed advertisement a complete account of the component networks behind it.

The proposed aggregate registry recorded intention

RFC 1482 wanted aggregate information to be retrievable beyond the NSFNET community. Its proposed statement included the prefix, Home AS, Announcing AS, Neighbor AS list and contacts. Updates could arrive by electronic mail or an online registration tool.

Those mechanics made coordination possible. They did not define an authenticated publication chain, an observation timestamp for a live update, a withdrawal receipt, or reconciliation with a router's received routes, selected routes and forwarding entries. The document's security section said security issues were not discussed.

The bounded conclusion is not that the registry was unreliable. It is that it answered a different question. A row said what an identified participant intended to announce to identified neighbors. To prove the resulting behavior, an auditor would still need time-specific protocol and forwarding evidence.

Later documents help name those layers. RFC 1771 describes BGP-4 route attributes and AS paths, so an observer can distinguish an immediate peer from earlier ASs on a path. RFC 1786 describes a richer routing-policy registry language. Neither later RFC retroactively proves that every RFC 1482 row was submitted, installed or enacted.

Thirty-three percent was a planning number

The memo estimated that aggregation might remove 4,135 announcements from a base of 12,348—a reduction of 33 percent. It also called the calculation an optimistic estimate produced with a pessimistic algorithm and warned that the realized saving could differ.

That qualification is part of the evidence, not editorial modesty to be discarded. The arithmetic modeled possible table reduction under assumptions about which routes could be aggregated. It was not a before-and-after measurement from deployed routers. Nor did it settle the slower problems of routing-table growth and address-space exhaustion.

The RFC Editor record classifies RFC 1482 as Historic. The text said implementation was underway, while planning, discussion, debugging, stability, decision algorithms and the handling of holes still required work. “Underway” marks a project state. It does not identify which router loaded which generated file on which date.

The durable object is a chain of witnesses

For this episode, the right historical unit is not “the aggregate” as one indivisible fact. It is a chain: allocation and component prefixes; a Home AS's aggregation intent; each transit's onward-announcement intent; the neighbor-specific policy; the registry version; the generated configuration; the installed configuration; the update received from a peer; the route selected; the export decision; the forwarding entry; the packet outcome.

The chain explains why routing scale could improve while evidentiary demands increased. Aggregation made remote tables smaller by allowing a compact statement to stand for many possible destinations. The less detail the statement carried, the more an operator needed provenance at the boundaries where it was created, transformed and acted upon.

RFC 1482 captured that bargain unusually clearly. A prefix could have one home, several onward announcers and many intended audiences. A proxy could speak for a larger block after hearing only one component. A route could be present while a hole remained dark. The network became more scalable precisely because the visible announcement ceased to be the whole story.

Sources