Summary

  • RFC 1104 described three policy-routing models: distributing routing information, filtering or forwarding individual packets, and dynamically allocating resources such as bandwidth and buffers. It discussed accounting as a related but separate historical record.
  • A route made available to a network did not prove that a particular packet passed a filter. A packet admitted at one router did not prove its end-to-end path. Neither act proved that capacity had been reserved or that a later account was accurate.
  • Reliable evidence therefore required four trails: reachability state, packet disposition, resource allocation and usage history. Collapsing them into one “policy applied” result moved authority to the wrong controller.

One phrase covered three different machines

RFC 1104, written by H-W. Braun of Merit/NSFNET and dated June 1989, did not announce a finished architecture. Its purpose was to outline models and provoke discussion about a scalable form of policy routing. The current RFC Editor record labels the document Unknown; the IETF Datatracker places it in the Legacy stream and gives it no formal standing in the IETF standards process.

The memo's useful move was taxonomic. It separated policy based on the distribution of routing information from policy applied to packet filtering and forwarding, then separated both from the dynamic allocation of network resources. Later it put accounting beside those mechanisms without pretending that accounting performed the same control.

All four surfaces could be described with the same sentence: “the network enforced policy.” The sentence concealed more than it revealed. Did a routing database withhold a destination? Did a router discard one datagram? Did an allocator favor one queue? Did a counter append a usage event? An operator who retained only the sentence could no longer tell which machine had acted.

Reachability policy changed the set of possible routes

The first model worked by controlling routing information. A network or Administrative Domain could limit what reachability it accepted, used or propagated. The effect was macroscopic: entire networks or domains might become available or unavailable in the routing view.

RFC 1104 used the NSFNET interface as a historical example. It described controls over a peer's source address, its domain or AS identity, the network numbers it advertised and the metrics admitted through a policy database. Those four checks are already supporting evidence in Sofia Ren's published history of RFC 1074; they are not the discovery or thesis here.

What matters in RFC 1104 is the boundary that follows the example. Distribution policy operates on network-scale reachability. It does not identify the person using an end system. It does not describe a decision on every packet. The memo explicitly says this model cannot stop malicious traffic introduced through source routing merely by controlling the ordinary routing information.

A missing route can make delivery impossible from one routing view. It cannot prove why a later packet disappeared. An available route can create a forwarding possibility. It cannot prove that a packet was accepted, that the selected path was used or that the destination received anything. Reachability is a control surface and an evidence object, not a packet receipt.

The packet gate began where the route map stopped

The second model inspected individual packets. Its unit was microscopic enough to reach hosts or users rather than only networks and domains. A router could compare packet fields and current policy, then forward or reject that datagram.

That precision came with a cost. RFC 1104 warned that tight checking could burden router performance and require very large policy databases whose copies remained consistent. A detailed rule at the boundary was useful only if the machine could retrieve it in time and the rule meant the same thing at every relevant observation point.

Packet filtering still did not distribute routing information. Passing one gate did not synthesize the end-to-end route described in RFC 1102, where a policy route was a sequence of administrative regions made progressively concrete by policy gateways. Nor did one local accept decision prove that the next router accepted the packet, that the return path existed or that an application consumed the payload.

The required record was correspondingly narrow: which packet representation, at which device, under which policy version, matched which rule and received which local disposition. Promoting that event to “the policy route worked” would borrow evidence the filter never observed.

Capacity was a third grant, with a different loser

RFC 1104's third model concerned resources: bandwidth, buffers, circuits and queue treatment. The memo called this model basically orthogonal to distributing routing information, though it expected interactions between them.

Orthogonal did not mean independent in practice. A route could exist while the traffic assigned to it received no special capacity. A packet could pass a filter and still wait behind another queue. Conversely, an allocator could reserve or prefer resources for a class whose end-to-end reachability later failed. The state “allowed to go” and the state “given enough to go” belonged to different controllers.

Allocation also created an explicit rival. Extra bandwidth, buffers or priority given to one flow could reduce what remained for another. RFC 1104 therefore raised technical and political questions about sharing resources across domains. It did not resolve those questions or prove that a named reservation took place.

The memo also recognized a choice between enforcing scarcity and reducing it. A network could spend processing, database and governance effort deciding who received a constrained resource, or invest in making the resource less constrained. Enforcement itself consumed capacity and attention. The efficient policy could not be inferred from the fact that a rule was technically expressible.

The account came afterward and could not rewrite the act

Accounting occupied a fourth surface. RFC 1104 described it as separate from policy-based routing, though closely related. An account combined history with policy: traffic volume, route or other usage could be collected at domain, network, host or user levels and later influence a decision.

History was not permission. A counter did not advertise a network, admit a packet or reserve a buffer. It reported what its measurement system believed had occurred according to a defined unit and observation point. Collection at one domain could also fail to describe an end-to-end service assembled across several domains.

The follow-on RFC 1125 made the charging dimensions more explicit. A policy could specify the unit, measurement basis, amount, who should pay, whose count controlled and what bounds applied. Those were separable fields. Its sample policies were examples, not official rules, but the structure exposed the attribution problem: even a correct counter did not identify the liable party unless another policy authorized that association.

The evidence ladder therefore continued beyond measurement. First a policy text existed. Then a controller held current state. A route, packet or resource decision occurred. A defined observer recorded usage. Finally, a separate institution might attribute the record and impose a charge or sanction. No earlier step issued authority to the next.

“Policy applied” was an archival failure

RFC 1104's historical importance lies less in choosing one model than in refusing to merge them. Route distribution altered the map. Packet filtering operated a local gate. Resource allocation changed the share of a scarce facility. Accounting preserved a historical claim. Interaction among them did not erase their different inputs, outputs and failure modes.

The phrase “policy applied” destroys precisely the information needed for review. If reachability and packet disposition are one field, investigators cannot tell whether the packet lacked a route or met a filter. If packet admission and resource allocation are one field, delay looks like denial or permission looks like service. If allocation and accounting are one field, a planned reservation can become an invoice without proof of use.

The durable object is not a verdict but a chain of bounded records: the policy version, controller, time, scope, route state, local packet action, resource grant, measurement unit and later institutional decision. The chain can show how one surface influenced another. It must never let one surface testify in place of another.

Sources