Skip to main content
  • Legend
  • Added
  • Deleted

This proposal introduced a solution for organisations that needed IPv6 Provider Independent (PI) address space.

Summary of Proposal:

This proposal introduces This policy is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) address space.

assignments.

Typically, such organisations will require the PI assignment to become Multihomed as happens for IPv4, but there may be other reasons behind requests. For example, some organisations are not Multihomed, but still need their assignments to be globally routable with stable addressing. They may wish to avoid renumbering if they change their upstream provider. This could be for administrative, policy or security reasons. In such cases, it seems that no other solution than PI assignments would currently be feasible.

Considering the probable medium to long-term consequences of this policy on routing tables, this proposal suggests an expiry date of three years for this policy. The three year period will start only after an alternative technically valid and deployable solution has been devised and accepted by the Internet community. After a 'sunset' period, the assignments made for Multihoming purposes should be reclaimed, and this policy should be modified to continue to allow assignments that could be needed for purposes other than Multihoming.

At that time, any organisations that wanted to avoid renumbering would be able to opt to become a Local Internet Registry (LIR), if they qualify, and be allocated the same prefix.

Rationale:

a. Arguments Supporting the Proposal

Currently, there is no solution for End User organisations that require redundancy in IPv6. This

In IPv4, there are organisations that qualify for a PI allocation, or that could opt to become an LIR. This may be because they need either to be Multihomed or have other administrative or technical reasons for needing a portable addressing block.

This is currently not the case for IPv6, and is perceived as a clear barrier to deployment of IPv6 for its deployment in some organisations. This policy proposal aims to solve this problem by means of providing addresses that barrier by providing a way to obtain a direct assignment from the RIPE NCC.

The other four RIR regions already have a policy for assigning IPv6 PI address space.

Any organisation receiving such an allocation would not be allowed to make further assignments to other external organisations. They would only be allowed to assign subnets internally within their own facilities.

Assigning a /32 would make those blocks behave as other regular LIR allocated ones. They would follow generally accepted routing filtering practices. At the same time, the blocks would be identifiable as belonging to a special 'super block'. This would also allow organisations to become an LIR and avoid the need for renumbering.
By setting up this policy, we would avoid creating an unfair situation among different regions regions, and meet the needs of any organisation that required PI address space. All organisations from the five RIR regions that opt for the IPv6 PI address space will PI space, would be in an equal position once the community agrees a long-term technical solution. These organisations will solution and would have to either move to this new solution or become an LIR, if they qualify.

Newcomers would also be in the same position. Some organisations would not opt for PI space under this policy as they would not need it. This would avoid placing them in an unfair situation.

Those that do not believe in possible alternative solutions, but who prefer to go for a permanent PI policy, have no valid reasons to oppose to this proposal, as the 'sunset period' would only come into effect after a suitable solution had been agreed. This proposal is, therefore, not going to interfere with their plans.

Some organisations may qualify to become an LIR now, and avoid using this temporary assignment. However, if their only reason to become an LIR is to get a PI block, then it may help better control the size of global routing tables in the long-term, if they consider the option that is proposal offers. This would be fairer to the wider Internet community.

The 'temporary' nature of this assignment must be considered long-term, as we may expect alternative solutions to be available in around three to four years. This takes no account of a transition period. Therefore, asking for a change after six or seven years should be acceptable to all.

b. Arguments Opposing the Proposal

The possible effect of this proposal is the growth of the global routing table to a level a growth of global routing tables to levels that, together with existing and forecasted the existing and forecast IPv4 routing entries, could create significant issues for operators unless vendors can provide products that address such issues. Even if such technical solutions were found, the proposal could still have a major impact on the cost and/or depreciation period for infrastructure investments.

Additional Information:

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 may have if the proposal is accepted and implemented.

A. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

We assumed that one immediate potential possibility that the proposal could bring if it were to become a policy would be for all existing IPv4 PI holders to request a /48 for each IPv4 prefix they have. At the time this analysis was carried out, there were approximately 22,000 objects with the status ASSIGNED PI in the RIPE Database [1] Link: http://www.ripe.net/ripe/policies/proposals/2006-01.html#ref1 . 22,000 /48s resolve into a little over a /34 and a /36 of IPv6 address space.

Fragmentation/Aggregation:

The introduction of this policy would increase the number of entries in the routing table, simply because the proposal is for assignment of new IPv6 prefixes.

Currently, the IPv6 tables collected by Routing Information Service (RIS) contain approximately 2,000 ROUTE6 object entries [2] Link: http://www.ripe.net/ripe/policies/proposals/2006-01.html#ref2 .

At the time this analysis was carried out, there were approximately 22,000 objects with the status ASSIGNED PI in the RIPE Database [1] Link: http://www.ripe.net/ripe/policies/proposals/2006-01.html#ref1 . Again, we assumed that one immediate potential possibility could be for all existing IPv4 PI holders to request and route a /48 for each IPv4 prefix they have. In that case, the routing tables would increase by a factor of 10 compared to today's size.

In the short term (up to one year), the impact of already existing IPv6 PI policies in other regions suggests a rather limited increase in routing table entries:

Although regional differences certainly exist, it seems unlikely that the RIPE NCC would assign thousands of IPv6 assignments in the first years.

B. Impact of Policy on RIPE NCC Operations/Services

Although it is thought to be unlikely, there is still the possibility that if the proposal 2006-01 is accepted and it is implemented as a policy, the RIPE NCC would receive a large number of requests under this new policy in a very short time. Should this occur, the RIPE NCC will attempt to minimise the impact on its service level by evaluating the requests under this new policy in a separate queue from other requests. This might delay the evaluation of requests for IPv6 PI space slightly, but it will ensure prompt evaluation of all other requests.

References:

[1] ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest Link: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest

[2] The UNIX command "whois -M -h riswhois.ripe.net 0::0/0 |grep route6 |sort |uniq -c |wc" reports 1,858 unique IPv6 prefixes on 26 January 2009.

[3] ftp://ftp.ripe.net/pub/stats/arin/delegated-arin-latest Link: ftp://ftp.ripe.net/pub/stats/arin/delegated-arin-latest

[4] ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest Link: ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest



For this reason, this proposal comes with a fixed 'sunset' period, dependant upon the date when an alternative technically viable solution becomes available and is widely accepted by the Internet community.

A temporary /32 assignment should not be seen as a waste of address space. It would bring the advantage of removing a need for new special filters and avoiding renumbering to those that could become LIRs.

Acknowledgments:

I would like to acknowledge input received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts.