Understanding AS0 and its Role in Internet Routing

Original Purpose of AS0

Autonomous System 0 (AS0) is a special autonomous system number (ASN) listed as reserved in the IANA ASN registry. It is not assigned to any Regional Internet Registry (RIR) or network operator and, as stated in the IANA registry, may be used to identify non-routed networks. RIRs recognize AS0 as a mechanism to invalidate unallocated address space, in accordance with RFC 6483. It is used to signal IPv4 and IPv6 address ranges that have not been delegated and therefore should not be routed. In summary, the original purpose of AS0 was to serve as a placeholder ASN indicating that a route has no valid autonomous system behind it, thereby ensuring such routes are excluded from normal Internet routing.

AS0 in the Context of BGP

In the Border Gateway Protocol (BGP), which is the Internet’s core routing protocol, Autonomous System 0 (AS0) is a reserved value and not a legitimate ASN for any network. An update to BGP standards by the IETF, outlined in RFC 7607, proscribes strict rules for how BGP implementations must handle AS0.

The RFC states:

“A BGP speaker MUST NOT originate or propagate a route with an AS number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or AS4_AGGREGATOR attributes.

An UPDATE message that contains the AS number of zero in the AS_PATH or AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in [RFC7606].

An UPDATE message that contains the AS number of zero in the AS4_PATH or AS4_AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in [RFC6793].

If a BGP speaker receives zero as the peer AS in an OPEN message, it MUST abort the connection and send a NOTIFICATION with Error Code “OPEN Message Error” and subcode “Bad Peer AS” (see Section 6 of [RFC4271]). A router MUST NOT initiate a connection claiming to be AS 0.”

These rules are designed to protect the integrity of global Internet routing. Because AS0 is not assigned to any real network, any route or session referencing it is inherently invalid. Allowing AS0 to appear in routing messages could lead to misconfigurations or even security vulnerabilities, such as route hijacking involving non-existent ASNs.

By enforcing these rules, BGP implementations ensure that AS0 serves as a clear signal: this route or session is invalid and must be ignored. This helps maintain the stability, security, and reliability of the Internet’s routing infrastructure.

AS0 and RPKI (Resource Public Key Infrastructure)

AS0 enables a resource holder to indicate that a prefix—and more specific ones —should not be routed by publishing a ROA listing AS0 as the sole authorized origin. In this context, AS0 is used in a special type of ROA known as an AS0 ROA. In other words, AS 0 ROA serves as a signed attestation that no AS is authorized to originate a route for a given prefix.

As described in RFC 6483:

“An AS 0 ROA has a lower relative preference than any other ROA that has a routable AS as its subject. This allows a prefix holder to use an AS 0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered “invalid”, while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes”.

This mechanism provides a cryptographic method for resource holders—including RIRs and IP address custodians—to explicitly mark prefixes as unreachable via BGP.

When a network operator performs Route Origin Validation (ROV), any route announcement for a prefix covered by an AS0 ROA will be classified as Invalid, because the only authorized ASN is 0—a value that is forbidden in BGP routing, per RFC 7607:

“By allowing a Resource Public Key Infrastructure (RPKI) resource holder to issue a ROA saying that AS 0 is the only valid origin for a route, we allow them to state that a particular address resource is not in use. By ensuring that all implementations that see AS 0 in a route ignore that route, we prevent a malicious party from announcing routes containing AS 0 in an attempt to hijack those resources.

In effect, AS0 ROAs act as cryptographically verifiable “do not route” signals. When properly validated and enforced, they help eliminate propagation of bogus or unauthorized routes, improving the overall security and hygiene of the global routing system.

Trust Anchor Locators (TALs) and AS0 ROAs

To facilitate the validation of ROAs, including AS0 ROAs, network operators rely on Trust Anchor Locators (TALs). A TAL is a file that contains the location of an RPKI repository and the public key of the trust anchor, enabling validators to retrieve and verify RPKI data.

As the RIRs assign the IP prefixes and AS numbers to the organizations, they also act as a trusted authority for RPKI and initially there were five TALs, each for one RIR. However, during the AS0 ROA implementation for unallocated resources, some RIRs, such as APNIC and LACNIC, published AS0 ROAs under separate TALs, distinct from their main RPKI TALs. This separation allows operators to opt-in to AS0 validation by explicitly adding these TALs to their RPKI validators.

For instance, APNIC’s AS0 ROAs are published under a dedicated TAL, and operators must manually include this TAL in their validators to process these ROAs. This approach provides flexibility, enabling operators to choose whether to enforce AS0-based route filtering.

Effect of AS0 on Route Announcements and Filtering

The use of AS0 thus creates a safety net in routing announcements. If someone attempts to announce a prefix that has no business being advertised (for example, address space not allocated to them or to anyone), and that prefix is covered by an AS0 ROA, networks doing RPKI validation will reject that BGP announcement as invalid. In practical terms, AS0 helps network operators filter out bogons – routes to IP blocks that shouldn’t be in the global table (addresses or prefixes not yet allocated by IANA or the Regional Internet Registries as well as all addresses reserved for private or special use by RFCs.). On the BGP protocol side, the enforcement is straightforward: any route containing AS0 is considered corrupt and is dropped. On the RPKI side, the presence of an AS0 ROA for a prefix means no legitimate origin exists, so any AS that claims to originate it will fail validation. The net effect is a tighter filtering of illegitimate routes: AS0 acts as a “negative route announcement”, explicitly stating that certain IP ranges should produce no BGP announcements. This improves overall hygiene of the routing table by preventing accidental or malicious advertisements of space that should not be globally routed.

Use Cases and Current Implementations of AS0

Regional Internet Registries have been key implementers of AS0-based controls, integrating AS0 into their RPKI services and policies. In recent years, RIRs and their communities have proposed using AS0 ROAs to cover all unallocated address space under their administration. Here is a summary of AS0 adoption among the RIRs:

• APNIC – Implemented: APNIC was the first Regional Internet Registry (RIR) to deploy an AS0 policy, through Policy prop-132 (AS0 for unallocated space). As of September 2020, it has published a comprehensive AS0 ROA covering all IPv4 and IPv6 prefixes that are “available” or unassigned within its region.
• LACNIC – Implemented: LACNIC approved an “ASN 0 ROA” policy in 2020 and put it into effect by June 23, 2021.
• RIPE NCC – Proposed, not adopted: RIPE NCC discussed an AS0 policy in 2019 but ultimately withdrew the proposal after community debate. As a result, RIPE NCC does not auto-publish AS0 ROAs for its unallocated space (though prefix holders in RIPE can still manually create AS0 ROAs for their own resources if they choose).
• AFRINIC – Implementation stage: AFRINIC introduced a draft AS0 policy with a proposal to implement a distinct TAL in late 2019, but it has not been implemented to date. According to the AFRINIC website, the implementation of RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space (Draft 3) is still in progress. However, AFRINIC encourages resource holders to manually create AS0 ROAs using the Myafrinic RPKI interface.
• ARIN – No policy: ARIN has not put forward a policy to globally mark its free pool with AS0. However, ARIN permits resource holders to create AS0 ROAs for any prefixes they hold and do not plan to announce.

Beyond the RIR initiatives, network operators and other Internet infrastructures are leveraging AS0 in specific use cases. For example, some organizations that have IP address space but are not currently advertising it will create an AS0 ROA for those prefixes – as a proactive safeguard so that if any BGP announcement for those prefixes appears, it will be treated as invalid. This is a way for a prefix owner to say “if you see a route for my prefix, it’s certainly not authorized.” Similarly, it has become best practice for Internet Exchange Points (IXPs) to use AS0 for their peering LAN subnets. IXP LAN IP ranges are meant for internal exchange traffic and should never be globally routed, so operators often publish ROAs with origin AS0 for those subnets. By doing so, if someone mistakenly leaks an IXP’s LAN prefix into BGP, routers performing origin validation will drop it.

Implications for Routing Security and Policy Enforcement

The introduction of AS0 into routing workflows has significant security benefits. It adds an extra layer of defense against BGP hijacks and mistakes by ensuring that certain routes (those marked with AS0) will never be accepted. In particular, AS0 ROAs help block hijack attempts of unallocated IP space – a tactic sometimes used by spammers or attackers to route traffic from address blocks that legitimately belong to nobody. By invalidating those bogus routes through cryptographic means, AS0 strengthens the integrity of the global routing table. Network operators who enable RPKI-based route filtering are far less likely to carry hijacked or mis-announced prefixes that fall under AS0 policy. Essentially, AS0 acts as an Internet routing “no-fly zone”, and when widely honored, it can eliminate entire classes of route leaks (like advertisements of IPv4/IPv6 prefixes that are not delegated to any network).

However, the implementetion of AS0 ROA policy by RIRs for routing control has also raised policy and governance questions. For instance, if a network’s membership with an RIR lapses or if there’s a dispute, an RIR could theoretically invalidate that member’s prefixes using AS0, causing other operators to drop routes to that network. On the other hand, current AS0 policies strictly limit its use to unallocated address space – RIRs are not authorized to create AS0 ROAs for allocated, active prefixes. Moreover, even without AS0, RIRs have existing means to revoke address registrations in cases of policy violations (e.g. non-payment or misuse), which would eventually lead operators to filter those routes through other databases or IRR systems. The difference is that an AS0 ROA can make routes disappear almost in real-time (as RPKI updates propagate within minutes), whereas other revocation methods might take longer or rely on individual network policies.

For network operators, accepting AS0 ROAs provides a straightforward and effective way to protect routing infrastructure from bogon address blocks, which are often exploited for malicious purposes such as spam or DDoS attacks. At the same time, operators who prefer greater control over validation policy may choose not to include these TALs and instead use customised filters. Network operators can also generate their own SLURM file to invalidate the unallocated address space from RIPE NCC and ARIN, which seem not to have plans to implement the policy in the short term. The AS0 deployment model is intentionally opt-in, giving each operator the flexibility to decide whether and how to enforce AS0-based filtering, based on their own operational and security priorities.

Overall, AS0 serves as an effective mechanism for strengthening routing security by enforcing the principle that “if no AS is authorized to announce a prefix, then no announcement should be accepted.” Its use within the RPKI framework has helped block potential vectors for hijacking unrouted or unallocated IP address space. As with any security measure that involves route rejection, using AS0 involves a balance between trust and control.

Author: Anastasia Kleiman