The RIPE NCC has been assigning 32-bit Autonomous System Numbers for quite some time now. In this article we're showing a number of statistics and some analysis.
Note: Figure 2 in this article has been modified on 7 July 2012. Due to a typo, the number of 32-bit ASNs in the ARIN region was wrong.
With 16-bit Autonomous System Numbers (ASNs), 65,536 unique numbers are possible. Just like 32-bit IP addresses, these 16-bit ASNs are becoming a scarce resource. Therefore, in 2007 the Internet Engineering Task Force (IETF) developed a new format: 32-bit AS Numbers ( RFC 4893 ), which increases the supply of ASNs to four billion.
In January 2007 The RIPE NCC started assigning 32-bit ASNs (or 4-byte ASNs as they are also called) by default. Upon request, however, the RIPE NCC still assigns 16-bit ASNs.
In Figure 1 below, you can see the distribution of 32-bit ASNs compared to 16-bit ASNs the RIPE NCC assigned since 2007 (Please note that the numbers for 2011 only include January - July).
Figure 1: 16-bit (blue) compared to 32-bit (red) ASN assignments by the RIPE NCC
In 2011, roughly one third of all ASNs assigned by the RIPE NCC consisted of 32 bits. This means that even with 32-bit ASNs available since 2007, quite a number of 16-bit ASNs are still being requested. However, as you can see in Figure 2, 65% of all 32-bit ASNs have been assigned by the RIPE NCC.
If operators are using up-to-date equipment and software and their upstream provider supports 32-ASNs, they should not experience any problems. The RIPE NCC itself started using 32-bit ASNs in 2007 and has not experienced any problems.
However, as Figure 3 shows, 25% of all 32-bit ASNs assigned by the RIPE NCC, were returned. The main reason for this is that either the user or the upstream provider's equipment did not support 32-bit ASNs. This is becoming less of a problem as time goes by.
Figure 3 shows that 52% of the 32-bit ASNs assigned by the RIPE NCC are visible in the global routing table, as compared to 23% that are not yet visible. When comparing this with 16-bit ASNs, we found that the visibility of 32-bit ASNs is lagging slightly behind. Overall, we can conclude that the majority of the RIPE NCC membership does not see any operational problems with 32-bit AS Numbers.
Comments 2
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Anonymous •
<br />Another good report from RIPE NCC - many thanks.<br /><br />I quote the last paragraph:<br /><br /> "Figure 3 shows that 52% of the 32-bit ASNs assigned by <br /> the RIPE NCC are visible in the global routing table, <br /> as compared to 23% that are not yet visible. When <br /> comparing this with 16-bit ASNs, we found that the <br /> visibility of 32-bit ASNs is lagging slightly behind. <br /> Overall, we can conclude that the majority of the RIPE <br /> NCC membership does not see any operational problems <br /> with 32-bit AS Numbers."<br /><br />Maybe the outcome for 32-bit ASNs is not too different from<br />that with 16-bit numbers. However, in absolute terms, if 23%<br />cannot be seen in the BGP tables, versus 52% that are visible, <br />this could be seen as a significant under-use of resource. <br />I would be glad of your comments on this.<br /><br />There may be lots of reasons, some good, as to why so many<br />of the 32-bit ASNs (and also the 16-bit ones) are not yet <br />visible. In some cases, there could be a time-lag between <br />allocation and use, for instance. In others, there may<br />be operational reasons for using ASNs only bilaterally and not<br />releasing them into the global BGP tables. <br /><br />Overall, though, the allocations seem to be working, and this is a credit to RIPE NCC and their clients. Well done.<br /><br />Regards.<br /><br />Mike Norris<br /><br /><br />
Anonymous •
Hi Mike,<br /><br />The RIPE NCC has in the past contacted holders of "invisible" ASNs to inquire why the ASNs do not seem to be used. It turns out that deployment plans often face unexpected delays, sometimes very long delays. <br /><br />This can cause a significant lag between the assignment and the ASN appearing in the global BGP. <br /><br />Some ASNs are requested for bilateral peerings, but the vast majority are intended for "normal" multi-homing on the internet.<br /><br />Regards,<br /><br />Alex Le Heux