I am wondering what could be the use case where a 16-bit ASN is needed over a 32-bit ASN at this times. I guess if the user have some older equipment and software 16-bit may be needed. Can some please advice for better understanding.

  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 3, 2021 at 21:29

5 Answers 5


It's usually incompatibility, not just with your own hardware, but also that of companies you peer with. I requested an ASN about 3-4 years ago and RIPE provided a 32-bit ASN. We could peer with our ISPs OK, but free peering at public Internet exchanges didn't always work. We requested a 16-bit one in the end. This was a few years ago now, so things may have moved on. I would still go with the 32-bit, you can request a 16-bit if you have specific problems.

  • I believe a 32-bit ASN might (have) cause(d) issues as well if traffic crosses an AS that only supports 16-bit ASNs since the numbers are in the AS path and some BGP implementations might trip over 32-bit numbers in there.
    – Tommiie
    Jan 11, 2019 at 6:33

If you're planning to do a lot with BGP communities which are used for signalling between your own ASN and your upstream or downstream peers, a 32-bit ASN might be less useful since the second 16 bits for the 32-bit ASN are used for communities in 16-bit ASNs. There's an IETF draft which will provide these communities for 32-bit ASNs.

If you're not planning on doing anything with communities outside your own ASN, there's no real drawback in using a 32-bit ASN. Any router nowadays supports it, and if it doesn't, it at least supports the AS23456 transition mechanism.


As mentioned above, using either a 16-bit or 32-bit ASN is mostly well supported today on all the major router vendors. If you are a company that is multi-homing or a small ISP that is only using transit routing to your upstreams, you can get by with the 32-bit allocation from ARIN.

However! If you are planning on using an IX that has route servers or doing some direct peering at IXs (or even with transit providers) where you need to make use of BGP communities to massage your routes, then you need to go back to ARIN before you deploy your 32-bit ASN and request the "next available" 16-bit ASN. Note that they only provide these if someone else abandons the assignment. The are not readily available.

Some examples of problems if you have a 32-bit ASN. Lets say I have XO as one of my peers at an IX (but I'm neither a customer of theirs nor transiting either direction). This particular IX I have only a 1G interface into whereas I have a 40G connection to a transit provider who has 100G to XO. Obviously I'd prefer (if I have the bandwidth need) to use the transit provider rather than the IX (this is one of those backward cases). So how do I peer with the IX but not exchange routes with XO? I send the community using SFMIX as an example) of 0:2828... But what if someone wants to modify how they peer with me? If I have a 32-bit number, its impossible to use 0:395395...

Gets even more convoluted if you use a route server that takes communities (like ANY2) but can't actually address your ASN...

Summary? If you plan on eventually going to more than one IX or have more than two transit providers, you'd be doing yourself a favor by requesting from ARIN a 16-bit replacement. Downside? There aren't any unless someone gives one up so you might be waiting awhile...

Note: This problem still exists as of January 2019. We are in the process of "fixing" a client who has run into this very issue.

  • I doubt this still is an issue today with Internet exchanges.
    – Tommiie
    Jan 11, 2019 at 6:36
  • The issue isn't the IX themselves as 32-bit is always allowed. The issue is in using the control mechanisms of the route servers that take their commands via the BGP comunities (new format) where the first 16-bits define the source ASN and the second 16-bits define control with whom... You can see examples of this in just about any route server communities control page for just about any IX. (see de-cix.net/en/resources/route-server-guides/… for an example of the control issues). Note, this only is an issue if you're an ISP that peers at IXs
    – Marcos
    Mar 17, 2019 at 1:05

16-bit ASNs and 32-bit ASNs are interoperable. You do not have to renumber. If you do not plan to expand your network it is sufficient to check that your tools still work when you enter a 32-bit ASN.

If you are using the latest equipment and software and your upstream provider supports 32-bit ASNs, apply for a 32-bit ASN. If you are using older equipment and software, apply for a 16-bit ASN.


A unique ASN (Autonomous System Number) is allocated to each AS for use in BGP (Border Gateway Protocol) routing. In BGP, each routing domain is a single administrative domain and has a unique AS number assigned to it, and is operated within a uniform set of routing policies. It also maintains interdomain routing.

Until 2007, AS numbers were defined as 16-bit integers, which allowed for a maximum of 65536 assignments. RFC 4893 introduced 32-bit AS numbers, which Internet Assigned Numbers Authority (IANA) has begun to allocate to regional Internet registries (RIRs), although this proposed standard has now been replaced by RFC 6793. These numbers are written preferably as simple integers (in a notation sometimes referred to as "asplain") ranging from 0 to 4,294,967,295, or in the form called "asdot" which looks like x.y, where x and y are 16-bit numbers.

Source: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)

  • 1
    Please do not plagiarize an answer. If you are going to quote a source, use the quote feature and be sure to properly attribute the source.
    – Ron Maupin
    Jul 28, 2016 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.