Summary
- RFC 1136 separated an Administrative Domain—the scope of a common technical plan and a defined level of trust—from a Routing Domain, whose members used one common routing procedure.
- The paper allowed several Routing Domains inside one Administrative Domain but forbade a Routing Domain from spanning multiple Administrative Domains. It treated the distinction as an engineering discipline, not a deed of ownership or proof of a packet’s path.
A map that was doing too many jobs
Early Internet language made an autonomous system carry a great deal of weight. It was a way to say that gateways belonged together for exterior routing while their interior algorithm could remain private. In RFC 827, Eric Rosen could still describe a core of DARPA gateways and attached systems, then anticipate a future of co-equal systems in which no one system should be called the core.
That future did not merely add more boxes to the old drawing. It made one word begin to stand for several different things at once. An AS might name the scope of an interior routing protocol. It might be the unit seen by a backbone. It might mark the people who had to coordinate an external connection. It might be read, far too readily, as a company, a territory, a hierarchy or a settled account of authority.
RFC 1136, written by Susan Hares and Dave Katz in December 1989, did not try to turn that ambiguity into a law. It was an Informational RFC, explicitly not an Internet standard. Its contribution was humbler and more useful: a model borrowed from the OSI Routeing Framework that gave separate names to separate operating surfaces.
The result is easy to mistake for an old taxonomy. It was also a diagnosis of where a growing network could fail. A label that conceals whether participants share a route computation, a technical plan, a trust assumption or a policy agreement leaves operators unable to see what must be coordinated before a new connection changes the system.
Administration was an operating condition
RFC 1136 called an Administrative Domain, or AD, a collection of end systems, intermediate systems and subnetworks operated by a single organization or administrative authority. The document immediately qualified the claim. Components inside the AD were assumed to interoperate with a significant degree of mutual trust; other ADs were treated with greater suspicion. Routing inside the AD rested on a consistent technical plan.
This is not a theory of corporate identity. The RFC did not say that every device with one logo shared an AD, or that an AD was a property right. It gave engineers a working presumption: if an operator presents a collection as one routing-administration boundary, there must be a coherent enough plan for that presentation to be safe.
Seen from outside, the AD could be a cohesive entity whose inner structure did not matter to routing. That concealment was functional. A neighbour did not need a complete internal map in order to exchange reachability information. But it was not a declaration that the internal map had disappeared, that the neighbour had acquired a right to direct it, or that one exterior number exhausted the identities inside.
The paper was especially careful about hierarchy. Administrative Domains could be arranged loosely according to the availability and authoritativeness of routing information. That arrangement did not imply administrative containment, and it did not imply a strict tree. A path through a hierarchy of routing information was not automatically a chain of command. This small sentence remains a useful brake on diagrammatic overreach.
A routing domain was a common calculation
The other term was narrower. A Routing Domain, or RD, was a set of systems using the same routing procedures: the same metrics, compatible ways of measuring them, the same information-distribution protocol and the same path-computation algorithm. RFC 1136 likened its intra-RD protocol to an Internet IGP.
That definition placed the boundary in executable behavior. A routing domain existed because routers and end systems could participate in one compatible way of forming routing knowledge. In the model, systems inside an RD could determine whether an end system within the domain was reachable and, if so, derive a path to it.
This did not mean that every successful lookup or every installed route proved membership, trustworthiness or authority. It described what the shared procedure was intended to make possible within a deliberately bounded set. The distinction matters because a shared algorithm is a coordination resource, not a blank cheque. It says something about how a group computes routes. It does not settle why the group may make every other decision attributed to it.
Subdomains made the point sharper. An RD could be divided so that one subdomain’s topological detail was largely hidden from another. The reduction in distributed routing information was a scaling choice. Less information crossed the internal boundary because the design limited what needed to cross; it was not evidence that the hidden topology had ceased to exist or that an outside reader could infer its governance from the summary.
The asymmetry the model would not hide
RFC 1136 permitted an AD to contain several RDs. It did not permit the reverse: a Routing Domain could not span more than one Administrative Domain. A classic, congruent case—one AD and one RD—was analogous to the paper’s view of an autonomous system. But congruence was a special case, not a reason to collapse the categories everywhere.
The rule was an attempt to make responsibility legible. Several routing procedures might operate within one coordinated administration. Their interaction could range from tightly coupled best-path routing, even across different routing protocols, to more policy-based exchange. What made the larger AD coherent was not sameness of every internal mechanism. It was tight coordination under a unified technical plan.
Cross the AD boundary and the premise changed. Inter-administrative routing concerned structured information flow between organizations that might require formal multilateral agreements. Legal, political, security and access-control concerns could matter. Such agreements, the RFC warned, were unlikely to be implicitly transitive. If A had agreed to exchange some information with B, and B with C, that did not silently create the same agreement between A and C.
This is the paper’s most durable institutional insight. Technical connectivity does not fill in the missing terms of a relationship. A router can learn a route, a network can carry a packet, and two organizations can exchange some information without any of those facts making every policy, duty or permission flow through the resulting graph. Coordination has to be stated where it is used.
When a number became a shorthand
The paper mapped its model onto the Internet of its moment. It saw national backbones as analogous to Common Domains and regional networks as clear AD candidates. It observed that an AS number had become an abstraction for policy groupings visible to backbones and suggested that the then 16-bit AS number could instead be viewed as an Administrative Domain number.
This was a warning against a false homogeneity test. A regional network might appear externally as one AS while containing several Routing Domains. The exterior number could be useful for policy representation without proving that every internal component ran one IGP, shared an identical topology or belonged to one nontechnical administration.
The RFC did not make the shortcut harmless. It said that structures containing multiple nontechnical administrations still needed a single approach to internal routing; in the absence of one encompassing administration, a technical committee might have to settle common issues. The paper was identifying work that a number could not perform by itself.
That distinction speaks directly to any later temptation to treat an identifier as self-executing authority. A number can make a coordination surface addressable. A route can make a claimed destination available for selection. Neither gives an observer the whole evidence of internal agreement, ownership, consent or operational competence. Those are separate propositions with separate records.
A campus link and the cost of an unstated change
RFC 1136 offered a concrete transition: a network inside an NSFNET regional network adds a connection to ESNET. Administrators of the network and the regional had to coordinate the change, perhaps altering policy and routing boundaries. Without coordination, the paper said, routing loops and policy violations could result.
The force of the example is not that a new link is inherently improper. It is that a link changes more than reachability. It can change who is prepared to carry traffic, which information is trusted, how a route is computed and which policy boundary an announcement crosses. A topology drawing that shows the cable but none of those conditions is incomplete.
The model then imposed its sternest test. If a campus wanted to set and enforce its own routing policy through its routers, it had elected to become a separate AD. If it continued to use one common IGP with other campuses, it would be trying to split a single RD across several ADs—an arrangement RFC 1136 called dubious engineering and disallowed in the model.
The claim is historical and conditional, not a present prescription. It does show an important reasoning habit: when control and policy are separated, technical membership must be reconsidered. One cannot keep the benefits of one common computation while silently treating every participant as independently authoritative over its part of that computation.
The boundary was a discipline, not a sovereign line
RFC 1136 did not win the future as a compulsory architecture. It should not be retrofitted into a claim that every current network conforms to its terms. Its value is diagnostic. It separated a common route calculation from a coordinated administration and both from the looser, negotiated relations between administrations.
That separation is also a limit on rhetoric. An AS number is not a title deed. A routing adjacency is not a mandate. A route seen from outside is not the whole internal topology. A shared IGP is not proof that every member has conferred unlimited authority on every other member. A hierarchy of information availability is not a hierarchy of ownership.
The Internet grew because it could expose enough information at a boundary without forcing every participant into one internal design. RFC 1136 added a companion rule: hiding detail is safe only when the remaining coordination responsibilities are named. The boundary did not eliminate responsibility. It identified where responsibility had to be made explicit.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

