Policy Archive

IPv6 Allocations to Non-Profit Networks - AFPUB-2009-v6-001

: Last Modified on - 18 October 2020

Ref. Name	AFPUB-2009-v6-001	Old Ref.
Status	Rejected
Date	27 Jan 2009
Author(s)	Graham Beneke
Organisation	Johannesburg Area Wireless Users Group

TOC	Incentive Background Definitions Allocation Size Allocation Criteria Summary

Incentive

Define criteria for non-profit and community organisations to be recognized for membership of AfriNIC and to allow them to request resources. Define criteria for organisations to qualify for blocks of IPv6 PI address space and define a membership category that can be charged under an appropriate fee structure.

Background

Many community and non-profit networks exist on the African continent and around the world. These networks have goals including providing on-net and local community services and the exchange locally hosted Internet content. They provide a platform for local skills development in IP, SysAdmin, Software Development and other ICT related skills.

Many of these organisations provide the services free of charge and do not have any kind of revenue stream. These networks generally consist of hundreds or thousands of consumer-grade network devices often linked though license exempt radio networking technologies.

Current financial policies only recognise academic institutions to receive discounted rates for their numbering resources. Other suitably defined community organisations also need ways of obtaining affordable addressing resources.

These networks are generally addressed using private IPv4 (RFC1918) address space with NAT technologies used at locations on the network where gateways are required to link certain internal services to the Internet.

IPv6 ULA (RFC4193) addresses are also used on these networks when deploying services over IPv6. NAT however does not exist for IPv6 and thus it is not possible to connect these ULA based networks to the global Internet. Announcements of these ULA blocks over private peering arrangements to large public AS's is often not feasible due to the many bogon filters that would need to be updated.

The current IPv6 PI allocations policy requires that the address blocks handed out by AfriNIC be announced within 12 months of allocation. This puts an expectation that the prefix is visible on a number of public looking glasses. While the organisation may have have a number of settlement-free peering arrangements with a number of public AS's it is possible that the organisation would never be able to purchase/obtain transit for its prefix and would thus never be globally routable or visible.

The lack of publicly addressable IP space for these community networks prevents them from participating on the public Internet more actively. While IPv4 address space is finite and likely to increase in cost/value as supply and demand changes over the immediate future - sufficient IPv6 address space exists for responsible allocations to be made to these organizations at a low cost.

Definitions

(a) A non-profit network is a network run within a local geographical area for the purposes of free or low-cost network services within this particular area. Legal responsibility for the network must be held by an organisation running as a not-for-profit entity and recognised as such by the laws governing that particular country or region.

Allocation Size

Organisations that qualify to become members under this policy may apply to AfriNIC for a /48 IPv6 address allocation. This is the only size of allocation the non-profit organisation may request. Once an HD-Ratio of 0.94 has been reached with respect to subnet utilisation then the organisation may make application to AfriNIC for additional addressing resources and provide justification for this.

Allocation Criteria

The organisation must not be an existing LIR.
The organisation must not hold an assignment of globally unique IPv4
address space.
The organisation may qualify for an allocation even if they do not
plan to announce it globally.
The organisation should provide details of peering arrangements with
at least 2 public AS's when applying for the allocation.
The organisation must announce the allocation in an aggregated way.
The organisation may not sub-allocate portions of the address space.

Summary
This policy seeks to make it as easy as possible for non-profit entities to obtain IPv6 addressing resources and drive the deployment of and demand for IPv6 services through this.

Additionally the policy seeks to limit the way in which these addressing resources are used to avoid abuse by Internet service providers and other commercial users of Internet addressing resources.

IPv6 PI Clarification

: Last Modified on - 17 November 2020

Details

ID: AFPUB-2019-v6-001-DRAFT02

Version: 2.0

Status: Implemented

Authors: Jordi Palet Martinez -

jordi.palet at theipv6company.com

The IPv6 Company

Owen DeLong -

owen at delong.com

Great Home Tek, Inc

Amends: CPM art 6.8

Submitted: 14th May 2019

Proposal

1.0 Summary of the problem being addressed by this proposal

By means of policy proposal “IPv6 PI Update” (AFPUB-2018-V6-004), the IPv6 Provider Independent (PI) space policy that provides IPv6 space for end-sites was revised/updated.

This revision however overlooked a sentence in the previous section 6.8.2.v, which read:

“The 'end-site' must show a plan to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC”.

This text was retained under 6.8.2.iv.

Of course, this doesn’t make sense because there are several possible cases, which are in the scope of this policy, that will not announce their IPv6 PI address space, such as:

IXP’s LAN peering space.
Numbering of private networks not connected to the Internet is a perfectly valid use case for IPv6 PI space and should be supported by RIR policy

In addition, the existing text is referring to end-sites, when actually should consider end-user organizations. An end-site, considered as a single “location”, will not address cases such as organizations having multiple end-sites and will force multiple AFRINIC end-user memberships.

An organization with multiple end-sites, will probably fall in one of the following cases:

Multiple end-sites connected with Layer 2 and BGP to their upstreams (a bank, a multi-campus university, etc.), will be able to obtain a prefix length sufficient to accommodate the entire number of sites, hopefully in the nibble boundary and announce a single aggregated prefix.
Multiple end-sites not connected among them and being announced as "different" networks, for example, even with different ISPs. Typically, will use and announce a single /48 for each end-site.
A possible mix case among 1 and 2 above.

2.0 Summary of how this proposal addresses the problem

Simple rewording of the text to allow those cases that don’t need to announce their IPv6 PI space.

3.0 Proposal

Current

Proposed

6.8 PI Assignments

This policy is aimed at providing IPv6 address space to end-sites.

6.8 PI Assignments

This policy is aimed at providing IPv6 address space to end-user organizations.

6.8.1 Introduction

This policy allows 'end-sites' to be assigned IPv6 provider independent (PI) addresses. 'End-sites' include End-Users and critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's).

6.8.1 Introduction

This policy allows 'end-sites' of end-user organizations to be assigned IPv6 provider independent (PI) addresses. These include critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's).

6.8.2 Assignment Criteria

Assignment target - End-sites which provide Public Internet services for a single administrative organisations' network, regardless of their size.
Assignment criteria:
1. The end-site must not be an LIR
2. The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its membership category
3. The end-site must justify the need for the IPv6 PI address space.
4. The end-site must show a plan to use the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC.
5. The IPv6 provider independent address space to be announced by the end-site should not be disaggregated.

6.8.2 Assignment Criteria

Assignment target - End-user organizations which provide services for their administrative organizations’ network, regardless of their size.
Assignment criteria:
1. The organization must not be an LIR.
2. The organization must be or become an AFRINIC End User Member.
3. The organization must justify the number of end-sites and the need for the IPv6 PI address space.
4. The organization must deploy the IPv6 provider independent address space at each of the end-sites, for which addresses are obtained, within twelve (12) months.
5. If the addressing space issued under this policy is to be announced, to the extent practicable, the organization should aggregate any announcements of prefixes so as to minimize global routing table growth.

6.8.3 Provider Independent (PI) address space:

The provider independent (PI) assignment should be made from a specific block.
The initial provider independent assignment size to an end-site should be a /48, or a shorter prefix if the end-site can justify it.
Subsequent assignments must be documented and justified. Where possible, such assignments will be made from a contiguous address block (i.e., extending the existing assignment "n" bits to the left).

6.8.3 Provider Independent (PI) address space:

The provider independent (PI) assignment should be made from a specific block.
The initial provider independent assignment size for each organization shall be at least a /48 per end site. If multiple end sites are requested and will be connected to each other, a nibble-aligned prefix shall be issued sufficient to allow at least one /48 per end-site. Valid justification for a shorter prefix for any end sites shall be accommodated.
The organization assignment will be calculated on the basis of the number of end-sites and adjusted to the nearest nibble-boundary.
Subsequent assignments must be documented and justified. Where possible, such assignments will be made from a contiguous address block (i.e., extending the existing assignment "n" bits to the left).
AFRINIC shall use a sparse allocation algorithm when issuing space to maximize the likelihood of success for the mechanism defined in the preceding paragraph.

6.8.4 Rectifying the size of an initial assignment

An End-site may submit a new addressing plan to AFRINIC if the plan initially submitted to justify the initial assignment no longer satisfies their current needs.
The new assignment will be consistent with the new plan and comply with 6.8.2 and 6.8.3.
If possible, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if such assignment would not leave sufficient space for subsequent assignments, AFRINIC will inform to the requesting organization, which will have the following options:
i. Receive a new block with the new requested prefix size, with the commitment to renumber its network and return the original block within a period of 6 months;
ii. Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keep both blocks.
This procedure can only be used once by each end-site.

6.8.4 Rectifying the size of an initial assignment

An organization may submit a new addressing plan to AFRINIC if the plan initially submitted to justify the initial assignment no longer satisfies their current needs.
The new assignment will be consistent with the new plan and comply with 6.8.2 and 6.8.3.
If possible, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if such assignment would not leave sufficient space for subsequent assignments, AFRINIC will inform to the requesting organization, which will have the following options:
i. Receive a new block with the new requested prefix size, with the agreement to utilize the new block for all future deployment and deprecate the old block through attrition, returning when empty. There is no deadline for return at this time;
ii. Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keep both blocks.
This procedure can only be used once by each organization.