How do 4-byte AS numbers work in BGP, and how does a 4-byte-ASN speaker peer with an old 2-byte-only speaker?
answer
- sixteen bits ran out
- a capability in the OPEN
- one reserved stand-in number
- an optional transitive path copy
- decimal, not dotted, notation
basics
~20 sRFC 6793 widens AS numbers from 16 to 32 bits, negotiated by a BGP capability. Toward a speaker without it, any ASN above 65535 becomes AS_TRANS (23456) in 2-byte fields, and the true path rides in the optional transitive AS4_PATH.
solid answer
~50 sBGP-4's OPEN and `AS_PATH` carry an ASN in 2 octets, so the space was 0–65535; RFC 6793 (which obsoletes RFC 4893) expands it to 0–4294967295. A speaker that supports this advertises capability 65 in its OPEN, carrying its full 4-octet ASN; when both peers advertise it, `AS_PATH` and `AGGREGATOR` carry 4-octet numbers. Toward an old speaker, the new one sends a 2-octet `AS_PATH` in which every ASN above 65535 is replaced by `AS_TRANS` (23456), plus `AS4_PATH` (attribute 17), an optional transitive attribute with the true path. Old speakers pass it along untouched, and the next new speaker rebuilds the real path from the two. A new speaker whose own ASN is above 65535 puts 23456 in the OPEN's `My Autonomous System` field. RFC 5396 says to write ASNs in plain decimal, `asplain`: 65540, not `1.4`.
go deeper
Recall that ASNs grew from 16 to 32 bits, that old numbers kept their values, and that 23456 is the stand-in old routers see.
Explain capability 65, what goes in the OPEN, how AS_PATH and AS4_PATH differ toward an old speaker, and how the next new speaker rebuilds the path.
Show the operational edges: AS_TRANS colliding in MED comparison, path loss when old speakers aggregate, 2-octet communities, and upgrading every router before renumbering.
Weigh a 4-byte ASN against a scarce 2-byte one: what still depends on 2-octet fields in your partners' networks, and how to verify every eBGP neighbour first.
## Why the number grew RFC 4271 defines the OPEN message's `My Autonomous System` field as a **2-octet unsigned integer**, and the original `AS_PATH` encodes each ASN in 2 octets too. That allows 65,536 values, and RFC 1930 was already warning in 1996 that the space was finite. **RFC 6793** (Standards Track; it obsoletes RFC 4893 and updates RFC 4271) expands the pool to **0–4294967295**. Existing numbers did not change. A 2-octet ASN becomes a 4-octet one by setting the two high-order octets to zero; RFC 6793 calls such numbers **mappable**. A number above 65535 is **non-mappable**: it has no 2-octet form. ## Negotiating 4-octet ASNs - A "NEW" speaker (one supporting RFC 6793) advertises the **four-octet AS number capability**, code **65**, in its OPEN (capabilities are RFC 5492's mechanism). The capability value is the speaker's own ASN as 4 octets; the length is 4. - When a NEW speaker receives that capability from a NEW peer, it uses the ASN in the capability **instead of** the OPEN's `My Autonomous System` field. - Between two NEW speakers, `AS_PATH` and `AGGREGATOR` simply carry 4-octet ASNs, and the transition attributes below **must not** be sent; if one arrives anyway, the receiver discards that attribute and processes the rest of the UPDATE. ## Talking to an old speaker | Item | NEW speaker to NEW speaker | NEW speaker to OLD speaker | |---|---|---| | OPEN `My Autonomous System` | own ASN, or 23456 if non-mappable (the capability carries the real one) | own ASN if mappable, otherwise **`AS_TRANS` = 23456** | | `AS_PATH` | 4-octet ASNs | 2-octet ASNs; each non-mappable ASN replaced by 23456 | | `AS4_PATH` (type 17, optional transitive) | never sent | the path in 4-octet form, unless every ASN in it is mappable | | `AGGREGATOR` | 4-octet ASN | 2-octet; if the aggregator is non-mappable, 23456 here plus `AS4_AGGREGATOR` (type 18) | `AS_TRANS` replaces one ASN with exactly one ASN, so the **path length is preserved** for best-path tie-breaking. `AS4_PATH` survives old speakers because RFC 4271 says a path carrying an **unrecognized optional transitive attribute** should be accepted and passed on, with the Partial bit set. A NEW speaker that receives both attributes rebuilds the path: 1. Count the ASNs in `AS_PATH` and in `AS4_PATH`. 2. If `AS_PATH` holds fewer, ignore `AS4_PATH` and use `AS_PATH` as it stands. 3. Otherwise, take as many leading ASNs from `AS_PATH` as needed so the result has the same count as `AS_PATH`, and prepend them to `AS4_PATH`. Worked example with documentation ASNs (RFC 5398): AS 65540 originates `203.0.113.0/24` to NEW AS 64500, which advertises to OLD AS 64501 with `AS_PATH` = `64500 23456` and `AS4_PATH` = `64500 65540`. AS 64501 prepends itself to `AS_PATH` only (`64501 64500 23456`, three ASNs) and passes `AS4_PATH` untouched (two). NEW AS 64502 takes one leading ASN, `64501`, and rebuilds `64501 64500 65540`. ## Caveats worth knowing - **Shared stand-in.** Many ASes appear as 23456 to old speakers. RFC 6793 §7 warns that MED may then be compared between routes that actually came from different neighbouring ASes. - **Aggregation by old speakers** can lose part of the 4-octet path; RFC 6793 notes that this risks loops unless the aggregate is less specific than all its components. - **Own-AS adoption.** An AS may upgrade its speakers piecemeal while it keeps a 2-octet ASN, but RFC 6793 assumes it uses a 4-octet ASN only after *all* its BGP speakers support the extension. - **Communities.** An RFC 1997 community puts an ASN in its high-order 2 octets, which a non-mappable ASN cannot fit. RFC 6793 points to four-octet AS-specific extended communities; RFC 8092's Large Communities (a 4-octet Global Administrator plus two 4-octet fields) were designed with 4-octet ASNs in mind. ## Writing ASNs down RFC 5396 names three notations and recommends one: - **asplain** — plain decimal for every ASN: `65540`. RFC 5396 makes this the standard representation. - **asdot+** — high and low 16 bits joined by a dot for every ASN: `0.64500`, `1.4`. - **asdot** — decimal below 65536, dotted from 65536 up: `64500`, `1.4`. For 65540: 65540 − 65536 = 4, so the high half is 1 and the low half is 4, giving `1.4`.
- Why does RFC 6793 carry the real path in a new optional transitive attribute instead of changing AS_PATH for every speaker?Old speakers cannot parse a 4-octet AS_PATH, but RFC 4271 already tells them to accept an unrecognized optional transitive attribute and pass it on with the Partial bit set. So AS_PATH stays in a form they understand, with AS_TRANS keeping its length right, while AS4_PATH crosses them unchanged until a new speaker merges the two.
- How can AS_TRANS distort MED comparison?MED is meant to be compared only between routes from the same neighbouring AS. If an AS with old speakers peers with two different ASes that both present themselves as 23456, it sees one neighbouring AS where there are two, and RFC 6793 §7 warns MED may then influence selection between their routes.
- Can an AS adopt a 4-byte ASN while one of its own BGP routers lacks 4-octet support?RFC 6793 §7 assumes not: an AS may upgrade speakers piecemeal while it keeps a 2-octet ASN, but uses a 4-octet ASN as its own only after all its BGP speakers support the extension. An old router has no way to hold its own AS's true number.
saying these in an interview costs you the question
- 4-byte AS numbers needed a new BGP version.
- A 4-byte-ASN network cannot exchange routes with 2-byte-only speakers.
- AS_TRANS shortens the AS path, so routes through old speakers look closer.
- Existing 2-byte ASNs had to be renumbered into the 4-byte space.
- Dotted notation like 1.4 is the standard way to write 4-byte ASNs.
- AS 23456 is a private ASN anyone may use internally.