Table of contents
- History of the Internet
- Before the RIRs
- Emergence of the RIRs
- The RIR system
- RIRs and the global Internet community
- The future of RIRs
The current system of managing Internet address space involves Regional Internet Registries (RIRs), which together share a global responsibility delegated to them by the Internet Assigned Numbers Authority (IANA). This regime is now well established, but it has evolved over ten years from a much simpler, centralized system. Internet number spaces were originally managed by a single individual authority, namely the late Jon Postel, co-inventor of some of the most important technical features of todays Internet.
It is important to understand that the evolution of the RIR system was not simply the result of Internet growth and the natural need to refine and decentralize a growing administrative task.
On the contrary, it arose from, and closely tracked, the technical evolution of the Internet Protocol, in particular the development of todays IP addressing and routing architecture.
In a relatively short time, the RIR system has evolved into a stable, robust environment for Internet address management. It is maintained today through self-regulatory practices that are well established elsewhere in the Internet and other industries, and it maintains its legitimacy and relevance by firmly adhering to open, transparent, and participatory decision-making processes.
Before the RIRs
IP Address Architecture
An important feature of the Internet Protocol (IP) is the ability to transparently use a wide variety of underlying network architectures to transport IP packets. This is achieved by encapsulating IP packets in whatever packet or frame structure the underlying network uses. Routers connecting different networks forward IP traffic by decapsulating incoming IP packets and then re-encapsulating them as appropriate for the next network to carry them.
To achieve this task with full transparency, the IP needed an addressing structure, which developed as a two-level hierarchy in both addressing and routing. One part of the address, the network part, identifies the particular network a host is connected to, while the other part, the local part, identifies the particular end-system on that network.
Internet routing, then, has to deal only with the network part of the address, routing the packet to a router directly connected to the destination network. The local part is not used at all in Internet routing itself; rather it is used to determine the intended address within the addressing structure of the destination network. The method by which the local part of an IP address is translated to a local network address depends on the architecture of the destination network static tables, simple conversions, or special purpose protocols are used as appropriate.
The original Internet addresses comprised 32 bits, the first eight bits providing the network part and the remaining 24 bits the local part. These addresses were used for a number of years. However, in June 1978, in IEN 46 A proposal for addressing and routing in the internet, Clark and Cohen observed:
The current internet header has space to name 256 networks. The assumption at least for the time being, is that any network entering the internet will be assigned one of these numbers. While it is not likely that a great number of large nets, such as the ARPANET, will join the internet, the trend toward local area networking suggests that a very large number of small networks can be expected in the internet in the not too distant future. We should thus begin to prepare for the day when there are more than 256 networks participating in the internet.
As predicted, it soon became necessary to adapt the address architecture to allow more networks to be connected. By the time the Internet Protocol itself was comprehensively specified (in RFC 790, published in 1981, edited by Jon Postel), the IP address could be segmented in a number of ways to provide three classes of network address.
In class A, the high order bit is zero, the next seven bits are the network, and the last 24 bits are the local address. In class B, the high order two bits are one-zero, the next 14 bits are the network, and the last 16 bits are the local address. In class C, the high order three bits are one-one-zero, the next 21 bits are the network and the last eight bits are the local address.
This so-called “classful” architecture served the Internet for the next 12 years, during which time it grew from a small US-based research network to a global academic network showing the first signs of commercial development.
Early registration models
In the 1980s, the American National Science Foundation’s (NSF’s) high-speed network, NSFNET, was connected to the ARPANET, a US Department of Defense Advanced Research Projects Agency (ARPA, now DARPA) wide-area network, which essentially formed the infrastructure that we now know as the Internet.
From these early days of the Internet, the task of assigning addresses was a necessary administrative duty, to ensure simply that no two networks would attempt to use the same network address in the Internet. At first, the elementary task of maintaining a list of assigned network addresses was carried out voluntarily by Jon Postel, using (according to legend) a paper notebook.
As the Internet grew, and particularly as classful addressing was established, the administrative task grew accordingly. The Internet Assigned Numbers Authority (IANA) was established, and within it the Internet Registry (IR). But as the task of the IR outgrew Dr Postel’s notebook, it was passed to SRI International in Menlo Park, California, under a NSF contract, and was called the Defense Data Network (DDN) Network Information Center (NIC).
During this time, under the classful address architecture, networks were allocated liberally and to any organization that fulfilled the simple request requirements. However, with the accelerating growth of the Internet during the late 1980s, two problems loomed: the rapid depletion of address space, due to the crude classful divisions; and the uncontrolled growth of the Internet routing table, due to unaggregated routing information.
Conservation vs. Aggregation
The problems of three sizes fit all highlight the basic dilemma of address space assignment: conservation versus aggregation. On the one hand, one wants to conserve the address space by assigning as little as possible; on the other hand, one wants to ease routing table pressures by aggregating as many addresses as possible in one routing table entry.
This can be illustrated by looking at a typical networking set-up of the time. Within organizations having a single Internet connection, buildings, departments, or campuses would have their own local networks. Often the use of multiple networks was dictated by distance limitations inherent in the emerging local area networking technologies, such as Ethernet.
These networks typically had to accommodate more than the 254 hosts addressable by a class C address, but would rarely exceed 1,000 hosts. Using pure classful addressing one could either subdivide networks artificially to remain below the 254 host limit, or use a class B address for each local network, possibly wasting more than 60,000 addresses in each. While the latter solution is obviously wasteful in terms of address space, the former is obviously cumbersome. Less obviously, the former also puts an additional burden on the Internet routing system, as each of these networks would require a separate route propagated throughout the whole Internet.
This basic dilemma persists to this day. Assigning address space generously tends to reduce the routing table size but wastes address space. Assigning conservatively will waste less, but it causes more stress for the routing system.
In order to address some of the problems of classful addressing, the technique of subnetting was invented. Described in RFC 791 in 1984, subnetting provided another level of addressing hierarchy by inserting a subnet part into the IP address between the network and local parts. Global routing remained the same using the network part of the address (class A, B, or C) until traffic reached a router on the network identified by the network part of the address. This router, configured for subnetting, would interpret a statically configured number of bits from the local part of the address (the subnet part) to route the packet further along a set of similarly configured routers. Once the packet reached a router connected to the destination subnet, the remaining bits of the local part would be used to determine the destinations local address as usual. So, in the previous example, the organization could have used a class B address with 6-bit subnetting, which would allow for 62 networks of 1,022 hosts each.
Subnetting nicely solved the routing table problem, since now only one global routing table entry was needed for the organization. It also helped address space conservation somewhat because it provided an obvious alternative to using many sparsely populated class B networks.
Since the boundary between the subnet part and the local part of an address could not be determined from the address itself, this local knowledge needed to be configured into the routers. At first, this was done by static configuration. Later, interior routing protocols carried that information. RFC 791 may be referred to for a number of historically interesting case studies.
Within seven years, however, it was becoming clear that subnetting was no longer sufficient to keep up with Internet growth. RFC 1338 stated the problem:
As the Internet has evolved and grown … in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include:
Exhaustion of the class-B network address space. One fundamental cause of this problem is the lack of a network class of a size which is appropriate for mid-sized organization; class-C, with a maximum of 254 host addresses, is too small while class-B, which allows up to 65534 addresses, is to large to be widely allocated.
Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage.
Eventual exhaustion of the 32-bit IP address space.
It has become clear that the first two of these problems are likely to become critical within the next one to three years.
The solution proposed was to extend the subnetting technique beyond the local organization into the Internet itself. In other words, RFC 1338 proposed abolishing classful addressing, replacing it with supernetting. The proposal was summarized as follows:
The proposed solution is to hierarchically allocate future IP address assignment, by delegating control of segments of the IP address space to the various network service providers.
In 1993, the supernetting technique was published as a standards track RFC under the name Classless Inter-Domain Routing (CIDR), by which it is known and used today. Two main ingredients were necessary to make CIDR work: routing system changes and new address allocation and assignment procedures.
Under CIDR, routers could no longer determine the network part of an address from the address itself. This information now needed to be conveyed by Internet routing protocols. Fortunately, there was only one such protocol in widespread use at the time, and it was quickly extended by the major router vendor of the time. According to legend, the necessary extensions of BGP-3 to BGP-4 were designed on a napkin, with all implementors of significant routing software present. The changes were implemented in a matter of days, but only much later described by the Internet standards track RFC 1654.
CIDR also required that forwarding decisions of routers be changed slightly. The network part of an address, now more generally called the prefix, can be of any length. This means that a router can have multiple valid routes covering a specific 32-bit destination address. Routers need to use the most specific of these routes the longest prefix when forwarding packets.
In additional to technical changes, the success of CIDR also relied on the development of administrative procedures to allocate and assign address space in such a way that routes could be aggregated as much as possible. Since the Internet was evolving towards the current state of arbitrarily interconnected networks of Internet Service Providers (ISPs), it was obvious that ISPs should play a role in address space distribution. In the new technique, ISPs would now, as much as possible, assign address space to their customers in contiguous blocks, which could be aggregated into single routes to the rest of the Internet.
Emergence of the RIRs
While the engineering-driven need for topological address space assignment was becoming clear, there was also an emerging recognition that the administrative mechanisms of address space distribution needed further development. A central system just would not scale for a number of reasons, including:
- Sheer volume
- Distance from the address space consumers
- Lack of an appropriate global funding structure
- Lack of local community support
The need to change administrative procedures was formally recognized by August 1990, when the Internet Activities Board published a message it had sent to the US Federal Networking Council stating it is timely to consider further delegation of assignment and registration authority on an international basis (RFC 1174).
The increasing cultural diversity of the Internet also posed administrative challenges for the central IR. In October 1992, the Internet Engineering Task Force (IETF) published RFC 1366, which described the growth of the Internet and its increasing globalization and set out the basis for an evolution of the registry process, based on a regionally distributed registry model. This document stressed the need for a single registry to exist in each geographical region of the world (which would be of continental dimensions). Registries would be unbiased and widely recognized by network providers and subscribers within their region. Each registry would be charged with allocating remaining address space in a manner compatible with potential address aggregation techniques (or CIDR)
The RIR system
Goals of RIRs
RFC 2050, published in November 1996, represented a collaboration of the global Internet addressing community to describe a set of goals and guidelines for the RIRs. While IANA was to retain ultimate responsibility for the entire address pool, RFC 2050 recognizes that RIRs operate under the consensus of their respective regional Internet community. This document, along with a history of RIR coordination, has helped to form the basis for a set of consistent global policies.
The three primary goals of the RIR system are:
- Conservation: To ensure efficient use of a finite resource and to avoid service instabilities due to market distortions (such as stockpiling or other forms of manipulation).
- Aggregation (routability): To assist in maintenance of Internet routing tables at a manageable size, by supporting CIDR techniques to ensure continued operational stability of the Internet.
- Registration: To provide a public registry documenting address space allocations and assignments, necessary to ensure uniqueness and provide information for Internet trouble shooting at all levels.
The open policy framework
It was always recognized that these goals would often be in conflict with each other and with the interests of individuals and organizations. It was also recognized that legitimate regional interests could justify varying approaches in balancing these conflicts. Therefore, within the global framework, each regional community has always developed its own specific policies and procedures.
However, while the specific approaches may differ across the RIRs, all operate on a basic principle of open, transparent, consensus-based decision-making, following self-regulatory practices that exist elsewhere in the Internet and other industries. Furthermore, the RIRs all maintain not-for-profit cost recovery systems and organizational structures that seek to be inclusive of all interested stakeholders.
The activities and services of each of the RIRs are defined, performed, discussed, and evaluated in open forums, whose participants are ultimately responsible for decision-making. To facilitate broad participation, open policy meetings are hosted by RIRs regularly in each of the regions. Ongoing discussions are carried out on the public mailing lists of each RIR, which are open to both the RIR constituents and the broader community. The RIRs also participate actively in other Internet conferences and organizations and, importantly, each RIR has a strong tradition of participating in the public activities of the others.
A current example of the coordinated efforts of the RIRs is the Provisional IPv6 Assignment and Allocation Policy Document, a joint effort of the RIRs (with the assistance of the IETF, IAB, and IESG) to describe the allocation and assignment policies for the first release of IPv6 address numbers.
Also, the RIRs recently published the RIR Comparative Policy Overview.
These documents help illustrate that the RIRs well-established combination of bottom-up decision making and global cooperation has created a stable, robust environment for Internet address management.
The primary function of each RIR is to ensure the fair distribution and responsible management of IP addresses and the related numeric resources that are required for the stable and reliable operation of the Internet. In particular, the resources allocated, assigned, and registered by RIRs are Internet address numbers (IPv4 and IPv6) and Autonomous System Numbers. RIRs are also responsible for maintaining the reverse delegation registrations of the parent blocks within their respective ranges.
Complementing their registry function, the RIRs have an important role in educating and informing their communities. The activities carried out by the individual RIRs vary, but include open policy meetings, training courses, seminars, outreach activities, statistical reporting, and research.
Additionally, a crucial role for the RIRs is to represent the interests of their communities, by participating in global forums and providing support to other organizations involved in Internet addressing issues.
RIRs and the global Internet community
Formation of ICANN and the ASO
The global Internet governance landscape began to undergo radical changes in mid 1998 with the publication of a United States government white paper outlining the formation of a “not-for-profit corporation formed by private sector Internet stakeholders to administer policy for the Internet name and address system”. The Internet Corporation for Assigned Names and Numbers (ICANN) was formed later that year.
At the heart of the ICANN structure are “supporting organizations” which are formed to “assist, review and develop recommendations on Internet policy and structure” within specialized areas. In October 1999, the existing RIRs and ICANN jointly signed a memorandum of understanding to establish the principles for forming and operating the Address Supporting Organization (ASO). It is intended that new RIRs will sign the MoU as they emerge.
Under the ASO MoU, the policy forums within each of the RIR regions continue to be responsible for the development of regional IP address policy. In addition, each signatory RIR is responsible for electing three members to the ICANN Address Council.
The purpose of the Address Council, as described in the MoU, is to review and develop recommendations on issues related to IP address space, using the open processes that exist in the three regions; and to advise the ICANN Board on these matters. In addition, the Address Council is responsible for the appointment of three ICANN Directors to the ICANN Board.
Since the formation of the ASO, the RIRs have played an integral part in facilitating its activities. By joint agreement, the RIRs will share the ASO secretariat duties, including the hosting of the ASO web site, on a revolving basis. APNIC provided these services in the ASOs first year of operation, and RIPE NCC is currently performing this role.
The ASO Address Council holds monthly telephone conferences, which are attended by representatives of the RIRs (and emerging RIRs on a listener basis). In accordance with the MoU, the ASO also holds regular open meetings in conjunction with the open policy meetings of the RIRs.
RIRs and industry development
As noted previously, the RIRs maintain high levels of participation in the conferences and activities of other organizations. Similarly, they invite the participation of interested parties in their own activities.
The RIRs are active in many areas of new technology implementation (such as GPRS and UMTS mobile telephony, IPv6, and cable and xDSL-based Internet services). The established regional processes have proved both flexible and open enough to incorporate such new developments into policy formation. Industry representatives frequently join policy discussions, present at plenary sessions, and participate in working groups.
The RIRs pursue relationships with industry bodies, particularly those with representative and developmental functions, to facilitate industry convergence on open standards and policy processes.
Many diverse parties have legitimate interests in the allocation and registration of IP addresses, and the RIRs remain committed to participating with these parties to achieve a consensus among the Internet community on IP address allocation issues.
The future of RIRs
In Internet time, it can be easy to forget that eight years is actually not long. Since it was first proposed in 1990, the RIR system has evolved rapidly, enjoyed strong community support, and has been relatively free of the political wrangling that has characterized the registration systems of other Internet resources. Without doubt, this position is largely due to the early determination to provide accessible, open forums for the interested stakeholders in the various regions.
New technologies, such as GPRS, broadband services, and IPv6 may raise operational and policy challenges to the RIRs, yet at the same time they bring opportunities for increased global cooperation, in a context where distinct regional concerns are represented more effectively than ever before.
It is hoped that the emergence of new RIRs will only serve to expand and enhance the inclusive nature of RIR activities.
- [IEN 46] Clark, D., and Cohen, D., A Proposal for Addressing and Routing in the Internet, June 1978.
- [RFC 790] Postel, J., Assigned Numbers, September 1981.
- [RFC 791] Information Sciences Institute, Internet Protocol, DARPA Internet Program, Protocol Specification, September 1981.
- [RFC 1174] Cerf, V., IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet “Connected” Status, August 1990.
- [RFC 1261] Williamson, S., and Nobile, L., Transition of NIC Services, September 1991.
- [RFC 1338] Fuller, V., Li, T., and Yu, J., Varadhan, K., Supernetting: An Address Assignment and Aggregation Strategy, June 1992.
- [RFC 1366] Gerich, E., Guidelines for Management of IP Address Space, October 1992.
- [RFC 1466] Gerich, E., Guidelines for Management of IP Address Space, May 1993.
- [RFC 1654] Rekhter, Y., and Li, T., A Border Gateway Protocol 4 (BGP-4), July 1994.
- [RFC 2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and Postel, J., Internet Registry IP Guidelines, November 1996.
- [RIPE-19] Blokzijl, R., Devillers, Y., Karrenberg, D., and Volk, R., RIPE Network Coordination Center, September 1990.
- [RIPE-65] Terpstra, M., RIPE NCC Internet Numbers Registration Procedures, July 1992.