[AfrICANN-discuss] More Number Scarcity

Anne-Rachel Inné annerachel at gmail.com
Mon Apr 2 20:11:39 SAST 2012


 More Number Scarcity

http://blog.icann.org/2012/04/more-number-scarcity/

by Leo Vegoda on April 2, 2012

Last year ICANN allocated the last five IPv4 blocks to the Regional
Internet Registries (RIRs). Since then we have seen a concerted effort on
the part of network and content providers to make sure they support IPv6,
so they’ll be ready for the next few billion Internet users. But there’s
another Internet number resource which is running short: 16-bit Autonomous
System Numbers (ASNs).

Internet networks learn how to reach destinations (IP addresses) using an
IETF protocol called the Boarder Gateway Protocol (BGP). BGP uses unique
Autonomous System (AS) numbers to identify individual networks (routing
domains) in order to announce the reachability of destinations (IP
addresses). Originally, BGP used 16-bit numbers, allowing slightly more
than 65,000 ASs

Internet growth in the 1990s made it clear that a 16-bit number space is
insufficient and the first proposals for a 32-bit number space, allowing
about 4.3 billion AS numbers, were published in
2001<https://tools.ietf.org/id/draft-ietf-idr-as4bytes-00.txt>.
In parallel with this work, the addressing community began developing a
transition policy in the RIRs’ open policy forums and socialising it with
network operators, the consumers of AS numbers.

The IETF work was published as a standards track
RFC<https://tools.ietf.org/html/rfc4893>in 2007. And while IPv4 and
IPv6 networks do not interoperate, networks
that don’t know about 32-bit AS numbers can still communicate with networks
using 32-bit AS number using a transition mechanism described in the RFC.
The RIR community work was ratified as a Global Policy in
2008<http://www.icann.org/en/news/in-focus/global-addressing/global-policy-asn-blocks-31jul08-en.htm>and
included a timetable for the transition. This echoed the timetables
the
addressing communities had agreed to in the policies governing AS number
assignments in each of their regions.

These regional policies have promoted 32-bit AS number assignments and now
require the RIRs to treat all AS numbers as part of the same 32-bit pool.
Unfortunately, lots of networks reported problems making use of 32-bit
ASNs. In the region served by the RIPE NCC, which has had the most success
at assigning 32-bit
ASNs<http://www.nro.net/wp-content/uploads/nro_stats_2011_q4.pdf>[PDF,
2.66 MB] (PDF slides 8 & 9), they still comprise just a third of the
total ASN assignments. The reason for the huge disparity in acceptance
between the five regions is not clear. Earlier this month, John Curran,
ARIN’s CEO & President, asked the ARIN
community<http://lists.arin.net/pipermail/arin-ppml/2012-March/024374.html>for
an easy, straightforward answer to this question.

One of the reasons networks have problems deploying 32-bit AS numbers is
that network providers who have not upgraded their equipment will see the
same transition AS number being used by different network providers. This
duplication of AS numbers causes problems for monitoring tools and even
path selection mechanisms. But there are just three blocks of 16-bit ASNs
left, so the time is rapidly approaching when networks won’t be able to
swap out a 32-bit AS number for a 16-bit replacement AS number. There won’t
be any new 16-bit AS numbers left.

Much has been written about the lack of IPv4 addresses and its impact on
the potential economic growth of countries and industries.  The need to
transition to IPv6 has triggered coordinated action plans from major
network, content and access providers to support both IPv4 and IPv6.
However, little attention has been paid to the diminishing pool of 16-bit
ASN numbers, which are another enabler of Internet growth.  The technical
community has defined a 32-bit ASN specification; the addressing
communities have implemented suitable assignment policies; what is now
needed is widespread acceptance of 32-bit AS numbers by network providers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/africann/attachments/20120402/f6d07c6e/attachment.htm


More information about the AfrICANN mailing list