Policy Archive

 

Details
  • Ref. Name:
    AFPUB-2007-v6-002
  • Old Ref:
    afpol-ipv6hdr20070330
  • Status:
    Implemented
  • Date:
    13 Jun 2007
  • Author:
    • Adiel A. Akplogan

1) Rational

The current IPv6 Address Allocation and Assignment Policy (afpol-v6200407-000) suggests that most IPv6 subscribers should be assigned a /48 "in the general case". The policy also requests AfriNIC to evaluate requests for additional allocations based on "units of /48 assignments" and that LIRs be allocated in general a /32.

 

Contrary to IPv4 where only utilization determines the level of consumption hence the threshold for subsequent allocations (80% host based utilization), in the IPv6 Policy efficient address space utilization threshold is used to determine eligibility to subsequent allocations. The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]:

 

Log (number of allocated objects)
 HD = ------------------------------------------
 Log (maximum number of allocatable objects)
The efficiency utilization threshold (T) is expressed as a number of individual
 /48 prefixes allocated from an IPv6 prefix (P). It can be calculated as:
((48-P)*HD)
 T = 2

The HD-Ratio presently defined for IPv6 is at 0.8.

This has the effect of making subsequent allocations to LIRs after only 10.9% utilization of their available space. If the allocation prefix is brought down to /20 the efficient utilization threshold will only be 2.1% using the HD ratio of 0.80. Based on this, the LIRs will have much more unused IP addresses than they really need for their efficient growth planning. (See ANNEX 1).

This policy proposal suggests to raise the HD ratio from 0.80 to 0.94. Doing this could allow to reduce by 3 bit the consumption of whole IPv6 address space over the next 50 years. An LIR will then qualify for a subsequent allocation only when its uses (for a /32) 51.41% of its allocation.

See http://smakd.potaroo.net/ietf/all-ids/draft-narten-iana-rir-ipv6-considerations-00.txt for more analysis on Issues Related to the Management of IPv6 Address Space.

** Similar adjustment of the HD-Ration has been adopted in the other RIR regions **

 

ANNEX 1

A) With an HD=0.8

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

        P       48-P            Total /48s     Threshold    Util%


        48       0                   1                1     100.0%
47 1 2 2 87.1%
46 2 4 3 75.8%
45 3 8 5 66.0%
44 4 16 9 57.4%
43 5 32 16 50.0%
42 6 64 28 43.5%
41 7 128 49 37.9%
40 8 256 84 33.0%
39 9 512 147 28.7%
38 10 1024 256 25.0%
37 11 2048 446 21.8%
36 12 4096 776 18.9%
35 13 8192 1351 16.5%
34 14 16384 2353 14.4%
33 15 32768 4096 12.5%
32 16 65536 7132 10.9%
31 17 131072 12417 9.5%
30 18 262144 21619 8.2%
29 19 524288 37641 7.2%
28 20 1048576 65536 6.3%
27 21 2097152 114105 5.4%
26 22 4194304 198668 4.7%
25 23 8388608 345901 4.1%
24 24 16777216 602249 3.6%
23 25 33554432 1048576 3.1%
22 26 67108864 1825677 2.7%
21 27 134217728 3178688 2.4%
20 28 268435456 5534417 2.1%
19 29 536870912 9635980 1.8%
18 30 1073741824 16777216 1.6%
17 31 2147483648 29210830 1.4%
16 32 4294967296 50859008 1.2%
15 33 8589934592 88550677 1.0%
14 34 17179869184 154175683 0.9%
13 35 34359738368 268435456 0.8%
12 36 68719476736 467373275 0.7%
11 37 137438953472 813744135 0.6%
10 38 274877906944 1416810831 0.5%
9 39 549755813888 2466810934 0.4%
8 40 1099511627776 4294967296 0.4%
7 41 2199023255552 7477972398 0.3%
6 42 4398046511104 13019906166 0.3%
5 43 8796093022208 22668973294 0.3%
4 44 17592186044416 39468974941 0.2%

 

B) with an HD=0.94

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

P 48-P Total /48s Threshold Util%

        P       48-P            Total /48s     Threshold    Util%

        48       0                   1                1      100.0%
47 1 2 2 95.93%
46 2 4 4 92.02%
45 3 8 7 88.27%
44 4 16 14 84.67%
43 5 32 26 81.23%
42 6 64 50 77.92%
41 7 128 96 74.74%
40 8 256 184 71.70%
39 9 512 352 68.78%
38 10 1024 676 65.98%
37 11 2048 1296 63.29%
36 12 4096 2487 60.71%
35 13 8192 4771 58.24%
34 14 16384 9153 55.86%
33 15 32768 17560 53.59%
32 16 65536 33689 51.41%
31 17 131072 64634 49.31%
30 18 262144 124002 47.30%
29 19 524288 237901 45.38%
28 20 1048576 456419 43.53%
27 21 2097152 875653 41.75%
26 22 4194304 1679965 40.05%
25 23 8388608 3223061 38.42%
24 24 16777216 6183533 36.86%
23 25 33554432 11863283 35.36%
22 26 67108864 22760044 33.92%
21 27 134217728 43665787 32.53%
20 28 268435456 83774045 31.21%
19 29 536870912 160722871 29.94%
18 30 1073741824 308351367 28.72%
17 31 2147483648 591580804 27.55%
16 32 4294967296 1134964479 26.43%
15 33 8589934592 2177461403 25.35%
14 34 17179869184 4177521189 24.32%
13 35 34359738368 8014692369 23.33%
12 36 68719476736 15376413635 22.38%
11 37 137438953472 29500083768 21.46%
10 38 274877906944 56596743751 20.59%
9 39 549755813888 108582451102 19.75%
8 40 1099511627776 208318498661 18.95%
7 41 2199023255552 399664922315 18.17%
6 42 4398046511104 766768439460 17.43%
5 43 8796093022208 1471066903609 16.72%
4 44 17592186044416 2822283395519 16.04%

 


 

History
31.03.2007 Posted to rpd mailing list by author
02.03.2007 Reached consensus during AfriNIC-6 in Abuja, Nigeria.
08.05.2007 15 Days Last Call period starts.
23.05.2007 15 Days Last Call period ends.
13.06.2007 Implemented

Ref Name AFPUB-2007-v6-003 Old Ref. afpol-v6200607
Status Withdrawn
Date 01 April 2007
Author(s) Jordi Palet Martinez
Organisation Consulintel
 
TOC
  1. Acknowledgments:
  2. Summary of Proposal
  3. Draft Policy Text
  4. Incentive

Acknowledgments:

I would like to acknowledge to the authors of the ULA-central work at IETF, Bob Hinden and Brian Haberman and all those who also contributed to that work.

Summary of Proposal:

This policy is intended to allow the assignment of IPv6 blocks within the so-called ³Centrally Assigned Unique Local IPv6 Unicast Addresses² (see http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01) to organizations or individuals requiring it. These addresses are globally unique and intended for local communications, usually within a site or set of them and are not expected to be routable on the global Internet. Prefix FC00::/7 is already reserved by IANA for ULA (bit 8 determines if locally or centrally assigned, so ULA or ULA-central).


Draft Policy Text:

New text, possibly as section 2.6:


2.6. ULA-central
ULA-central refers to the Centrally Assigned Unique Local IPv6 Unicast Addresses as described in the IETF document ³ietf-ipv6-ula-central² (whatever version is the most recent, as an Internet Draft, RFC or STD). The ULA-central block is within the prefix FC00::/7, with bit 8 set to 0.

New text, possibly as section 7:

7. Assignment of ULA-central blocks

Any organization or individual requiring a /48 from the ULA-central block will be able to get it assigned, once the relevant contract is executed and related membership fees are paid (to be determined by the board).

Note that in most of the cases, locally assigned ULA addresses (RFC4193) are preferred, and it is only expected that large managed sites will prefer central assignments. It is also important to reinforce that the ULA prefix
(FC00::/7) it is not routable in the global Internet (i.e., not designed to be used as IPv6 PI) and consequently must be filtered.

Incentive:


a. Arguments Supporting the Proposal

The ³Micro-allocations for Internal Infrastructure² document from ARIN (policy proposal 2006-2, authored by Jason Schiller et al., available at http://www.arin.net/policy/proposals/2006_2.html), document describes the need of this kind of additional block for purposes BGP Re-Convergence, Internal Infrastructure Security and why locally assigned ULAs (RFC4193) addresses are not appropriate.

b. Arguments Opposing the Proposal

None foreseen. However, it should be clear that the original scope of ULA-central is for large managed sites and all other cases should use locally assigned ULAs as per RFC4193. From the same document, it is clearly documented the reasons why this prefix will not be useful as IPv6 PI and will be filtered out in the global Internet.