Which AS numbers are reserved for private use in BGP, and what must happen to them before routes reach the public Internet?
answer
- a best current practice, BCP 6
- one 16-bit block, one 32-bit block
- removed before the global table
- the last numbers are not private
- separate blocks for examples
basics
~10 sRFC 6996 reserves 64512-65534 and 4200000000-4294967294 for private use. Because they are not globally unique, private ASNs must be removed from AS_PATH, and AS4_PATH, before routes are advertised to the global Internet.
solid answer
~40 sPrivate-use ASNs are RFC 6996's two blocks: 64512–65534 (1,023 numbers) and 4200000000–4294967294 (94,967,295 numbers). They are not globally unique, so if prefixes originate from them they MUST be removed from `AS_PATH`, and from `AS4_PATH` where present, before the routes are advertised to the global Internet; RFC 7454 adds that private ASNs should not be sent to peers outside the private arrangement and should be stripped when received from them. Typical uses are a single-homed customer speaking eBGP to its provider, which strips the private ASN and announces the prefix from its own AS, and data-centre fabrics that number each tier (RFC 7938). Do not confuse them with the *Last ASNs* 65535 and 4294967295 (reserved by RFC 7300, not private) or the documentation blocks 64496–64511 and 65536–65551 (RFC 5398).
go deeper
Recall the 16-bit private block, 64512 to 65534, and that private numbers never belong in paths on the public Internet.
Explain both RFC 6996 blocks, who strips private ASNs and where, and how private, Last, documentation and AS_TRANS numbers differ.
Show the traps: removal that fails on mixed paths, routers unaware of the 32-bit range, and why multihoming forces a public ASN.
Argue an ASN plan for a large fabric or estate: 16-bit versus 32-bit private numbers, reuse versus uniqueness, and what each choice costs in policy.
## The reserved ranges Several parts of the AS number space are set aside, each for a different reason, and confusing them is the usual mistake. | Range | Size | Purpose | Source | |---|---|---|---| | 64512–65534 | 1,023 | **Private use**, 16-bit space | RFC 6996 (BCP 6) | | 4200000000–4294967294 | 94,967,295 | **Private use**, 32-bit space | RFC 6996 (BCP 6) | | 65535 | 1 | **Last ASN** of the 16-bit range, reserved | RFC 7300 (BCP 6) | | 4294967295 | 1 | **Last ASN** of the 32-bit range, reserved | RFC 7300 (BCP 6) | | 64496–64511 | 16 | **Documentation** and examples | RFC 5398 | | 65536–65551 | 16 | **Documentation**, numbers needing 32 bits | RFC 5398 | | 23456 | 1 | `AS_TRANS`, stand-in for 4-byte ASNs | RFC 6793 | IANA's registry also marks AS 0 as reserved. Recompute the sizes if you need them: 65534 − 64512 + 1 = 1,023 and 4294967294 − 4200000000 + 1 = 94,967,295. ## Why 65535 is not private RFC 1930 originally listed **64512 through 65535** for private use. RFC 6996 replaced that section with the 1,023-number block ending at **65534**, and RFC 7300 reserved 65535 separately. The reason is communities: an RFC 1997 community carries an ASN in its high-order 16 bits, and values whose high half is `0xFFFF` (65535) include the **well-known communities** such as `NO_EXPORT` (`0xFFFFFF01`). Using 65535 as a private ASN risks emitting well-known community values by accident. RFC 7300 says the Last ASNs **must not** be advertised to the global Internet and operators should filter them. ## The stripping rule - RFC 6996 §4: if prefixes originate from private ASNs, those ASNs **MUST be removed** from the AS path attributes, including `AS4_PATH`, before the routes are advertised to the global Internet. - Ordinary AS-path filtering MAY also be used to stop prefixes originated from private ASNs reaching the Internet. - RFC 7454 (BCP 194): private ASNs should not be used in advertisements to peers outside the private arrangement, should be stripped when received from such peers, and prefixes carrying them should not be accepted except from customers. - A private ASN in a path reaching the global table identifies no one uniquely: several networks may use the same number, and the true originator can only be found by tracing back to the nearest public AS. Two implementation traps from RFC 6996: some implementations do not remove private ASNs when the path **mixes private and public ASNs**, and implementations unaware of the newer 32-bit range may stop removing any private ASN once old- and new-range numbers are mixed. Before using 4200000000–4294967294, check that every eBGP speaker supports RFC 6793 and that the removal features recognise both ranges. ## Where private ASNs fit 1. **Single-homed enterprise.** It speaks eBGP to provider AS 64496 using private ASN 64512 and announces provider-assigned `203.0.113.0/24`. The provider removes 64512, so the Internet sees the prefix originate from 64496 — consistent with RFC 1930, which says a single-homed site needs no AS of its own. 2. **Multihoming changes the answer.** With a second provider, AS 64497, the prefix would appear to originate from two different ASes once each provider strips the private number. RFC 1930's "one prefix, one origin AS" principle is why a multihomed enterprise obtains a public ASN. 3. **Data-centre fabrics.** RFC 7938 runs eBGP between fabric tiers with private ASNs from 64512–65534. The 1,023-number limit pushes it to reuse ASNs across clusters, which needs an implementation feature that accepts the local ASN in `AS_PATH`; the 32-bit private range removes much of that pressure. ## Pitfalls - Treating 65535 as the top of the private block — that is RFC 1930's superseded range. - Using documentation ASNs in production: RFC 5398 says configurations should not peer with ASes numbered from that set. - Assuming the provider will strip private ASNs without agreeing it — the private arrangement must be explicit on both sides. - Mistaking 23456 for a private number: it is `AS_TRANS`, and seeing it in a path means a 4-byte ASN crossed an old speaker. - Forgetting the 32-bit block exists: RFC 6996 added it precisely because new uses such as data-centre fabrics outgrew 1,023 numbers.
- Why is AS 65535 not usable as a private ASN even though it sits right after the private block?RFC 7300 reserves it as a Last ASN. RFC 1997 communities whose high-order 16 bits are 65535 include the well-known communities such as NO_EXPORT, so using 65535 as a private AS risks tagging routes with well-known values by accident. RFC 7300 also says Last ASNs must not be advertised to the global Internet.
- What should an operator check before numbering devices from the 4200000000-4294967294 private range?RFC 6996 §4: every eBGP speaker must support 4-octet ASNs (RFC 6793), and any implementation feature that removes private ASNs must recognise both private ranges. Otherwise private numbers can leak, and some implementations stop removing private ASNs altogether when a path mixes old- and new-range numbers.
saying these in an interview costs you the question
- Private ASNs run from 64512 all the way to 65535.
- A private ASN can be announced to the Internet if no one else uses it.
- The documentation ASNs 64496-64511 are spare private numbers.
- Private ASNs exist only in the 16-bit space.
- Removing private ASNs from AS_PATH is optional, purely cosmetic tidying.