Summary
- RFC 6793 lets capable peers exchange four-octet ASNs directly and uses AS_TRANS plus AS4_PATH and AS4_AGGREGATOR to cross older speakers.
- The capability proves support for an encoding, not authority to operate an ASN; mixed-version aggregation can still lose path information.
One path, two representations
A supporting speaker advertises Capability Code 65 and places its AS number in the four-octet capability value. When both peers advertise support, they encode AS numbers directly as four-octet entities in the existing AS_PATH and AGGREGATOR attributes. In that relationship, AS4_PATH and AS4_AGGREGATOR must not be carried; a new speaker receiving them from another new speaker discards them and continues processing.
The boundary changes when a new speaker talks to an old one. The ordinary AS_PATH must remain a sequence of two-octet numbers. A non-mappable four-octet number is represented there by AS_TRANS, the reserved value 23456. The new speaker normally sends an optional transitive AS4_PATH alongside it so that later capable speakers can recover the four-octet information. AS4_AGGREGATOR performs the corresponding role when the aggregating ASN cannot fit.
This is not a simple second copy. A receiving new speaker follows defined rules involving path lengths and the two aggregator attributes. It keeps the leading portion learned through old speakers and combines it with AS4_PATH. Confederation segments are invalid in AS4_PATH and must be excluded. The translation maintains interoperability, but it creates two views whose consistency now matters.
Capability is not identity
The capability says that a BGP speaker understands the four-octet encoding and supplies the AS number it will use for that session. It does not authenticate the organization operating the speaker, prove authorization to use the number, or upgrade a commercial relationship. Those controls remain outside RFC 6793.
Power also remains distributed. Each operator controls software readiness, session policy, validation, monitoring and the moment a four-octet number becomes the AS’s own number. An AS using a two-octet number may upgrade speakers piecemeal. But RFC 6793 assumes that using a four-octet number as the AS’s own waits until all BGP speakers inside that AS support the extension. A non-mappable four-octet number cannot serve as a confederation member number until the confederation has completed the transition.
The beneficiaries are new networks that need numbers beyond the old space, registries that must sustain allocation, and operators that can interoperate during a staged transition. Old neighbors need not all change at once. The cost is that every compatibility boundary must be known and tested.
Reconstruction has a loss boundary
RFC 6793 explicitly identifies cases in which AS_PATH and AS4_PATH cannot reconstruct the complete path. An old speaker may aggregate routes carrying different AS4_PATH information. Depending on implementation, the transition attribute may disappear or the two attributes may contain valid but incompatible partial histories. The document says inconsistency can lose path information and create potential routing loops in certain cases, a condition an attacker could exploit.
That makes observability an executive concern, not just a parser detail. Operators need an inventory of new and old speakers, capability state per adjacency, AS_TRANS appearance, AS_PATH/AS4_PATH length relationships, aggregation points, malformed transition attributes and confederation sequencing. RFC 7607’s prohibition on AS 0 should not be confused with AS_TRANS: zero is invalid in specified attributes, while 23456 has a defined transition purpose.
Evidence and limits
RFC 6793 defines capability advertisement, native encoding, transition attributes, reconstruction, aggregation limits, transition sequencing and security considerations. RFC 4271 supplies the base BGP path model; RFC 7607 distinguishes invalid AS 0 handling. Conclusions about authority, beneficiaries, costs and operating control are analysis based on those facts.
The sources do not prove the upgrade state of a named network, authenticate control of an ASN, guarantee complete reconstruction after every legacy aggregation, or dictate a vendor rollout. A valid four-octet value identifies protocol data; it is not organizational identity proof.
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

