Summary
- Internet Protocol addressing did not begin with five territorial divisions. Geographic administration emerged from 1990 onward as a response to international growth, language and service needs, registry workload, address conservation, and the attempt to make contiguous allocations compatible with routing aggregation.
- RFC 1174 recommended international delegation while retaining central IANA and Internet Registry functions; RFC 1466 proposed four major allocation areas but also preserved multi-regional space, three
Othersranges, direct central service, and a default registry for uncovered areas. - The present five-region map hardened through separate operational starts, address-block delegations, corporate incorporations, bilateral transitions, ICANN recognition decisions, and ASO and NRO instruments. Those milestones did not occur at the same time and should not be projected backwards.
- Administrative service region, recipient domicile, network operation, BGP origin, registry incorporation, and governing law need not coincide. The examined records establish separability and institutional boundary changes, not the frequency of multidimensional mismatch; the unresolved question is whether exclusive service boundaries were optimal, contestable, or representative.
9 December 2002: forty-three candidate networks enter pre-transfer review
On 9 December 2002, four Regional Internet Registries began pre-transfer work on a test population of 43 candidate networks inside 129.0.0.0/8. The records had originated in early registration arrangements later inherited by the American Registry for Internet Numbers, while the resource holders were considered candidates for service by the RIPE Network Coordination Centre.
The published Early Registration Transfer project procedure separated several stages. Pre-transfer preparation began on 9 December. Contact notices were planned for 11 December. Database transfer was scheduled for 10 January 2003, with conflict resolution able to continue afterward. The announcement was prospective, so it establishes neither final completion of all 43 candidates nor a completed movement in December 2002.
That distinction reveals what an administrative boundary change involved. Some candidate records existed only in ARIN’s database. Others appeared in both ARIN and RIPE records with different contacts or descriptions, while another group appeared only in the RIPE registry. Many apparent conflicts could reflect stale data rather than competing claims or attempted hijacking. The process therefore called for contact reconciliation, transfer of supporting documents, database work, and changes to reverse-DNS delegation.
The containing /8 remained an “ARIN majority” block. The project addressed individual registrations rather than reclassifying the whole range as European. This was a retrospective correction problem: globally unique numbers had been registered before the later regional system supplied a settled administrative destination for them.
The ERX announcement documents record custody and service responsibility. It contains no historical BGP-origin series, equipment inventory, complete recipient-domicile table, or governing service agreements for the candidate networks. Those dimensions remain unknown at the case level. What the record establishes is narrower and still important: an inherited registration could enter a formal process for reassignment to another regional registry without renumbering the network.
Administrative correction had operational consequences. Registry contacts, maintenance authority, reverse delegation, documentation, and future requests all depended on the responsible institution. Yet the scheduled database transfer was distinct from physical deployment and route propagation. A registry record could move while the associated equipment and routing arrangements remained as they were.
ERX thus captures the regional system in maturity. In 1989, no five-registry map existed against which a legacy record could be judged misplaced. By 2002, the regional division was established enough for four registries to treat historical placement as a correctable anomaly. Geography had become both prospective, guiding new delegation, and retrospective, reorganising records created before the map.
The protocol had addresses before administration had continents
The Internet Protocol supplied a common addressing architecture before number administration acquired regional service boundaries. RFC 791, published in September 1981, defined 32-bit source and destination addresses in the Internet header. Its classful formats divided bits between network and local portions. They contained no field for Europe, North America, Africa, Latin America, or the Asia-Pacific.
Routers used addresses to make reachability decisions based on network topology. Administrative geography entered elsewhere: in the institutions that assigned identifiers, recorded recipients, processed requests, maintained reverse delegation, and coordinated uniqueness.
Uniqueness required a common system. Two unrelated networks using the same globally visible number would leave hosts and gateways unable to determine consistently which network was intended. Assigned-number publications recorded common values, while coordinating organisations allocated network numbers and autonomous system numbers and maintained registration information.
By August 1990, RFC 1174 described two central functions. The Internet Assigned Numbers Authority function was performed by the University of Southern California’s Information Sciences Institute. The Internet Registry function was performed by SRI International at the DDN Network Information Center. IANA allocated identifiers and could delegate responsibility; the Internet Registry gathered and maintained registration information.
Institutional location and resource location were already different concepts. A United States organisation could maintain a global record for networks operating elsewhere. A contact could administer a network spanning several countries. A recipient could change carriers or deploy in a new location without changing its corporate domicile. Routing information could pass through providers organised under different legal systems.
Registration nevertheless mattered. It connected an identifier to an organisation, an administrative contact, and a record-maintenance process. It supported uniqueness, troubleshooting, reverse delegation, and accountability. Those functions made the registry consequential without turning it into a map of equipment sites or route origins.
The network’s rapid international growth made a regional layer attractive. Applicants worked in different time zones and languages and operated amid different telecommunications customs. Service providers needed blocks from which they could make customer assignments. At the same time, the routing system faced pressure from an expanding number of separately advertised networks.
Geography offered one way to organise service and address inventory. The packet header did not require that answer. It emerged from recommendations, block plans, operating institutions, and later recognition rules.
RFC 1174 proposed distribution while retaining a centre
RFC 1174 was an Informational RFC published in August 1990. It recorded the official view of the Internet Activities Board rather than an Internet standard. Its recommendations were addressed to the United States Federal Networking Council through the sponsor and technical-governance arrangements of the period.
The first recommendation proposed distributing responsibility for assigning network and autonomous system numbers. The document cited rapid network growth, internationalisation, and increasing scarcity, especially among Class A and Class B identifiers. The proposal anticipated a larger and more varied Internet than a single registry desk had originally served.
Distribution came with retained central functions. The Internet Registry would remain the principal registry for network and autonomous system numbers. It would allocate blocks to approved organisations, maintain aggregate registration information, and serve as the default registry where no delegated authority had been identified. Authoritative updates would continue to converge at the Internet Registry, with complete copies redistributed to delegated registries.
The Coordinating Committee for Intercontinental Research Networking was expected to approve organisations capable of receiving blocks and further assignment authority. Candidate registries were to meet with IANA and the Internet Registry and document their operating procedures. Delegation therefore depended on institutional eligibility, coordination, and a defined process rather than location alone.
This architecture contained a practical balance. Local or regional organisations could process assignments closer to applicants, while the central registry preserved a common view of the number space. The default route kept service available to networks outside a delegated area. Replication allowed distributed access without abandoning authoritative coordination.
The document stopped well short of the later five-region arrangement. It drew no permanent continental boundaries and named none of the organisations that would become ARIN, LACNIC, or AFRINIC. A recommendation for distribution was not itself an operational registry, a block delegation, or a recognition decision.
RFC 1174 also treated registration and connectivity separately. Its connected-status attachment recommended removing a simple “connected” status from registration records and recording acceptable-use and transit policies instead. For non-United States networks, United States access criteria were relevant only where traffic used federally sponsored networks. Registration alone supplied no assurance that a network was routed, publicly reachable, or permitted to use a particular transit path.
Regional registries inherited that boundary. They could allocate resources, maintain records, arrange reverse delegation, and evaluate requests. Transit providers and network operators controlled whether and how a prefix appeared in routing. The service region described an administrative relationship, while connectivity arose through separate technical and commercial arrangements.
Implementation followed through particular communities. European network operators began meeting through RIPE in 1989, but a coordination community was not yet a functioning registry. The RIPE NCC’s later establishment, delegation, referral arrangements, incorporation, and operational independence each supplied a different part of the regional structure.
RFC 1466 drew a qualified geographic plan
By May 1993, RFC 1466 offered a more explicit geographic design. The Informational RFC, authored by Elise Gerich of Merit Network, obsoleted RFC 1366 and was later obsoleted by RFC 2050. It reported review by the Federal Engineering Planning Group on behalf of the Federal Networking Council, the co-chairs of the Intercontinental Engineering Planning Group, and RIPE, with general consensus among those groups.
RFC 1466 connected regional service to the changing Internet population. Registries operating in distinct geographic areas could respond to local languages and customs. A candidate regional registry was expected to have recognition among network providers and subscribers, standing beyond its registry function, and resources sufficient for stable, timely, and reliable service. It also had to follow IANA and Internet Registry guidelines and coordinate sub-allocation practices.
These were stated rationales and design expectations, rather than measured comparisons between a central system and regional treatment groups. They identified plausible service mechanisms: overlapping working hours, local documentation, familiarity with provider markets, training relationships, and closer contact with downstream registries.
RFC 1466 preferred a single regional registry at that level for efficient and fair sub-allocation. The preference did not create an exhaustive territorial gate. Applicants could still approach the Internet Registry directly. They might be referred to an appropriate regional registry, but the central registry remained prepared to serve a network subscriber when necessary. Areas without a designated regional registry continued to use the default registry.
The address plan contained similar qualifications. RFC 1466 divided 192.0.0.0 through 207.255.255.255 into eight equal /7 ranges. Each /7 comprised 131,072 former Class C /24 network-number units, equivalent to 33,554,432 individual IPv4 addresses. The exact four areas named in the document were Europe, North America, Pacific Rim, and South & Central America.
| Designation in RFC 1466 | Address range | Size |
|---|---|---|
| Multi-regional | 192.0.0.0–193.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| Europe | 194.0.0.0–195.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| Others | 196.0.0.0–197.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| North America | 198.0.0.0–199.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| South & Central America | 200.0.0.0–201.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| Pacific Rim | 202.0.0.0–203.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| Others | 204.0.0.0–205.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
| Others | 206.0.0.0–207.255.255.255 |
One /7: 131,072 /24 units, or 33,554,432 IPv4 addresses |
This was not the modern five-RIR map. Africa had no separate allocation area. Neither the Middle East nor Central Asia appeared as an independent category. Three ranges were labelled Others, while Multi-regional covered earlier assignments. The plan made room for inherited records and regions without a designated registry.
The geographic division also applied unevenly across the address inventory. RFC 1466 retained central control over Class A space and imposed separate restrictions on Class B treatment. Its regional plan focused principally on the former Class C inventory, where contiguous blocks could support more systematic downstream assignment.
Routing aggregation supplied a major technical rationale. A provider receiving a contiguous block could assign compatible sub-blocks to customers and, where topology permitted, advertise one aggregate rather than many individual routes. Fewer entries in default-free routing tables would improve scaling.
Allocation created the possibility of aggregation; operational routing determined the result. Providers needed BGP-4 and classless routing, and customer placement had to align with the aggregate. Multihoming, topology changes, and traffic engineering could require more-specific announcements. A geographically reserved range therefore carried aggregation potential rather than an automatic routing outcome.
The contemporaneous RFC 1467, published in August 1993, reported that RIPE NCC had requested regional-registry status and received 194.0.0.0–195.255.255.255 for the European Internet community. RIPE NCC also administered 193.0.0.0/8, obtained before the geographic plan. The Internet Registry continued to serve regions lacking a designated registry.
RFC 1467 described service providers receiving blocks for customer assignments and reported that moving processing closer to end users had operated without major problems. That statement is useful period testimony from within the system. It supplies neither a complete request dataset nor an independent comparison of regional and central service.
The same report recorded a delay in the scheduled general availability of an aggregation mechanism. Registries were assigning aggregation-compatible blocks before the routing system could consistently realise the intended reduction. Geographic planning, provider allocation, and routing-protocol deployment were connected parts of the scaling strategy, each with its own timetable.
RFC 2050 recorded the three-registry period
RFC 2050 replaced RFC 1466 in November 1996. It was published as Best Current Practice 12, or BCP 12. Its institutional description must be read in that period rather than through the later five-RIR map.
At publication, RFC 2050 named three Regional Internet Registries: InterNIC for North America, RIPE NCC for Europe, and APNIC for the Asia-Pacific. It also described service extending into areas surrounding those core regions. ARIN, which began operating in December 1997, should not be substituted retrospectively for InterNIC in the RFC’s November 1996 account.
The RFC identified conservation, routability, and registration as the goals of address distribution. Conservation addressed finite address space. Routability favoured hierarchical distribution compatible with aggregation. Registration maintained a public record for uniqueness and troubleshooting. These goals overlapped but were not identical.
RFC 2050 also preserved flexibility outside a designated service area. An ISP located in a region without a regional registry could contact any regional registry. This provision is further evidence that the period system had not yet become an exhaustive set of exclusive continental gates.
An allocation or assignment supplied no guarantee of routability. Providers still decided which routes to accept and propagate. Hierarchical allocation could support aggregation, but routing policy and topology governed visibility.
RFC 2050 is now Historic and was superseded by RFC 7020. Its current status does not erase its historical value. It records how address administration described itself in November 1996: three regional institutions, incomplete geographic closure, a parent-registry hierarchy, and an operational distinction between registration and routing.
The appeal structure reinforced that hierarchy. Each registry was expected to document an appeal process. An organisation dissatisfied with an assigning registry could appeal to its parent registry and ultimately to IANA after exhausting other avenues. This supplied a route for reviewing assignment decisions, though it does not establish a general right to choose another RIR or redraw a regional boundary.
The five institutions acquired authority through different dates
The five-region system emerged through a sequence in which community formation, delegated service, referral, block delegation, incorporation, operational handover, recognition, and joinder remained separate.
| Date | Event | What the date establishes |
|---|---|---|
| 1989 | European network operators began RIPE meetings | A regional coordination community existed. |
| April 1992 | RIPE NCC was formally established in Amsterdam | A staffed coordination centre had been created. |
| 1 May 1992 | RIPE NCC was acting as a delegated registry | Delegated registry service had begun. |
| 1 August 1992 | The Internet Registry began forwarding all European applications to RIPE NCC | European referral became systematic. |
| September 1993 | The APNIC pilot began operating from Tokyo | A regional Asia-Pacific service experiment was active. |
| 10 January 1994 | Historical delegation records date APNIC’s receipt of the equivalent 202/7 block |
APNIC had regional address inventory to administer. |
| April 1994 | APNIC’s retrospective history places public recognition of its status in this month | The recognition account is distinct from the January delegation record. |
| 1996 | APNIC Ltd was incorporated in Seychelles | A Seychelles entity supplied part of APNIC’s institutional structure. |
| 18 April 1997 | ARIN’s original Virginia articles of incorporation were executed | The dated articles existed; they alone do not establish the state filing or effective legal-formation date. |
| 12 November 1997 | RIPE NCC’s Dutch association documents were deposited | Incorporation documentation was completed before operational takeover. |
| December 1997 | ARIN began operating as an independent registry | North American registration service separated operationally from InterNIC. |
| 1 January 1998 | The new RIPE NCC association took over the activities | Independent institutional operation followed incorporation. |
| August 1998 | APNIC completed its operational relocation to Brisbane through the later Australian company structure | Service operations moved from Japan to Australia without collapsing APNIC Ltd and APNIC Pty Ltd into one entity. |
| 23 August 1999 | Representatives of six regional organisations signed LACNIC’s founding agreement | A Latin American and Caribbean institution had been constituted before recognition. |
| 18 October 1999 | The first ICANN–RIR ASO MoU was executed | APNIC, ARIN, and RIPE NCC entered a formal policy-advisory relationship with ICANN. |
| 4 June 2001 | ICANN accepted ICP-2 | Criteria for recognising new RIRs were adopted. |
| July and October 2001 | ARIN and LACNIC agreed transition details and then the service area | A bilateral boundary and service transition took shape before approval. |
| November 2001 | LACNIC staff joined analysis of relevant ARIN applications | Operational preparation preceded direct service. |
| 14 March 2002 | LACNIC received provisional approval | Provisional recognition preceded its service start and final recognition. |
| 30 July 2002 | LACNIC began direct registration service under ARIN supervision | Operational responsibility began in supervised form. |
| 30 October 2002 | LACNIC signed its ASO joinder | Joinder was executed before becoming effective. |
| 31 October 2002 | The LACNIC ASO joinder became effective and ICANN granted final recognition | Coordination membership and recognition aligned on this date without becoming the same legal act. |
| 11 November 2002 | ARIN and LACNIC signed transfer instruments | The instruments preceded effective transfer. |
| 18 November 2002 | The ARIN–LACNIC transfer of authority took effect | The negotiated service handover became effective. |
| 24 October 2003 | APNIC, ARIN, LACNIC, and RIPE NCC executed the NRO MoU | Four RIRs created a collective coordination mechanism. |
| 2004 | AFRINIC incorporated in Mauritius | The prospective African registry obtained an institutional home before service transfer and final recognition. |
| 30 September 2004 | ICANN provisionally recognised AFRINIC | Provisional recognition preceded operational handover. |
| 21 October 2004 | ICANN and the NRO executed a new ASO MoU | The NRO assumed the ASO role and the agreement addressed service-region definition. |
| 21 February 2005 | APNIC, ARIN, and RIPE NCC transferred African-region services to AFRINIC | AFRINIC became operationally responsible across its service region. |
| 8 April 2005 | ICANN granted final recognition to AFRINIC | The fifth RIR received final institutional recognition. |
| 25 April 2005 | AFRINIC and the NRO executed the relevant membership instrument | The dated instrument formalised the relationship. |
| 27 April 2005 | ASO history records AFRINIC becoming the fifth NRO member | Recorded membership followed the instrument date. |
The RIPE NCC sequence shows why one anniversary cannot carry the whole institutional history. RIPE meetings supplied a community in 1989. Formal establishment followed in April 1992. Delegated-registry activity is documented from 1 May, and the Internet Registry’s forwarding of all European applications began on 1 August. The Dutch association documents were deposited on 12 November 1997, while the association took over activities on 1 January 1998.
APNIC’s history is equally layered. Its Tokyo pilot began in September 1993 and ended with 27 members across 12 economies. The equivalent 202/7 delegation is dated 10 January 1994, while a retrospective institutional history describes public recognition in April. Both records can be retained because they refer to different documentary stages.
The corporate history requires particular care. APNIC Ltd in Seychelles, incorporated in 1996, was distinct from APNIC Pty Ltd in Australia. The 1998 annual report records the later Australian structure and completion of the Brisbane operational relocation in August 1998. The evidence examined here supports that separation and the service handover, but it does not justify assigning every earlier agreement or member-service obligation to an entity where the relevant instrument has not been supplied.
ARIN’s original articles carry the date 18 April 1997 and were amended in June and August. The dated document proves execution of the articles, while a state filing or effective record would be needed to establish the precise legal-formation date. ARIN’s institutional history places its independent operating establishment in December 1997. The articles archive and the operating history therefore answer different questions.
LACNIC’s chronology is unusually detailed. Its 2002 annual report describes the July and October 2001 transition agreements and LACNIC participation in relevant ARIN application analysis from November. Provisional approval on 14 March 2002 came before direct service on 30 July. The ASO joinder was signed on 30 October and effective on 31 October, the day of final recognition. Transfer instruments followed on 11 November and became effective on 18 November.
AFRINIC similarly separated institutional formation from regional operation. Incorporation in Mauritius, provisional recognition on 30 September 2004, service transfer on 21 February 2005, final recognition on 8 April, the 25 April NRO instrument, and membership recorded on 27 April were related milestones rather than interchangeable labels.
The first ASO chronology contains a smaller documentary discrepancy worth preserving. The 1999 MoU states that it was executed on 18 October, while a later ASO history places formal establishment on 19 October. The instrument date and retrospective anniversary can coexist as different claims.
Taken together, the milestones explain how administrative geography became durable. Communities organised; staff processed requests; address blocks were delegated; referrals became routine; corporations assumed responsibilities; incumbent registries negotiated handovers; ICANN recognised new registries; and ASO or NRO instruments connected them to global coordination. No single event performed all these functions.
Evidence for service capacity and routing mechanisms
Regionalisation was justified partly as a service response. The available evidence supports capacity indicators and specific mechanisms, while leaving comparative performance unresolved.
A May 1992 RIPE document reported more than 60 participating organisations and more than 170,000 reachable computers in Europe. These were period institutional and host-reachability counts, not numbers of applicants, allocations, users, or independently verified service outcomes. They nevertheless show the scale of the coordination environment around the new centre.
RIPE participants had documented European address use before the NCC began distributing space. From May 1992 it acted as a delegated registry, and from August all European applications were forwarded to it. The sequence demonstrates an operating regional intake backed by an established technical community.
APNIC’s 1998 annual report supplies a different measure. It self-reported a current response time of two working days for requests. The figure was not a target and did not describe a response-time distribution, approval quality, or a comparison with earlier central service. It records the institution’s stated current service level at that time.
The same report described translated materials, member documentation, training, and efforts to make request handling more predictable. These activities corresponded to the rationales expressed in RFC 1466: communication across languages, staff knowledge, and closer relationships with regional operators. National Internet Registries and other sub-regional arrangements added local interfaces inside the wider Asia-Pacific service area.
Routing evidence provides a firmer account of mechanism. In January 1992, the default-free or NSFNET routing-table context described by RFC 1519 contained about 4,700 routes. The 1988–1991 historical series had roughly doubled every ten months. By December 1992, the table value was 8,561, reasonably described as about 8,500 routes.
Contiguous power-of-two allocations allowed several customer networks to be represented by one aggregate prefix where provider topology aligned. RFC 1519 made compatible classless interdomain routing a condition of obtaining that benefit. Address planning alone could organise the inventory without changing the number of advertised routes.
A later review in RFC 4632, using observations through March 2005, associated a sharp 1994 reduction in routing-table entries with provider deployment of BGP-4 and aggregation of CIDR supernet blocks. Growth then became roughly linear from mid-1994 to early 1999 before accelerating again as multihoming and traffic engineering produced more-specific routes.
That history supports a chain of contribution rather than a single geographic treatment effect. Regional and provider-oriented delegation helped produce aggregatable blocks. BGP-4 and provider practice converted some of those blocks into aggregate announcements. Later operational requirements limited the reduction.
RFC 1467’s report that downstream processing closer to end users operated without major problems is contemporaneous institutional testimony. It provides evidence of functioning distributed capacity. The source supplies no before-and-after population, central-registry baseline, comparable control group, or complete outcome distribution. Accordingly, it cannot measure how much geography itself changed response times or central workload.
The strongest supported finding concerns institutional capability. Regional registries developed staff, intake processes, training, documentation, address pools, and downstream relationships. The records articulate reasons why those features might improve service. A causal estimate of reduced transaction costs would require request-level observations, dates, outcomes, and a defensible comparison across administrative designs.
Three institutional boundary cases
The surviving cases show administrative boundaries changing independently of some institutional facts. They do not supply complete matrices for individual holders. Treating them as boundary cases preserves what is observable without turning unknown recipient, deployment, routing, or legal facts into evidence.
ERX and inherited custody
The 129.0.0.0/8 test arose because early registrations had accumulated before the later service map. ARIN inherited records from central arrangements, even where candidate networks were associated with the region served by RIPE NCC.
On 9 December 2002, the registries began pre-transfer work for 43 candidates. They planned contact notices for 11 December and database transfer for 10 January 2003. Record conflicts and supporting-document issues could continue afterward. The announcement provides no final count of completed candidates, so the population is a pre-transfer set rather than a verified completion total.
The institutional boundary is visible. ARIN and RIPE NCC were different record custodians with different corporate homes and service processes. A candidate registration could move between them after contact reconciliation and documentary review. The recipient’s domicile, contemporary equipment sites, historical BGP origins, upstream providers, and governing agreements remain unreported in the announcement.
ERX proves administrative corrigibility and path dependence. The candidates entered ARIN’s system through inherited custody, not through a demonstrated 1997 classification of every legacy network as North American. By 2002, that inheritance could be reviewed against the regional service map.
APNIC’s institutional relocation
APNIC’s pilot began in Tokyo in September 1993 and served a membership distributed across 12 economies by the end of the experiment. Its search for a stable legal and operating structure considered organisational independence, taxation, funding, continuity, and a workable corporate home.
The 1998 annual report distinguishes APNIC Ltd in Seychelles from APNIC Pty Ltd in Australia. It records completion of the operational move to Brisbane in August 1998 without interruption to ordinary service. The two corporate entities and the movement of operations must therefore remain separate in the history.
This case establishes institutional separability. The Asia-Pacific service region persisted while the secretariat moved from Japan to Australia and the corporate structure changed. The evidence does not follow a named member’s resources through domicile, physical deployment, BGP origin, and governing contract. Those resource-holder dimensions are unknown rather than proven mismatches.
National Internet Registries added another administrative layer. They could provide national or language-specific interfaces within APNIC’s larger region. Multinational providers presented a different organisational problem. APNIC experimented with confederation arrangements allowing large providers to maintain separate allocation pools, and the institutional history records fee and administrative concerns leading to suspension of new ISP confederations in 1998.
These arrangements show that a continental registry could contain several service scales. They also show why an operator’s commercial topology did not always map neatly onto a single national interface. A direct policy and service record would still be required to establish the arrangement for any particular provider.
Africa’s transition to AFRINIC
Africa initially lacked a single regional registry. By 2001, ICP-2 described service divided between ARIN and RIPE NCC, while APNIC also served part of the region during the later transition. Administrative coverage crossed institutional boundaries before AFRINIC assumed the regional role.
AFRINIC incorporated in Mauritius in 2004. Its historical account places technical operations in South Africa, backup and disaster recovery in Egypt, and training coordination in Ghana. These facts describe the registry’s distributed institutional operations, not the location of every member network.
Provisional recognition arrived on 30 September 2004. On 21 February 2005, APNIC, ARIN, and RIPE NCC transferred African-region services to AFRINIC. ICANN described AFRINIC as fully operational at that stage, while final recognition followed on 8 April. The NRO instrument and recorded membership came later in April.
This transition shows an administrative service boundary being consolidated through institutional agreement. The public record identifies incumbent registries, the new registry, operational functions, recognition stages, and a regional transition. It lacks a holder-by-holder dataset covering notice, response, recipient domicile, deployment, historical route origin, governing service agreement, objection, and disposition.
ICP-2 required a proposed RIR to demonstrate support from a very substantial majority of the region’s ISPs. It also required open policy processes, neutrality, technical competence, financial viability, auditable records, and a transition from incumbent registries. Those were recognition criteria. They are not an independently verified roll of every operator’s position.
The AFRINIC application included a transition plan, bylaws, funding arrangements, and evidence of support. Incumbent RIRs recommended recognition, and ICANN assessed compliance. These records establish a structured institutional process. They leave open the degree to which exclusive service boundaries represented every affected operator or accommodated objections in individual cases.
Across the three cases, the affirmative result is consistent: service responsibility could change through documentary reconciliation, corporate restructuring, or regional transition. Administrative geography selected a usual registry, policy forum, record custodian, and address pool. The evidence does not measure how often other dimensions coincided with or departed from that administrative selection.
Recognition turned practice into a durable boundary system
ICP-2 converted earlier regional practice into a more explicit recognition framework. APNIC, ARIN, and RIPE NCC developed the criteria in response to ICANN. The ASO Address Council recommended them, and the ICANN Board accepted them on 4 June 2001.
The 2004 ASO MoU cites ICP-2 as published by ICANN on 7 July 2001. The current ICANN URL is a later host for the 2001 text, despite the date embedded in its path. Acceptance, cited publication, and later hosting are documentary stages rather than competing versions of the underlying framework.
ICP-2 expected a proposed RIR to cover a large, approximately continental region. It preferred one RIR under one management and in one location per region, citing risks that multiple registries could fragment address space, complicate coordination, and confuse users.
A candidate needed broad ISP support, an open bottom-up policy process, neutrality, technical competence, adherence to conservation and aggregation principles, viable funding, auditable records, and appropriate confidentiality protections. The application also needed a transition plan where incumbent registries already served the region.
The framework strengthened administrative geography in two ways. Continental scale became a recognition criterion, and overlapping regional registries became disfavoured. What had begun as distributed assignment and referral acquired a formal pathway for approving region-wide institutions.
The selection process ran through several constituencies. Existing RIRs drafted the framework. The ASO Address Council recommended it. Applicant communities assembled evidence of support. Incumbent registries negotiated transitions, and ICANN issued provisional or final recognition. LACNIC’s service area emerged through agreement with ARIN; AFRINIC’s transition involved three incumbents and an NRO recommendation.
The instruments examined here concern management of Internet number resources, registration services, coordination, and recognition. They do not purport to make an RIR the government of its service region or to establish a comprehensive property or conflict-of-laws regime. ICP-2’s support test focused on LIRs and ISPs rather than national electorates.
The 2004 ICANN–NRO ASO MoU made the registry system’s cartographic role explicit. It provided that the regions served by each RIR would be defined by the RIRs in a manner of their choosing, while the NRO would ensure coverage of all possible service areas.
That clause placed service-area definition inside the coordinated RIR system. Policy forums, mailing lists, member elections, recognition applications, public-comment processes, and RFC 2050’s appeal hierarchy offered forms of participation and review. The examined records contain no consolidated period catalogue covering operator requests to choose another RIR, remain with an incumbent after transition, or obtain a permanent boundary exception.
The absence of such a catalogue establishes an evidence gap rather than the absence of remedies. A reliable assessment of contestability would require the applicable procedure, dated requests, decisions, and appeal outcomes across registries.
The alternatives geography displaced
Geographic service regions were not the only imaginable design. Function, language, provider choice, and a shared global ledger could each have organised parts of the system differently.
A function-based model would divide responsibilities among specialised bodies. One institution might allocate IPv4 space, another assign autonomous system numbers, another maintain registration data, and another operate reverse delegation or utilisation audits. Early administration already separated IANA allocation from Internet Registry recordkeeping, while providers and local registries handled downstream assignments.
Such specialisation could concentrate expertise. Its principal difficulty would be coordination across dependent functions. An applicant might need addresses, an autonomous system number, reverse DNS, and record authentication from several authorities. Corrections and appeals would require a clear precedence rule, while uniqueness would still depend on a common authoritative view.
Language offered a second organising principle. RFC 1466 expressly cited language as a rationale for regional service. Spanish-speaking operators in Europe and the Americas, Arabic-speaking operators across Africa and the Middle East, or English-speaking operators in several regions might benefit from a service desk built around communication rather than continents.
Linguistic communities overlap, and many operators work in several languages. A language-based registry would need rules for applicants eligible for multiple services and a funding model for smaller language groups. Regional registries instead developed translated documents, training, national interfaces, and local registries inside a larger administrative structure.
A competitive model would allow operators to choose among registries. Competition might reward clearer processes, lower fees, or faster responses. It could also suit networks whose corporate and operational footprints crossed regional boundaries.
Competition would introduce conservation and coordination risks. An applicant refused by one registry might seek more permissive treatment elsewhere. Address pools, reverse delegations, registration records, confidential request files, and audit histories would need reliable portability. ICP-2’s preference for one RIR per region expressly favoured coordination and a legible service default over such institutional competition.
The most substantial alternative was a multi-provider service layer above one authoritative ledger. Applicants could use a national, linguistic, provider-based, or specialist agent. The service agent would validate requests and submit standard transactions to a globally reconciled registry. Operators might then change service agents without renumbering or moving the authoritative record between regional pools.
Several historical designs pointed in that direction. RFC 1174 proposed delegated registries with central aggregate records. RFC 1466 preserved direct Internet Registry service and referrals. RFC 2050 described local registries, provider assignments, regional registries, and parent appeals. ERX demonstrated that registration information and reverse delegation could at least enter a cross-registry transfer process.
The challenge would be precise authority. Multiple agents updating the same record would require strong authentication and deterministic precedence. A central commit authority might leave regional competition largely cosmetic. Portable service would also complicate funding where registries maintained costly public functions for regions whose most profitable members could leave.
Geography prevailed because it supplied a comprehensible operating default linked to address inventory and existing communities. An organisation or network approached the registry serving its region, followed the applicable policy, and received resources from the corresponding pool. National registries and providers could then handle closer relationships.
That legibility carried an institutional tradeoff. Once service areas became exclusive, a network spanning several regions had limited practical choice of administrator. The documentary record explains why administrators preferred the regional model; it does not compare all alternatives through common service, representation, conservation, and routing metrics.
Path dependence made the regional map expensive to replace
By 2005, the regional map rested on more than a set of coloured boundaries. Delegated address blocks connected each registry to a distinct inventory. Providers had built customer plans around sub-allocations. Reverse-DNS zones followed the hierarchy. Registration systems accumulated records, authentication practices, and audit histories.
Human institutions grew around those technical assets. Staff acquired regional and policy expertise. Members paid fees, participated in mailing lists and meetings, and elected boards. Applicants relied on registry contacts and credentials. Each additional interaction made the existing service relationship easier to continue and harder to replace.
Corporate structures added commitments involving employment, taxation, procurement, banking, liability, and contracts. RIPE NCC operated through its Dutch association. ARIN became an independent Virginia-based institution. APNIC’s Seychelles and Australian entities formed separate parts of its corporate transition. LACNIC developed its regional institutional base, while AFRINIC incorporated in Mauritius.
Incorporation identifies the legal home and structure of a registry entity. It cannot, by itself, establish the law governing a particular resource holder, route, allocation, or service agreement. Those questions require the relevant contract and applicable legal rules.
Recognition instruments supplied another layer of continuity. APNIC, ARIN, and RIPE NCC executed the first ASO MoU in October 1999. APNIC, ARIN, LACNIC, and RIPE NCC formed the NRO through the 24 October 2003 MoU. The 2004 ASO MoU placed the NRO in the ASO role, and AFRINIC joined after recognition through its April 2005 instrument and membership.
Referral reinforced the institutions. Once applicants were routinely sent to the registry for their geographic area, that registry accumulated more records, fees, operational knowledge, and policy participation. Those assets increased its capacity to serve the same region, making the boundary appear progressively more natural even though it had been built through earlier administrative choices.
Legacy records became conspicuous under this arrangement. ERX addressed registrations inherited from the central era because their custody no longer matched the established service map. The effort required to reconcile contacts, documentation, database entries, and reverse delegation illustrates the cost of changing administrators after operational dependence had accumulated.
Address inventory contributed its own inertia. RFC 1466 connected certain /7 ranges to geographic areas, while preserving Multi-regional and Others space. Later IANA allocations continued the hierarchical block structure. A prefix could therefore carry an administrative lineage without revealing its current deployment or route origin.
CAIDA’s visual history of IPv4 allocations illustrates flows through changing administrators from 1977 onward. Its aggregated representation is useful for institutional timing. It offers no request-level explanation, complete deployment map, governing-law analysis, or proof of why a particular prefix appeared through a particular route.
Path dependence is compatible with genuine benefit. Concentrated experience may improve a registry’s understanding of its members and policies. The same concentration raises switching costs and narrows institutional choice. The historical record supports both mechanisms without supplying a common metric that determines their optimal balance.
Registration, routing, jurisdiction, and property remain separate
RFC 2050 described registration as a public record supporting uniqueness and troubleshooting. It also used control language suited to the allocation policies of the period. An assignment delegated authority over a block to an end enterprise. Provider-based addresses were described as loans during connectivity, and customers changing providers were encouraged to return them and renumber. Transfers required registry approval.
These provisions governed operational relationships within the address-distribution system. The instruments examined here do not purport to supply a comprehensive property code for every legal system. They also do not determine how courts would classify contractual rights, reliance, possession, or later economic interests in number resources.
A registry’s service boundary indicates which institution ordinarily evaluates requests, maintains records, runs a policy forum, and administers a pool. Jurisdiction over a particular organisation or agreement may depend on incorporation, contract terms, conduct, statutory reach, and conflict-of-laws rules. A regional map alone cannot decide that analysis.
BGP observations answer another question. They associate a route announcement with an origin autonomous system as seen from particular routing collectors and times. Such observations can help reconstruct routing behaviour, but they do not establish every router’s location, ultimate infrastructure ownership, authorisation, recipient domicile, or the appropriate registry.
Allocation and registration data can corroborate part of an operational history. They are not substitutes for archived routing observations, corporate records, deployment evidence, or service agreements. The distinction matters most where an administrative record is treated as proof of a much broader legal or physical conclusion.
Registry administration still has material consequences. Incorrect data can affect reverse DNS, resource certification, abuse contacts, transfer processing, and an operator’s ability to demonstrate administrative control. The disciplined conclusion is therefore substantive rather than dismissive: number registries govern important coordination relationships, and the reach of each relationship must be established from the relevant evidence.
Geography became infrastructure
The five-region map was built, not discovered. Its foundations were plausible service needs, scarce address inventory, routing pressure, delegated administration, and operating communities. Its durable form came from referrals, address pools, corporate institutions, transition agreements, recognition criteria, and accumulated dependence.
That history supports neither a purely technical inevitability nor a merely decorative account. Regional registries became real infrastructure for allocation, registration, policy, reverse delegation, training, and coordination. At the same time, the records examined here leave the optimality and representativeness of exclusive service boundaries unresolved.
The map’s lasting significance lies in that combination. Geography solved an administrative coordination problem well enough to become embedded, then inherited authority from the systems built around it. Its boundaries organise service without making Internet numbers territorial, and their durability reflects institutional layering rather than a property of the protocol itself.