Policy Pre-CPM

Details
  • Ref. Name:
    AFPUB-2004-ASN-001
  • Old Ref:
    afpol-as200407-000
  • Status:
    Implemented
  • Date:
    30 Jun 2004
  • Author:
    • Adiel Akplogan
    • Ernest Byaruhanga

1) Abstract

This document contains policies and guidelines concerning requesting, assigning and registering AS (Autonomous System) numbers in the AFRINIC region.

 

2) Introduction

AFRINIC (the African Network Information Center) is the regional Internet Registry for Africa and part of the Indian Ocean region (Seychelles, Mauritius, Madagascar, Comoros). It is responsible for distributing public Internet address space and related resources (including Autonomous System Numbers) in the region and coordinating the development and implementation of the policies to manage those resources.

The policies described in this document have been developed by the Internet community through a consensus process facilitated by AFRINIC. They are to be implemented by AFRINIC.

 

3) Scope

This document describes the policies relating to the distribution, management, and use of Autonomous System (AS) numbers in the AFRINIC service region. These policies apply to IPv4 and IPv6 networks. Policies of other regions other than the AFRINIC service region are outside the scope of this document.

 

4) Definitions

The following terms and definitions are used in this document.

4.1 Autonomous System (AS)

An Autonomous System (AS) is a connected group of one or more IP prefixes run by one or more network operators under a single and clearly defined routing policy.

4.2 Autonomous System Number (ASN)

An Autonomous System Number (ASN) is a unique integer associated with an AS. The ASN is used as an identifier to allow the AS to exchange dynamic routing information with other Autonomous Systems.

Exterior routing protocols (such as the Border Gateway Protocol (BGP) described in RFC 1771) are used with ASNs to exchange information between networks. An AS will normally use some interior gateway protocol to exchange routing information on its internal networks.

4.3 Multi-homed Network

A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multi-homed if it is connected to a public Internet Exchange Point.

4.4 Routing policy

The routing policy of an AS is a description of how network prefixes are exchanged between that AS and other Autonomous Systems.

4.5 aut-num object

An aut-num object is an object in the Whois database used to register ASN assignment details.

 

5) Eligibility for an AS Number assignment

There are a limited number of available AS Numbers. Therefore, it is important to determine which sites require unique AS Numbers and which do not. Sites that do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64512 through 65535 (RFC1930).

In order to qualify for an AS number, the requesting organization must fulfill the following requirements:

  • A unique routing policy (its policy differs from its border gateway peers).
  • A multi-homed site.
  • An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter).
  • Be an AFRINIC member in a good standing (End-User or LIR type)

All requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930 "Guidelines for the creation, selection and registration of an Autonomous System (AS).

 

6) Ownership and Routing Considerations

6.1 Ownership

The Internet community regards ASNs as a public resource that should only be distributed according to demonstrated need. Neither assignment nor registration confers ownership of resources. Organizations that use ASNs are considered "custodians" rather than "owners" of the resource, and are not entitled to sell or otherwise transfer that resource to other parties.

6.2 Routing considerations

Responsible management of ASNs is necessary to help limit the expansion of global routing tables. Aggregating contiguous IP address prefixes within single Autonomous Systems helps to minimize the number of routes announced to the global Internet.

 

7) Assignment Procedures

AFRINIC assigns AS Numbers for Autonomous Systems located in the AFRINIC service region and accepts requests from LIRs, non-LIR's members and non-members fulfilling the eligibility requirements in Section 5.0 of this document.

AFRINIC may ask for such information that may help to understand the planned routing policy and to decide if an AS Number is actually needed.

7.1 Using ASNs for LIRs network

Assignments to ISPs that will use the ASN in their own network are subject to the following terms:

  • The requesting ISP is responsible for maintaining the registration described in Section 8.
  • The requesting ISP is entitled to continue using the ASN, even if they change network peers or service providers.
  • LIRs with AFRINIC will not be charged any annual maintenance fee for ASNs.

7.2 Providing ASNs to non-LIRs

Assignments to any other organizations that are not LIRs are subject to the following terms:

  • The ISP that will actually use the ASN must meet the criteria in Section 5.
  • The requesting ISP is responsible for maintaining the registration described in Section 8.
  • A one-time registration fee will be charged for each ASN assigned, as described in AFRINIC's Fee Schedule. Every three years thereafter, AFRINIC will invoice the organization for an annual maintenance fee, payable on the anniversary date of the original assignment.

 

8) Registration Requirements

All ASNs assigned must be publicly registered in the AFRINIC Whois database. AFRINIC will create the 'aut-num' object in the database.

All attributes of the 'aut-num' object must be properly registered in accordance with the AFRINIC Whois database documentation. Without limiting these general requirements, Sections 8.1, 8.2 describe particular requirements for ASN registrations.

8.1 Registering contact persons

Administrative and technical contact persons must be registered for each ASN assigned. The registered administrative contact ('admin-c') is the person responsible for the ASN and should generally be someone who is physically located at the site of the AS.

The technical contact ('tech-c') need not be physically located at the site of the AS, but must be a person who is responsible for the day-to-day operation of that AS.

8.2 Registering routing policy

AFRINIC recommends that the routing policy of the AS is registered in Whois Database each ASN assigned.

8.3 Updating registration details

LIR's responsible for ASNs should update the 'aut-num' object in the AFRINIC Whois database if any of the registration information changes.

 

9) Returning unused ASNs

If an ASN is not being used by the organization that originally received it, it should be returned. AFRINIC will then return it to the public pool of AS Numbers for reassignment to another Autonomous System in the AFRINIC region.

 

10) Miscellaneous

AFRINIC may publish other guidelines related to ASNs including charging (maintenance recovery fees) details and related agreements, request forms, a further description of evaluation procedures, practices that LIR requesting ASNs are expected to adopt and information that may assist organizations to request ASNs.

Any other guidelines published will be developed within the community (where necessary) and will be consistent with the goals and policies described in this document.

 

Date: 20040331 Adaptation:
Version: Draft.01b Adiel Akplogan
Previous: Draft.01a Ernest Byaruhanga

 

 

Abstract

This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations in the AfriNIC region.

Table of Contents

1. Introduction
2. Definitions
3. Goals of IPv6 address space management
4. IPv6 Policy Principles
5. Policies for allocations and assignments
6. Assignments for Internet Experiments
7. HD-Ratio and Utilisation Threshold.

1. Introduction

1.1. Overview

This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.

[RFC 2373, RFC 2373bis] designate 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. IANA has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. Because End Sites will generally be given /48 assignments , the particular emphasis of this document is on policies relating the bits within 2000::/3 to the left of the /48 boundary. (See RFC3177). http://www.faqs.org/rfcs/rfc3177.html

However, since some End Sites will receive /64 and /128 assignments, all bits to the left of /64 are in scope.

2. Definitions
-----------

For consistency, many of the following definitions have been replaced by definitions from other RIR documents.

The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.

Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.

 



2.1. Regional Internet Registry (RIR)

Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.

2.2. Local Internet Registry (LIR)

A Local Internet Registry primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.

2.3. Allocate

To "allocate" means to distribute address space to RIR/LIR for the purpose of subsequent distribution by them.

2.4. Assign

To "assign" means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.

2.5. Utilisation

Unlike IPv4, IPv6 is generally assigned to End Sites in fixed amounts (e.g. /48). The actual usage of addresses within each assignment will be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the /48 boundary. In other words, "utilisation" refers to the assignment of /48s to End Sites and not the number of addresses assigned within individual /48s at those End Sites.

Throughout this document, the term "utilisation" refers to the allocation of /48s to End Sites and not the number of addresses assigned within individual /48s within those End Sites.

2.6. HD-Ratio

The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation of the H-Ratio originally defined in [RFC1715] and is expressed as follows:

Log (number of allocated objects)
HD = ------------------------------------------------
Log (maximum number of allocatable objects)

where (in the case of this document) the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of a given size.

3. Goals of IPv6 address space management.
--------------------------------------

3.1. Goals.

IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.

3.2. Uniqueness

Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.

3.3. Registration

Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.

The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.

3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address ranges.

Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.

3.5. Conservation

Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.

3.6. Fairness

All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.

3.7. Minimised overhead

It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.

3.8. Conflict of goals

The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments,
seeking to balance the needs of the applicant with the needs of the Internet community as a whole.

In IPv6 address policy, the goal of aggregation is considered to be the most important.

4. IPv6 Policy Principles
----------------------

To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.

4.1. Address space not to be considered property.

It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.

The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned.

4.2. Routability not guaranteed

There is no guarantee that any address allocation or assignment will be globally routable.

However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.

4.3. Minimum allocation

RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering.

The minimum allocation size for IPv6 address space is /32.

4.4. Consideration of IPv4 infrastructure

Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.

5. Policies for allocations and assignments
----------------------------------------

5.1. Initial allocation

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organization must:

a) be an LIR;

b) not be an end site;

c) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region.

d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to annouce the allocation as a single aggregated block in the inter-domain routing system within twelve months.

5.1.2. Initial allocation size

Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32.

Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure.

5.2. Subsequent allocation

Organizations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organization (LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /48 assignments. The HD- Ratio [RFC 3194] is used to determine the utilization thresholds that justify the allocation of additional address as described below.

5.2.2. Applied HD-Ratio

The HD-Ratio value of 0.8 is adopted as indicating an acceptable address utilization for justifying the allocation of additional address space. Section 7 provides a table showing the number of assignments that are necessary to achieve an acceptable utilization value for a given address block size.

5.2.3. Subsequent Allocation Size

When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organization needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.

5.3. LIR-to-ISP allocation

There is no specific policy for an organization (LIR) to allocate address space to subordinate ISPs. Each LIR organization may develop its own policy for subordinate ISPs to encourage optimum utilization of the total address block allocated to the LIR. However, all /48 assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.

5.4. Assignment

LIRs must make IPv6 assignments in accordance with the following provisions.

5.4.1. Assignment address space size

Assignments are to be made using the following guidelines:

- /48 in the general case, except for very large subscribers.
- /64 when it is known that one and only one subnet is needed by design
- /128 when it is absolutely known that one and only one device is connecting.

AfriNIC is not concerned about which address size an LIR actually assigns. Accordingly, AfriNIC will not request the detailed information on IPv6 user networks ( as in IPv4 ) , except for the cases described in Section 4.4 and for the purposes of measuring utilization as defined in this document.

5.4.2. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will
be processed and reviewed (i.e., evaluation of justification) at the RIR level.

Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having AfriNIC review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

5.4.3. Assignment to operator's infrastructure

An organization (LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.


5.5. Registration

When an organization (LIR) holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in the AfriNIC database. Information is registered in units of assigned /48 networks. When more than a /48 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in the AfriNIC database.

AfriNIC will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time.

AfriNIC shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.

5.6. Reverse lookup

When an AfriNIC delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.


5.7. Existing IPv6 address space holders

Organizations that received /35 IPv6 allocations under the previous IPv6 address policy [RIRv6-Policies] are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 5.1.1. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.

6. Assignments for Internet Experiments
------------------------------------

Organisations often require deployment tests for new Internet services and technologies. These require numbering resources for the duration of the test.

The policy goal of resource conservation is of reduced importance when resources are issued on a temporary basis.

6.1 Defining the experiment

An organisation receiving numbering resources must document the experiment. This may be in the form of a current IETF Experimental RFC (http://www.ietf.org/rfc/rfc2026.txt see Sec. 4.2.1) or an "experiment proposal" detailing the resources required and the activities to be carried out.

The assignment size will be equal to the existing minimum allocation size on the date the request is received. Where the experiment requires a variation to this rule it should be noted in the resource request.

6.2 Publication

The experiment proposal must be made public (e.g. published on web site), upon registration of the resources by AfriNIC. Following the conclusion of the experiment the results must be published free of charge and free from disclosure constraints.

6.3 Non-commercial basis

Resources issued for an experiment must not be used for commercial purposes.

6.4 Period of the Temporary Resource Registration.

The resources will be issued on a temporary basis for a period of one year. Renewal of the resource's registration is possible on receipt of a new request that details any continuation of the experiment during the extended period.

The resources issued cannot be used for a commercial service following the conclusion of the experiment.

6.5 Registration

AfriNIC will register the resources issued in the AfriNIC Whois Database.


7. HD-Ratio (HD) and Utilisation Threshold (T).
------------------------------------------

The HD-Ratio is not intended to replace the traditional utilisation measurement that ISPs perform with IPv4 today. Indeed, the HD-Ratio still requires counting the number of assigned objects. The primary value of the HD-Ratio is its usefulness at determining reasonable target utilisation threshold values for an address space of a given size. This document uses the HD-Ratio to determine the thresholds at which a given allocation has achieved an acceptable level of utilisation and the assignment of additional address space becomes justified.

The utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as:

((48-P)*HD)
T = 2

Thus, the utilisation threshold for an organisation requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the allocation of /48s to End Sites, and not the utilisation of those /48s within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.

In accordance with the recommendations of [RFC 3194], this document adopts an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations.

The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8

 

Page 12 of 12