Summary

  • When a business cannot reach an online service, its staff need to know which network to ask for help. An AS number can point toward a routing-policy boundary, but it cannot identify every carrier or explain the outage.
  • RFC 1930 clarified in 1996 what that number can show: the boundary of a routing policy, building on RIPE’s 1994 application form.

Analysis

Imagine a business whose customers suddenly cannot reach its service. Its staff need to know which provider can investigate, while each network along the path sees only part of how traffic was routed. An AS number can help locate a policy boundary in the route record, but it cannot by itself name every carrier or explain the interruption. That gap between a useful clue and a complete answer is why the number’s meaning matters. In March 1996, RFC 1930 made the distinction explicit: an autonomous system is a group of IP prefixes operated under one clearly defined routing policy.

Other networks need its number when they must distinguish that policy.

The difference becomes practical when a customer has one provider. If its routes follow that provider’s policy, RFC 1930 says a separate AS is generally unnecessary: the prefixes can sit within the provider’s AS. With two providers, the network may need to announce different prefixes or express different route preferences to each. In BGP, those choices become visible in the announcements the network sends and the routes each neighbor accepts or prefers. The point is not the number of cables or routers; it is whether the network needs a distinct policy at that boundary.

The paperwork had begun to make that distinction visible. RIPE-109, dated 1 March 1994, divided an AS request into administrative and technical parts. The administrative section was mandatory; the applicant could initially leave technical details incomplete, though RIPE urged them to be supplied later. The form included an AS object with as-in and as-out expressions, a way to describe which routes an operator accepted from or announced to peers. RFC 1930 explicitly says its broader guidance was based on that RIPE document. A regional form became the foundation for an IETF best practice with wider scope.

The 1996 document was correcting a category error as well as describing a protocol identifier. Earlier definitions tied an AS to one technical administration and a common interior protocol. RFC 1930 observed that operators could use several interior protocols and metrics while still presenting one coherent routing plan externally. Conversely, one company could contain distinct routing policies. The boundary was the policy other networks saw, not a corporate org chart or a count of machines.

That distinction mattered because numbers were finite. RFC 1930 described the space as 16-bit and reported about 5,100 numbers allocated, with fewer than 600 actively routed at the time. Those are the authors’ 1996 figures, not a present-day measure. The document discouraged creating an AS merely because it was part of an application process and reserved 64512–65535 for private use. A decade later, RFC 4893 introduced a gradual BGP transition to four-octet AS numbers, using capability signalling and compatibility attributes for older speakers. RFC 6793 later replaced that specification.

The history is not a simple story of a number shortage. It is a story about what the number was supposed to represent. An ASN can identify a routing-policy boundary in public records and route paths; on its own, it cannot prove who operates every router, whether a route is accepted, or where customers receive service. The application form, the routing protocol and observed network behavior are different records. Treating them as interchangeable turns a useful identifier into a claim it cannot support.

Sources