Keep IPv6 PI When Requesting IPv6 Allocation

Summary of Proposal

If an organisation has received an IPv6 PI assignment prior to becoming an LIR, the last statement in section 7.1 of “IPv6 Address Allocation and Assignment Policy” means they cannot receive an IPv6 allocation unless they return their PI assignment, if both will have the same routing requirements.

I believe this policy text serves as a bureaucratic roadblock to IPv6 deployments, and I propose we remove it.

There are around 1,700 non-LIR IPv6 PI assignment holders in the RIPE region. As these companies develop and expand over time, many will require additional IP space to support their operational requirements and provide IPv6 services to customers. However, if such an organisation becomes an LIR and wants an IPv6 allocation (with the same routing requirements), they must return their critical PI space, or lie to the RIPE NCC about their routing requirements.

Considering PI cannot be assigned to an organisation's customers, it is generally configured on their core network. To renumber would be considerably painful in most cases, and would impede their deployment plans. Other options would be to look into IPv4 alternatives or become dependent on space from another LIR’s IPv6 allocation – neither of which would be desirable.

The recently approved 2014‐04 tried in part to solve this issue by removing IPv6 as a prerequisite for an IPv4 /22 from the last /8. However, the predicament still remains for organisations with IPv6 PI that want to provide IPv6 services to customers. Removing the root cause of this problem is the goal of this proposal.

Ultimately, this policy clause punishes organisations that configured IPv6 PI as a non-LIR and require additional IPv6 space to meet their business and operational needs. We need policy that supports, not penalises, IPv6 deployments.

Policy Text

[The following text will update section 7.1 in the RIPE Policy Document “IPv6 Address Allocation and Assignment Policy“, if the proposal reaches consensus.]

a. Current policy text

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

[...] if the original criteria on which the assignment was based are no longer valid.

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both.

b. New policy text

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

[...] if the original criteria on which the assignment was based are no longer valid.

[Text removed]

Rationale

a. Arguments supporting the proposal

• RIPE Policy should support, rather than restrict, organisations that want to further deploy IPv6
• Removing the statement in question would mean LIRs can keep their (deployed) IPv6 PI assignment when receiving an IPv6 allocation
• Painful and time-consuming renumbering would be avoided
• Avoids IPv6 PI holders that need additional space looking to IPv4 alternatives

b. Arguments opposing the proposal

• Allowing these organisations to receive a PA allocation in addition to their PI assignment will result in a larger routing table size

  Counter Argument
  Without having to decide whether routing table size or IPv6 deployment is more important at this moment in time, it can be argued that there are more prefixes in the routing table because of the existing policy text.

  The current text forces organisations to consider alternative IP solutions to connect customers if they cannot renumber their IPv6 PI in time. If they choose IPv4, they may end up with several IPv4 prefixes what will be added to the routing table - one /22 prefix on becoming an LIR, but as this is very limited in size, they will likely require additional IPv4 prefixes over time.

  However, if this proposal is accepted, they can get one IPv6 allocation prefix and an IPv4 /22 (for a transition NAT pool) to meet their IP requirements indefinitely.

  It is important to keep in mind that of the current ~1,700 non-LIR IPv6 PI holders, not all will need to become an LIR and request an IPv6 allocation. Will there be enough of these requests to adversely affect router memory? Isn’t the continued dependency and increasing fragmentation of IPv4 a bigger threat to routing table size?

• Removing the last sentence of 7.1 would mean the order of requesting IPv6 resources changes the outcome

  Sequence 1: an organisation can get IPv6 PI as a non-LIR. After becoming an LIR, they can request an IPv6 allocation. This means they will get both, regardless of routing requirements.

  Sequence 2: an LIR that first requests an IPv6 allocation and then goes on to request IPv6 PI can only get both if they have different routing requirements.

  Counter Argument
  Organisations that deploy IPv6 PI have a genuine need for an allocation if they want to connect customers on IPv6. In a sense, pre-LIR IPv6 PI deployers will be rewarded.

  Meanwhile, LIRs that first receive an allocation (up to /29 without justification) do not have a requirement for PI with the same routing requirements. They can make specific assignments from their PA space.

  Not allowing LIRs to needlessly have two prefixes also helps to reduce the routing table entries.

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.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC's understanding that LIRs would be able to keep previously assigned IPv6 Provider Independent (PI) ranges when requesting an IPv6 allocation from the RIPE NCC. LIRs would not longer need to provide documentation of different routing requirements to justify both.

However, LIRs would still need to demonstrate different routing requirements when requesting IPv6 PI assignments after receiving an IPv6 allocation or when requesting multiple PI assignments.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.

Fragmentation/Aggregation:

In the unlikely scenario that all ~1,700 IPv6 PI holders went on to become LIRs and request IPv6 allocations, and announce both their new and existing blocks into BGP, the growth of the default free routing table would be 8% for IPv6-only routers and 0.3% for routers holding both IPv4 and IPv6 routing states.

In reality, this number would likely be much lower, as relatively few PI holders go on to become LIRs. The RIPE NCC therefore expects little impact in terms of routing table growth.   

C. Impact of Policy on RIPE NCC Operations/Services

Registration Services:

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.

Billing/Finance Department:

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.

RIPE Database:

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.

D. Legal Impact of Policy

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact if this proposal is implemented.

E. Implementation

The RIPE NCC estimates that the implementation of this proposal would have a very low impact.

The RIPE NCC would update existing processes and supporting documentation for IPv6 allocation requests to remove the routing checks on previously assigned IPv6 PI ranges.