Summary

  • Autonomous System number 0 is a reserved non-identity in BGP OPEN and four UPDATE attributes, yet the numeric value zero is valid in other objects, including the ORIGIN code for IGP. Evidence must therefore retain the field, not merely the number.
  • RFC 7607 assigns the smallest specified refusal by location: abort a connection whose peer claims AS 0, treat an AS_PATH carrying AS 0 as withdrawn, and discard a malformed AGGREGATOR or four-octet transition attribute while continuing the rest of the UPDATE processing.

Imagine a route-monitoring console during a change window. One event says ORIGIN: 0. Another says an AS_PATH segment contains 0. An aggregation process also reports an AGGREGATOR value ending in zero. The event pipeline turns all three into one card: zero observed in BGP.

The card is accurate in the least useful sense. Under RFC 4271, ORIGIN value 0 is the ordinary code for IGP. It does not name Autonomous System 0. Under RFC 7607, an ASN value of zero inside AS_PATH is prohibited and makes the route malformed. The zero carried as an aggregator ASN is prohibited too, but the error procedure does not remove the same unit of state. If zero is the peer AS in OPEN, there may be no established session at all.

The incident is not short of alarms. It is short of field identity.

That distinction matters because BGP error handling is an allocation of authority. A receiver may terminate a connection, remove the routes in one UPDATE, or discard one attribute and continue. Choosing a stronger action than the specification requires can withdraw unrelated valid reachability. Choosing a weaker action can admit or propagate a reserved non-identity. RFC 7607 is valuable not because zero is difficult to recognize, but because it tells the receiver which object must be refused.

Reserved means unavailable for identity

IANA's current Autonomous System Number registry lists 0 as Reserved and cites RFC 7607. The special-purpose AS registry makes a second point visible: reserved and special-purpose numbers are not interchangeable. AS_TRANS 23456 has a defined role in four-octet transition. Documentation ranges and private-use ranges have bounded uses. AS 0 is not a convenient private ASN, a migration placeholder or an anonymous origin.

RFC 7607 updates the base BGP specification and names five prohibited carriage points: the peer AS in OPEN, and AS_PATH, AS4_PATH, AGGREGATOR and AS4_AGGREGATOR in UPDATE. A speaker must not originate or propagate a route with AS 0 in any of those four attributes. It must not initiate a connection claiming to be AS 0.

This is a semantic prohibition, not merely a range check at the configuration screen. A platform can reject router bgp 0 at commit time and still need to parse malformed state received from another implementation. Juniper's four-octet ASN documentation, for example, describes a commit failure for restricted AS numbers including zero. That is useful prevention on the named product. It is not evidence that every neighbor, converter, route server, aggregator or software release will keep zero off the wire.

Nor does a generic border filter complete the obligation. FRRouting's BGP documentation includes a bogon-AS example matching _0_ in AS_PATH. Such a rule can add defense and produce useful counters.

It cannot see a peer-AS value in OPEN, and a normal AS-path expression does not establish what happened to AGGREGATOR, AS4_PATH or AS4_AGGREGATOR.

Policy is an additional control surface; it is not a substitute for field-correct protocol processing.

One value, three failure units

The clearest way to read RFC 7607 is as a field/action matrix.

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. RFC 4271 defines the OPEN field and the subcode; RFC 7607 decides that zero is unacceptable. The failure unit is the attempted adjacency. There are no routes from an established instance of that session to preserve.

If an UPDATE contains AS 0 in AS_PATH, RFC 7607 declares the UPDATE malformed and sends processing to RFC 7606. RFC 7606 assigns malformed AS_PATH to treat-as-withdraw. Every route carried in that UPDATE is treated as if withdrawn and removed from Adj-RIB-In under the base BGP procedures. The design normally keeps the session and the other valid routes exchanged over it. The failure unit is the affected reachability, not the whole adjacency.

If AS 0 appears in AGGREGATOR, RFC 7607 again invokes RFC 7606, but AGGREGATOR has a different error action. A malformed AGGREGATOR is discarded and the UPDATE continues to be processed. The failure unit is the attribute. The route is not thereby guaranteed to survive: it may fail some other check or policy, and selection is a separate decision. But “AS 0 seen in an UPDATE” does not justify the blanket claim that the route must be treated as withdrawn.

AS4_PATH and AS4_AGGREGATOR belong to the transition machinery defined by RFC 6793. RFC 7607 makes a zero in either attribute malformed and delegates processing to that document. RFC 6793 uses attribute discard and local logging for malformed transition attributes in the specified old/new-speaker contexts, then continues UPDATE processing. Capability context matters because those attributes reconstruct four-octet information across speakers with different support. Discarding the transition attribute can reduce the information available for reconstruction; it is not a declaration that the original writer was trustworthy.

The three outcomes—connection abort, treat-as-withdraw and attribute discard—are not a scale on which operators choose their preferred severity. They are consequences attached to different protocol objects. The field determines the permissible refusal.

The valid zero that exposes bad observability

The ORIGIN attribute makes a good test of an incident pipeline. RFC 4271 defines three ORIGIN values: 0 for IGP, 1 for EGP and 2 for INCOMPLETE. A legitimate route can therefore contain a byte whose decoded value is zero without making any ASN claim.

An observability system that indexes only the number may match ORIGIN 0, ASN 0, the IPv4 default prefix 0.0.0.0/0, a zero metric and an empty counter under one rule. The resulting false positives encourage suppression. The resulting false negatives are worse: an operator may silence the generic rule and miss a prohibited AS_PATH occurrence.

The minimum incident record should preserve message type, attribute type code, raw or lossless value, peer, direction, AFI/SAFI, four-octet capability context and timestamp. A display label is helpful only if the underlying record remains recoverable. The source of truth is not the word “zero”; it is the tuple of field, value and protocol state.

This principle also prevents an attractive but dangerous repair. Replacing every numeric zero with a null or omitting it from telemetry may make the dashboard quiet. It destroys the evidence that distinguishes a valid ORIGIN code from a prohibited identity. Data cleanliness is not protocol correctness.

AS 0 ROAs are a separate signal

AS 0 appears in RPKI for a deliberate reason, but not as a routable origin. RFC 6482 defines a Route Origin Authorization as a signed object containing one asID and one or more prefix authorizations. RFC 6483 explains the AS 0 convention: the holder uses an AS 0 ROA to state that the described prefix and its more specifics should not be used in routing.

The object does not authorize a BGP speaker to originate the prefix as AS 0. RFC 6907 states the logical consequence: because no valid route can have origin ASN 0, no route can match an AS 0 ROA. A route with a real origin under a covering AS 0 ROA can be Invalid when no candidate ROA validates its actual origin and length.

There is an important qualification. RFC 6483 permits an AS 0 ROA to coexist with ROAs for routable ASNs. Route validation is Valid if any candidate ROA matches the prefix, maximum length and actual origin. In that case, the AS 0 ROA does not override the matching authorization. “AS0 exists” is not, by itself, the route-validity result.

The two systems also move on different clocks. A BGP OPEN or UPDATE is processed in the session's message stream. A ROA is published, validated through a certificate path, collected by relying parties and re-evaluated according to repository and cache state. A change to an AS 0 ROA may take a different time to reach validators than a corrected BGP advertisement takes to reach peers. An incident can involve both lanes, but the evidence ledger must keep their timestamps and authorities separate.

That separation marks the boundary from the existing governance question around AS0 ROAs. RFC 7607 is not a policy for deciding which address space should be disavowed. It is a rule for refusing a value that cannot identify a BGP peer or path participant.

From the packet to the export boundary

A useful investigation starts before local policy. RFC 7854 defines the BGP Monitoring Protocol and gives a collector ongoing access to a peer's Adj-RIB-In, received UPDATEs, peer transitions and route mirroring. Pre-policy Adj-RIB-In can show that an invalid attribute arrived even when post-policy state is clean. That distinction prevents the receiving operator from claiming that absence after policy proves absence on the wire.

Post-policy Adj-RIB-In shows the result after inbound handling. For an AS_PATH zero, the affected NLRI should not remain as accepted reachability. For an AGGREGATOR or transition-attribute zero, the malformed attribute should not remain, while the route may continue if otherwise valid. Implementation logs should identify the field and action. A counter that says only “malformed update” is insufficient when the response depends on the attribute.

RFC 9069 adds Loc-RIB monitoring to BMP. Loc-RIB is the set selected by the local Decision Process. It answers a different question from post-policy Adj-RIB-In: not merely whether a route was accepted, but whether it became locally selected state. A claim of traffic impact needs another step—FIB and packet evidence—because a control-plane selection does not prove successful programming or delivery.

RFC 8671 adds pre- and post-policy Adj-RIB-Out visibility. That is where the “must not propagate” requirement becomes testable. Pre-policy output can show candidate state; post-policy output can show what the local speaker prepared to send to a named peer. A downstream collector or cooperating neighbor can then confirm receipt or absence. No single collector proves global absence, but a bounded export perimeter can be audited.

The evidence sequence should therefore read:

  1. preserve the OPEN or UPDATE and decode the exact zero-bearing field;
  2. record peer identity, capability negotiation and implementation release;
  3. show the specified NOTIFICATION, treat-as-withdraw or attribute-discard consequence;
  4. compare pre- and post-policy Adj-RIB-In;
  5. inspect Loc-RIB and, where impact is alleged, the FIB and packets;
  6. inspect every material Adj-RIB-Out boundary;
  7. identify and correct the originating configuration, template or software path;
  8. repeat the observation after controlled readvertisement or session recovery.

Correct the writer, do not merely hide the value

The receiver must protect its routing system immediately, but downstream filtering is not the final repair. AS 0 may result from an integer default, an empty variable converted to zero, a local-AS migration, a broken aggregation step or a four-octet reconstruction defect. Those causes have different recurrence risks. The source record should include generated configuration, template input, commit validation, relevant logs and the first point at which the forbidden field exists.

Source correction should be canaried. For an OPEN defect, verify that the corrected peer claims the intended routable ASN and that the adjacency establishes without weakening the peer-AS check. For an AS_PATH defect, verify the clean path before allowing the affected routes back into Adj-RIB-In. For aggregator and transition attributes, verify both that zero is absent and that any information needed for four-octet reconstruction is coherent.

Do not “repair” a received AS_PATH by replacing zero with a guessed ASN. That invents provenance. Attribute discard is allowed only where the specification assigns it. Treat-as-withdraw deliberately refuses the route rather than fabricating a path. The writer must send a new, defensible advertisement.

The same restraint applies to an AS 0 ROA. Removing or replacing a signed RPKI object is an action by the resource holder through the RPKI publication system, not a BGP receiver's interpretation of a packet. If the ROA is erroneous, correct the object and observe validator convergence. Do not alter BGP path evidence to make route-origin validation look cleaner.

Sources