Summary

  • RFC 6996 requires Private Use ASNs to be removed from AS path attributes, including AS4_PATH where applicable, before privately originated prefixes are advertised to the global Internet. The requirement defines a boundary outcome, not one universal removal algorithm.
  • Delete, leading-only, all-occurrences, replace and peer-AS exception modes can produce different public paths from the same input. Deletion may shorten the path and alter selection; replacement may retain the count while collapsing several private identities into one public AS.
  • Safe operation records the raw inbound path, the exact versioned transformation per neighbor and AFI/SAFI, reconstructed AS4 state, Adj-RIB-Out, downstream receipt, best-path change and packets. A clean collector path is not a complete history.

The same route left three different borders

Consider a synthetic lab provider using documentation-only ASN 64497 as its example border identity, serving a customer whose private network uses AS 65020, 65030 and 4200000041. ASN 64497 is not a globally assigned public production identity. The customer originates a canary prefix through this internal chain. The provider also learns an alternative lab path in which a non-private documentation ASN sits between two private values.

The first exit uses a limited algorithm. It scans the recently added end of AS_PATH, removes the leading private run and stops when it reaches the first non-private ASN in the documentation-only lab path. The second exit is configured to remove every Private Use occurrence, including values after that non-private example ASN. The third replaces every private occurrence with the lab provider's documentation ASN 64497 so that the visible number of AS hops is retained.

All three exits then perform the ordinary eBGP prepend. Downstream A sees a shorter path. Downstream B sees no private values but loses every distinction among the customer's internal speakers. Downstream C sees several copies of 64497 and may apply a different tie-break, AS-path policy or loop rule. A fourth, older border recognizes only the 16-bit private range and leaves 4200000041 inside an AS4 representation.

Nothing in this example makes Private Use ASNs suitable for the global table. They are not globally unique; cleaning remains necessary. The error is to treat “remove private AS” as a deterministic sentence after it has become a family of versioned transformations.

Private means scoped, not secret

IANA distinguishes several numerical categories. The range 64512–65534 is reserved for Private Use in the 16-bit space. The four-octet range is 4200000000–4294967294. Values 64496–64511 are reserved for documentation and sample code, not private production identity. The terminal values 65535 and 4294967295 are reserved separately by RFC 7300.

That classification matters to automation. A hand-built regex that deletes “high-looking ASNs” can erase documentation values, reserved sentinels or future assignments while missing the actual four-octet private range. A vendor implementation that still recognizes only the old range can accept the command yet export a newer private identity.

Private Use also does not mean hidden. Inside a data-centre fabric, each private ASN can carry genuine operational identity. RFC 7938 describes Clos designs that assign and even reuse private numbers across clusters. The path helps loop detection and diagnosis inside the intended scope. The number becomes unsafe outside that scope because another organization may have used the same value for a different actor.

The public boundary therefore changes the meaning of evidence. Before the edge, 65020 may identify one leaf or customer domain under a local inventory. After the edge, the globally unique provider must remain the accountable neighbor because the internal number can no longer be interpreted globally. Erasure without a retained local mapping does not protect privacy; it destroys the only available attribution record.

What RFC 6996 requires—and leaves local

RFC 6996 says that when prefixes originate from Private Use ASNs, the private numbers must be removed from AS path attributes before global advertisement. It explicitly includes AS4_PATH in four-octet deployments. It also permits normal path filtering as a way to prevent such routes from escaping.

The document warns about implementation differences rather than hiding them. Some implementations known at publication time did not remove anything when a path mixed private and non-private ASNs. A speaker unaware of the newer private range could also fail to remove values across AS_PATH and AS4_PATH.

The BCP does not define an in-band marker saying which nodes were deleted. It does not negotiate a “removal mode” with the downstream peer. It does not require every vendor's all, limited, replace, nearest or peer exception to mean the same thing. Its minimum interoperable outcome is narrower: non-unique private origin identities must not be exposed as if they were globally attributable AS hops.

This is an example of a useful minimum initial specification. It establishes the invariant needed at the common boundary while leaving implementation choices local. Those choices are legitimate only if the operator names and tests them; local freedom is not permission to call divergent output identical.

AS_PATH is both a control input and an evidence record

RFC 4271 defines AS_PATH as a well-known mandatory attribute made of ordered AS_SEQUENCE and unordered AS_SET segments. An external speaker normally prepends its own AS when advertising a route. A receiver scans the path for its own ASN to detect a loop. Implementations commonly use path length in route selection and policies frequently match particular AS sequences.

Deleting a private occurrence therefore does more than improve presentation. It modifies a control input. If three private ASNs become none before the public provider prepends itself, the downstream path may be several positions shorter than an alternative. The route can become more attractive even though no link, commercial relation or forwarding distance changed.

Replacement addresses only one dimension. If 65020, 65030 and 4200000041 are replaced by 64497, the occurrence count can remain. The path now looks like repeated prepending by the provider. It no longer says which internal domains existed, and a downstream policy that limits repeated instances of one AS may respond differently.

The same tension appears in loop prevention. A provider may avoid removing a private ASN equal to the downstream peer's ASN so that the peer continues to reject its own number. Junos calls out this peer-loop restriction and offers no-peer-loop-check to remove it. Nokia exposes a skip-peer-as choice. Disabling the exception is not merely more complete cleaning; it changes whether a particular loop signal survives the boundary.

The correct question is not “did the command remove every private number?” It is “which control and evidence properties must survive when globally ambiguous identities are removed?”

Similar verbs conceal different algorithms

Cisco documentation records a significant release boundary. Older behavior treated a mix of public and private ASNs as a configuration error and did not remove the private values. Later modes can remove private values from mixed paths. The all replace-as form substitutes the local router's AS for removed values. The feature can also be applied per address family, so one neighbor relationship can produce different IPv4 and IPv6 histories.

Junos begins at the recently added, left end and normally stops at the first public AS or at a private value equal to the peer ASN. all changes the scope. With replace, the default substitute is tied to the local AS for the group; nearest can select a public value encountered in the original path under the documented rules. Confederation member values have already been processed before this operation.

Nokia SR OS separates limited, skip-peer-as and replace. Its documentation identifies how local-as, router autonomous-system or confederation context selects the replacement value. It also states the operational consequence often lost in command summaries: deletion can shorten AS_PATH and make a route more preferable. When combined with as-override, removal occurs first.

Arista documents default preservation, removal and replacement, while its current manual also states a mixed public/private limitation for the described command behavior. The safe lesson is not that one platform is correct and another is wrong. The lesson is that configuration names are symbolic interfaces. Running output on the deployed release is the authority.

A mixed fleet must therefore carry a semantic matrix, not a Boolean “feature supported” column. For each platform and release, record the recognized ranges, leading/all behavior, mixed-path action, peer exception, replacement value, confederation ordering, AS4 treatment, AFI/SAFI scope and observable counters.

AS4_PATH makes partial cleaning possible

Four-octet ASN compatibility can divide path information between AS_PATH and AS4_PATH when new and old BGP speakers interact. RFC 6793 defines how a new speaker reconstructs effective path information and describes cases in which complete reconstruction is not possible.

RFC 6996's reference to both attributes is therefore material. An old or incomplete cleaning implementation might remove a 16-bit private value in the visible AS_PATH while retaining a four-octet private value in AS4_PATH. Another might make a decision on the reconstructed path but display only one raw component in a routine command.

Testing must preserve three views: raw AS_PATH, raw AS4_PATH and the platform's reconstructed effective path. Compare them before outbound policy, after transformation and at a capable downstream receiver. A clean display on one side does not prove that the transitive compatibility attribute was cleaned or that another release reconstructs the same result.

AS_TRANS must not be classified as a Private Use ASN simply because it appears near this boundary. It is a reserved compatibility value with a specific four-octet transition role. Removing it under an over-broad private-range matcher can corrupt reconstruction rather than improve public hygiene.

Confederation removal is a different authority

Confederations use AS_CONFED_SEQUENCE and AS_CONFED_SET to expose Member-AS structure internally while presenting a confederation identifier externally. Their segment processing is standardized by RFC 5065. Many operators choose private values for Member-AS identities, but the two concepts are independent: a private ASN need not be in a confederation, and a confederation member number need not be private.

Order matters when both mechanisms exist. If confederation segments disappear before remove-private examines the remaining path, the removal algorithm never sees the same input that a pre-confederation diagnostic showed. A platform that documents a different order can produce another outcome.

The evidence record should therefore distinguish “removed because it was a confederation segment” from “deleted because it belonged to an IANA Private Use range” and “replaced by egress policy.” Collapsing all three into “path sanitized” makes rollback impossible to reason about.

Reuse makes the loop question harder

Private numbering succeeds because separated scopes may reuse it. A data-centre design can assign the same leaf-AS range in multiple clusters. When those scopes become connected during merger, disaster recovery or temporary backbone work, a router may receive its own private ASN from a different physical actor and reject the route as a loop.

Some designs use allowas-in or related exceptions. RFC 7938 discusses the technique in its topology and notes that it is not standardized. This can be a reasoned local choice when the topology supplies other loop boundaries. It also means the correctness proof no longer comes from the ordinary “my ASN never appears” invariant.

Removing the duplicated private value on a public edge may prevent an outside false loop, but it cannot repair internal ambiguity. Replacing all duplicates with the provider's public AS may create a different repeated-AS shape. Leadership should not use egress cleanup as a substitute for inventorying collisions when two private scopes begin to interact.

A clean collector path proves only the final projection

Suppose a route collector in the synthetic documentation-range lab shows 64497 64498 and no private numbers. This proves that one observation path received a cleaned representation. It does not turn either documentation ASN into a globally assigned public identity, nor prove which private ASNs were present, whether the egress deleted or replaced them, whether another AFI or neighbor used the same policy, or whether the internal origin was authorized.

RFC 6996 notes that identification may require tracing back to the neighboring globally unique AS or inspecting other attributes. Operationally, that means the public provider inherits an evidence obligation. For every exported customer route, it should be able to map the public path back to the customer relationship, inbound session, raw path and change epoch.

The minimum ledger contains prefix, AFI/SAFI, source peer, relationship class, raw AS_PATH, raw AS4_PATH, reconstructed path, IANA classification version, removal policy and release, matched scope, peer-AS exception result, replacement value, post-policy path and local prepend. It then attaches Adj-RIB-Out by neighbor, downstream Adj-RIB-In, downstream best-path reason, FIB next hop and packet observations.

That ledger separates questions that a single show bgp cannot answer:

  • Was the private identity used inside its approved scope? Internal allocation and topology record.
  • Did it reach the correct boundary? Inbound RIB and raw attributes.
  • Which transformation acted? Versioned policy trace.
  • Did every public egress meet the invariant? Per-neighbor Adj-RIB-Out.
  • Did path selection change? Downstream candidate and best-path evidence.
  • Who remains accountable? Mapping from the globally unique neighbor to the hidden private origin.
  • Did service traffic move? FIB and packet measurements.

Canary the cases that differ, not the easy case

An all-private path is necessary but insufficient. The test matrix must include a leading private run followed by public ASNs; a private value after a public AS; repeated private values; the neighbor's own private ASN; one value from each private range; a documentation-only ASN that must remain distinct; AS_TRANS in a transition path; confederation-adjacent segments; and AS4_PATH across an old/new speaker boundary.

For every case, write the exact expected sequence under limited deletion, all deletion and replacement. Test the negative space: an unrecognized new-range value should cause the rollout to stop, not be waved through because the command is configured. A peer-AS exception should be demonstrated with one path that remains loop-rejected and one deliberately approved exception.

Compare control candidates before and after the rewrite. If deletion turns a four-hop route into a one-hop public path, downstream policy and selection should be assessed before production. If replacement produces repeated 64497 values, ensure maximum-AS-prepend filters and traffic-engineering rules react as intended.

Rollback must cause re-advertisement. Removing the egress command changes future processing; it does not prove that every downstream Adj-RIB-In has replaced the earlier projection. Use a bounded policy re-evaluation, route refresh or session action according to platform semantics and convergence risk. Verify the old exact path, candidate set and packets after rollback.

Sources