You are here: Home > Publications > RIPE Labs > Mirjam Kühne > Assigning 32-bit ASNs
Content by this author

Assigning 32-bit ASNs

Mirjam Kühne — 18 Jul 2011
Contributors: Alex Le Heux
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).

RIPE NCC ASN Distribution (16 vs. 32 bit)

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.

Global Distribution of 32-bit ASNs Figure 2: Global 32-bit ASN Distribution by RIR

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.

32-bit ASNs routed, not visible and returned Figure 3: Distribution of RIPE NCC assigned 32-bit ASNs returned, visible and not visible in BGP

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.

 

2 Comments

Anonymous says:
18 Jul, 2011 03:42 PM

Another good report from RIPE NCC - many thanks.

I quote the last paragraph:

  "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."

Maybe the outcome for 32-bit ASNs is not too different from
that with 16-bit numbers. However, in absolute terms, if 23%
cannot be seen in the BGP tables, versus 52% that are visible,
this could be seen as a significant under-use of resource.
I would be glad of your comments on this.

There may be lots of reasons, some good, as to why so many
of the 32-bit ASNs (and also the 16-bit ones) are not yet
visible. In some cases, there could be a time-lag between
allocation and use, for instance. In others, there may
be operational reasons for using ASNs only bilaterally and not
releasing them into the global BGP tables.

Overall, though, the allocations seem to be working, and this is a credit to RIPE NCC and their clients. Well done.

Regards.

Mike Norris


Anonymous says:
18 Jul, 2011 04:14 PM
Hi Mike,

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.

This can cause a significant lag between the assignment and the ASN appearing in the global BGP.

Some ASNs are requested for bilateral peerings, but the vast majority are intended for "normal" multi-homing on the internet.

Regards,

Alex Le Heux
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.