This policy proposal has been accepted
The new RIPE Document is: ripe-707
This proposal aims to clarify the wording used in RIPE-699 regarding terms such as “organisation” and “LIR”.
The proposed text aligns the IPv6 policy with the IPv4 policy, which seems to have been the intent when the current IPv6 policy text was originally written.
This means that an organisation, defined as a legal entity that can have several LIRs, will be able to receive IPv6 allocations per LIR, not per “organisation”.
The proposal also clarifies that it is against the policy for an LIR to repeatedly request and transfer IPv6 allocations (i.e. request an allocation and transfer it, request another and transfer it, and so on).
To qualify for an initial allocation of IPv6 address space, an organisation must:
a) be an LIR;
b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.
Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary.
Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation.
Organisations that have received an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.
Subsequent allocation will be provided when an LIR:
a) Satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56. To this end, the HD-Ratio [RFC 3194] is used to determine the utilisation thresholds.
or
b) Can justify new needs (which can't be satisfied within the previous allocation), according to the initial allocation size criteria as described in section 5.1.2.
When an organisation meets the subsequent allocation criteria, 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 organisation needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. The allocation made will be based on the relevant documentation.
There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation 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/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
An organisation (i.e. ISP/LIR) may assign a network prefix 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.
When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.
When an RIR/NIR delegates IPv6 address space to an organisation, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organisation should properly manage its reverse lookup zone. When making an address assignment, the organisation must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
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 use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.
To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /29 without needing to supply any additional documentation.
LIRs may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation.
LIRs that have received an IPv6 allocation may receive a subsequent allocation in accordance with the following policies.
Subsequent allocation will be provided when an LIR:
a) Satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56. To this end, the HD-Ratio [RFC 3194] is used to determine the utilisation thresholds.
or
b) Can justify new needs (which can't be satisfied within the previous allocation), according to the initial allocation size criteria as described in section 5.1.2.
When an LIR meets the subsequent allocation criteria, 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 LIR needs more address space, it must provide documentation justifying its new requirements, as described in section 5.1.2. The allocation made will be based on the relevant documentation.
There is no specific policy for an LIR to allocate address space to subordinate ISPs. Each LIR may develop its own policy for subordinate ISPs to encourage optimum utilisation 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/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
An LIR may assign a network prefix 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.
When an LIR holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.
When an RIR/NIR delegates IPv6 address space to an LIR, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each LIR should properly manage its reverse lookup zone. When making an address assignment, the LIR must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
Thus, the utilisation threshold for an LIR 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 use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.
This proposal will simplify the RIPE NCC’s process for evaluating IPv6 requests when a legal entity has multiple LIRs, and it will make life easier for LIRs.
We don’t ask LIRs to return their IPv4 space when they want to merge LIRs or evaluate their usage – so why should we require this for IPv6? Allowing resource requests and LIR mergers to be the same for IPv4 and IPv6 will make things a lot easier.
Even worse is that LIRs may have their IP space in use and be forced to migrate or renumber because they might not be allowed to merge LIRs without returning their second IPv6 prefix.
An LIR should be able to receive a /22 of IPv4 (currently) and a /29 of IPv6. Merging LIRs at a later stage should not be a reason to reclaim already-allocated prefixes.
It could be argued that this proposal might consume the RIPE NCC’s IPv6 pool faster, but this will only happen if there is repetitive abuse from legal entities with multiple LIRs. However, this has not been the case with AS Numbers which follow a similar policy.
In the event that abuse is detected by the RIPE NCC, it can be reported to the community to review the policy again in the future.
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.
If this proposal is accepted, it is the RIPE NCC’s understanding that in the IPv6 policies, the undefined term “organisation” will be replaced by the defined term “LIR”. As a consequence, the right to receive IPv6 allocations will apply per LIR, as will responsibilities such as registration requirements and managing the reverse lookup zone. For the RIPE NCC, this policy change will provide clarity regarding to whom IPv6 is allocated.
In this context, it should be noted that the term LIR refers to an LIR account. This is not the same as a RIPE NCC membership. A legal entity can only have one membership, while it can have multiple LIR accounts with the RIPE NCC.
This means it will be possible for a single legal entity to receive multiple IPv6 allocations through several LIR accounts, though the RIPE NCC has already been approving these requests under the existing policy. Currently there are more than 700 members with more than one LIR account. Of these, around 200 have IPv6 allocations in more than one LIR account.
When receiving such requests, the RIPE NCC asks why multiple IPv6 allocations are needed. The main reasons given are plans for geographical distribution and building network redundancies.
If this proposal is accepted, more entities might consider opening several LIR accounts to request multiple IPv6 allocations up to a /29 (as no further justification is needed up to this size), rather than requesting one larger IPv6 allocation, which requires additional documentation.
The policy change also clarifies that once an LIR has received an IPv6 allocation from the RIPE NCC, any further IPv6 allocation requests will be evaluated as subsequent allocations. This applies regardless of whether the LIR still holds its first allocation or has returned or transferred it. LIRs that have returned or transferred their previous IPv6 allocation and later discover a new need can request another allocation, as the IPv6 policy allows subsequent allocations based on this criteria.
This policy change will prevent a potential loophole where IPv6 allocations could be repeatedly requested and transferred away. If the RIPE NCC observes such behaviour, it will request additional documentation to justify the request, based on the subsequent allocation policy.
Currently around 6,000 out of 19,000 active LIR accounts don’t hold an IPv6 allocation. While this policy change might raise awareness that IPv6 allocations can be requested on a per-LIR basis, it’s unlikely that all of these LIR accounts will actually submit requests in the near term.
Overall, the RIPE NCC estimates that there will be no significant impact on the IPv6 pool.
Registration services expects a slight increase in the number of IPv6 allocation requests, as result of the clarification that allocations can be requested for each LIR account.
When the requesting LIR account belongs to a legal entity that has requested an IPv6 allocation via another LIR account, Registration Services will check that the provided plans and documentation are different from previous requests from the same legal entity. This will apply in particular when the requested IPv6 allocation size exceeds /29.
It is expected that implementation of the proposal would have a low impact in terms of software development needed to facilitate the policy changes in internal RIPE NCC systems (about one month). Internal and external processes and documentation would also need to be updated.