new IPv6 policy framework

Though this is a good  document it does not cater for the needs of
Multinational Registries, i specifily asked for the MIR proposal to be
included in this discussion. This document caters for the single LIR not
mutiple LIR's in one very large pan EMEA network, which is still growing. I
would like to see this included in the draft, or reasons why the community
(not the NCC) are opposed to the MIR proposal for IPV6 (and ipv4 also). To
date there has been no negative comments on the porposal which is why i am
puzzled it is not included.

Regards,
Stephen Burley
UUNET EMEA Hostmaster
SB855-RIPE


>
> Dear LIRs,
>
> Following the discussions at the RIPE 39 meeting and on the mailing
> lists in all the RIR communities, please find below the latest
> developments concerning IPv6 address allocation policies.  This
> proposal is based on requirements expressed by the RIPE community as
> well as those of the other RIR communities.
>
> Please note that the text below is not a replacement of the current
> policy document, but rather a summary of the new IPv6 address
> allocation framework. Therefore this proposal is intended as input for
> further discussion in the RIPE community.
>
> When formulating this framework, we were specifically taking the
> following feedback into account:
>
> - The allocation criteria should be such that it is easy to obtain
>   IPv6 address space.
>
> - The size of the initial allocation should be large enough to allow
>   flexibility in addressing infrastructure and customer sites.
>
> This results in the following changes to previously discussed
> IPv6 allocation criteria:
>
> 1. to recognise existing infrastructure (both IPv4 and IPv6) where it
>    exists and calculate IPv6 address needs based on existing networks.
>
> 2. to apply the slow start mechanism only for 'IPv6 only' networks
>    without existing IPv4 infrastructure
>
> 3. to reduce the minimum allocation size for those IPv6 only networks
>    (unless larger requirements are shown)
>
> 4. to measure the utilisation rate with the HD ratio rather than
>    percentages
>
> 5. to make subsequent allocations when the HD ratio is reached
>
>
> Kind Regards,
> Mirjam Kuehne
> RIPE NCC
> ----------------
>
>
> 1. Abstract
>
> This document provides a set of proposed policies for the management
> of IPv6 address space, specifically concerning the allocation of
> address space allocated by Regional Internet Registries (RIRs) to
> organisations operating IPv6 networks.
>
>
> 2. Overview
>
> Under the current system of management of global IP address space,
Regional
> Internet Registries (RIRs) are responsible for allocation of
> address space to organisations within their respective geographic
> regions.
>
> In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy
> document for IPv6, which has been in operation since then.  Since 2000,
> this document has been under review and discussion, and through this
> process many issues have been raised.
>
> It is the aim of this document to propose a new policy framework for
> IPv6 address space management which takes into account the operational
> experience of the past 3 years, and addresses most if not all of the
> major issues raised through the open review process.
>
> This document does not attempt to provide details of policy
implementation,
> procedures or documentation; nor does it document requirements for
> management of address space which is allocated.  These policies can be
> established globally or regionally as appropriate, based on global
> consensus regarding the fundamental principles described here.
>
>
> 3. Address Space Requirement for Initial Allocation
>
> It is proposed to recognise existing network infrastructure and
> address utilisation (both IPv4 and IPv6). New IPv6 address needs are
> then based on these existing networks.
>
> In assessing a request for an initial allocation, there are 3 possible
> cases to consider:
>
> 3.1. the requesting organisation has an existing IPv4 network which
>      will be addressed by the new IPv6 allocation
>
> 3.2. the requesting organisation has an existing IPv6 network
>
> 3.3. the requesting organisation has no network at all
>
>
> 3.1. Case 1 - Existing IPv4 services
>
> Where IPv6 address space is requested for addressing an existing IPv4
> network, the address requirement is determined according to the
> structure and customer base of the existing IPv4 network. This only
> relates to the part of the network that will be migrated to IPv6.
>
> Additional policies may require the return of IPv4 address space to
> the RIR or upstream ISP, in the case the existing network is
> renumbered to the new IPv6 space in future.
>
> 3.2. Case 2 - Existing IPv6 services
>
> Where an IPv6 allocation is requested by an organisation to address
> infrastructure which is already addressed by IPv6 addresses from an
> upstream provider (or from the 6BONE), the address requirement is
> determined from the number of site addresses assigned by the
> organisation (as registered in the appropriate whois database).
>
> Where existing address space is no longer used, it must be returned.
>
> 3.3. Case 3 - No existing IPv4 or IPv6 services
>
> Where IPv6 address space is required by an organisation which has no
> existing infrastructure, the address requirement will be assessed
> according to network architecture plans and other documentation
> provided to the RIR within the request process.  Such documentation be
> thorough enough to satisfy the RIR that the network deployment is
> genuine, however the specific details of documentation requirements
> will be defined separately.
>
>
> 4. Size of Initial Allocation
>
> The amount of addresses allocated to an existing network, will be
> determined based on the existing infrastructure and address
> utilisation of that network.
>
> For new networks without existing infrastructure, it is proposed to
> establish a minimum allocation for IPv6 address space. It is suggested
> to keep the size of the initial allocation relatively small (a /35 or
> smaller) and to determine the size of subsequent allocations based on
> the utilisation rate of the initial allocation (this is called slow
> start mechanism). This will allow easy access to IPv6 allocations for
> newcomers. At the same time possible wastage of address space and
> routing table growth will be limited.
>
>
> 5. Qualification for Subsequent Allocation
>
> An organisation which has already received address space from an RIR may
> receive a subsequent allocation providing that its existing address space
> is utilised in accordance with these policies.  As explained below, the
> HD-Ratio will be used to measure utilisation of the existing address
space.
>
> An organisation which is deploying substantial new network infrastructure
> may receive a subsequent allocation before it has reached the required
> utilisation threshold, providing that the address requirement would
> immediate cause the organisation to exceed the utilisation threshold.  In
> such cases, the new network infrastructure will be examined by the RIR as
> if it is a request for a new network, and the RIR may require the same
> level of documentation detail, in order to approve the allocation.
>
>
> 6. Address Space Requirement for Subsequent Allocation
>
> For subsequent allocations, the RIR should assess the address requirement
> according to the organisation's history of IP address usage, as well as
its
> stated requirements for future development.
>
> In general, the RIR should provide address space for a fixed time
> period of 2 years.
>
> The above recommendation should be followed in cases where the
organisation
> concerned has complied with all relevant address management policies.  In
> other cases, the RIR may allocate for a shorter future timeframe, and
> require that identified problems be rectified before larger allocations
are
> made.
>
>
> 7. IPv6 Utilisation Metric: the HD-Ratio
>
>
> In IPv4, currently, a "utilisation threshold" of 80% is applied
> consistently in determining whether an IPv4 address pool is to be
> considered utilised, regardless of the size of that block.
> Consequently, an organisation which holds IP address space may
> not receive additional addresses until it has utilised at least 80% of
> the address space held.
>
> For IPv6 is it proposed to assess utilisation according to the "HD-Ratio"
> rather than by a simple percentage.  The HD-Ratio was proposed by Durand
in
> "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the
> original H-Ratio defined by Huitema in RFC-1715).
>
> Using the HD-ratio we can establish a utilisation metric which allows
> percentage utilisation to decrease as the address space grows large.  This
> is appropriate for management of the much larger blocks of address space
> under IPv6, and the likelihood of complex routing and allocation
> hierarchies within those address blocks.
>
> More details about the HD ratio can be found in Appendix A.
>
>
> Appendix A:
>
> In the general case, where individual objects are allocated out of an
> arbitrary address space, the HD-Ratio is calculated as follows:
>
>                log(number of allocated objects)
>     HD = --------------------------------------------
>           log(maximum number of allocatable objects)
>
>
> Where the objects being allocated are IPv6 site addresses (/48s) assigned
> from an IPv6 prefix of length P, we can restate this formula as follows
> (where A is the number of /48 prefixes actually assigned):
>
>                 log(A)             log(A)
>
> In other words, 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
>
>
> In accordance with the recommendations of
> draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft
> to adopt 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
>
>
>
>
>     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%
>    3       45      35184372088832      68719476736       0.2%
>    2       46      70368744177664     119647558364       0.2%
>    1       47     140737488355328     208318498661       0.1%
>    0       48     281474976710656     362703572709       0.1%
>
>
>
>
>