Summary

  • RFC 1403 defined a 32-bit OSPF external-route tag whose Automatic, Completeness and PathLength fields described the condition of path evidence, not the full path itself.
  • A manually assigned tag carried opaque local information. Even an automatic tag could represent only path-length classes. Truncated or longer exterior paths therefore could not safely be reconstructed from OSPF.
  • The specification converted that information loss into authority limits: some routes must never be re-exported into BGP, while full path information had to travel separately between border routers.

The smallest field carried the most important refusal

The scene was an Autonomous System border in the early 1990s. Outside, BGP described reachability together with an inter-domain path. Inside, OSPF calculated routes using a different model. A router speaking both protocols could import a claim from one side and later encounter another border router trying to send that claim back out.

That sounds like translation. It was also a problem of memory. If the internal representation had discarded part of the exterior path, what authority did the receiving border router have to manufacture a new BGP advertisement?

RFC 1403 answered with an unusually compact grammar. The OSPF external-route tag was thirty-two bits. When generated automatically, one bit marked that fact, another described whether source information was complete, and two bits classified path length as zero, one, greater than one or reserved. Twelve bits remained available for an arbitrary tag, and sixteen held an autonomous-system number.

It was a summary about evidence. It was not a miniature AS_PATH.

That distinction becomes clearest in the cases the field could not represent. An arbitrary path longer than one AS would not fit. The tag could preserve the fact that such a path existed and whether its information was complete, but not the sequence itself. RFC 1403 did not treat the resulting blank as permission to infer. It used the blank to stop export.

The tag first had to identify its own provenance

The high Automatic bit separated two objects that happened to occupy the same field. If the bit was zero, the other thirty-one bits were locally configured information. The document said nothing should be inferred about the route’s characteristics from them. That setting remained the default for compatibility with deployed OSPF implementations.

If the bit was one, the remaining subfields acquired the defined completeness and path-length meanings. The record therefore contained a primitive form of provenance: before reading the claim, a router had to know whether the claim had been generated under the shared grammar.

This did not authenticate the router or protect the tag from alteration. RFC 1403 explicitly left security undiscussed. “Automatic” established how to interpret the bits; it did not establish who could be trusted. A syntactically valid tag could still be attached to bad input or produced by faulty configuration.

But the interpretive rule was consequential. The same integer was not allowed to become structured evidence merely because its bit pattern looked familiar. Meaning depended on the process that created it.

Complete, incomplete and too large are different states

The Completeness bit did not say whether a destination was reachable. It described the status of path information carried into OSPF. The two PathLength bits did not count every AS. They divided the source knowledge into coarse classes.

For short cases, that could be enough to build a bounded path. A route imported from an internal protocol could be represented as local. A route carrying one neighbouring AS could be exported with a path comprising the local AS and that neighbour, subject to the specification’s filters and origin mapping.

Longer cases broke the compression.

When path information had already been truncated, the automatic tag used the incomplete/longer-path state. Another border router was forbidden to re-export that route into BGP. The tag honestly reported that it lacked the evidence required to reproduce the exterior history.

When a complete longer BGP path had been imported into OSPF, the prohibition remained, for a different reason. OSPF was only the reachability projection; the full path was expected to travel through BGP between border routers inside the AS. A router seeing the OSPF route had to wait for the internal BGP update before advertising externally. RFC 1403 called this longer complete case “out of band”: another protocol carried what the tag could not.

The two refusals should not be merged. In one, the history was lost. In the other, the history still existed elsewhere. Both blocked reconstruction from the small projection, but only the second offered a parallel authoritative record to wait for.

Import was not export permission

RFC 1403 surrounded the tag with conservative defaults. No OSPF route was to be exported into BGP by default. External OSPF routes required explicit configuration. In the other direction, administrators had to select which BGP routes entered OSPF. A border router could not originate a default route internally unless configured to do so.

These rules separated three acts that are easy to collapse in an operations console: learning a route, projecting it into another domain, and authorizing it to leave that domain. The fact that a destination appeared in OSPF established neither the provenance needed by BGP nor permission to advertise it.

Metric translation showed the same caution. OSPF cost and BGP’s inter-AS metric had different widths and meanings. The corrected document did not prescribe a grand conversion. The optional BGP metric was absent by default. A number from one decision system could not acquire the semantics of another through arithmetic alone.

Identity helped correlate the full record

The specification required a BGP identifier and OSPF router ID to match while the router was up. This was more than cosmetic convenience. If two border routers imported reachability to the same external network, a third router needed to determine which one its OSPF route actually used, then associate that forwarding choice with the corresponding exterior path.

The later RFC 1745 adapted the model for BGP-4 and IDRP. It added variable-length reachability, path sets and newer attributes. With equal-cost exits, the advertising router could need to merge multiple paths into a set. Yet the small-tag boundary survived: a truncated path must never be re-exported, and a complete longer path still had to arrive through the exterior protocol before a new exterior advertisement.

Modernisation changed the records that needed correlation. It did not make the lossy summary reversible.

A next hop was still not an outcome

RFC 1403 also mapped OSPF’s Forwarding Address and BGP’s NEXT_HOP so packets on a shared network could avoid an unnecessary router hop. That rule could establish how an advertisement directed forwarding. It could not establish that the remote destination answered, that an application worked or that a user obtained a result.

The evidence ladder is longer: source route, import action, tag provenance, completeness state, explicit export policy, full-path receipt, exterior advertisement, forwarding observation, remote reachability, application outcome. Each record can be accurate while the next event fails.

The RFCs themselves report protocol requirements, not a measured deployment. Both RFC 1403 and RFC 1745 are now Historic, and neither supplies security analysis. Their durable contribution is narrower than a current configuration recipe. They demonstrate that a projection’s admission of incompleteness matters only if the system removes powers that require the missing detail.

Sources

These sources establish document status, specified field semantics and protocol requirements. They do not establish present implementation behavior, adoption, an incident, authenticity, forwarding success or a user outcome.