Changes to Provider Independent (PI) IPv6 Assignments for End User Organisations
|Legend||(+) Added||(-) Deleted|
|Changed||Tag Added||Tag Deleted|
insert: <b> This proposal introduced a solution for organisations that needed IPv6 Provider Independent (PI) address space. delete: </strong> delete: </p> insert: </b> insert: </p>insert: <h2>
insert: <b> Summary of Proposal: insert: </b> insert: </h2>insert: <div>
This policy is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments.delete: <p> Typically, such organisations will require the PI assignment to become Multihomed as happens for IPv4, but there may be other reasons reason behind requests. For example, some organisations This policy proposal is only trying to cover this type of PI assignments (for example data centers which 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 an ISP, or security reasons. In such cases, it seems that no other solution than PI assignments would currently be feasible. delete: <br /> delete: <br /> 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. delete: <br /> delete: <br /> 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. delete: </p> delete: <p> content providers). insert: </div>
Rationale: delete: </p> delete: <div> insert: </h2>
a. Arguments Supporting the Proposal delete: <br /> delete: <br /> insert: </p>insert: <p>
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. delete: <br /> delete: <br /> insert: </p>insert: <p>
This is currently not the case for IPv6, and is perceived as a clear barrier for its deployment of IPv6 in some organisations. This policy proposal addresses that barrier by means of providing a way to obtain a direct assignment from the RIPE NCC. delete: <br /> delete: <br /> insert: </p>insert: <p>
Any organisation receiving such an allocation assignment would not be allowed to make further assignments to other external organisations. They would organisations, but instead only be allowed to assign subnets internally within their own facilities. delete: <br /> delete: <br /> insert: </p>insert: <p>
Assigning a /32 would make those blocks behave as other regular LIR allocated ones. They would ones and 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. delete: <br /> delete: <br /> insert: </p>insert: <p>
By setting up this policy, we would avoid creating an unfair situation among different regions, and meet the needs of any organisation that required PI address space. All organisations that opt for PI space, would this PI, will be in an equal position once the community agrees a long-term technical solution and would will have to either move to this new solution or become an LIR, if they qualify. Newcomers would will also be in the same position. Some organisations would will not opt for PI space under this policy as because they would do not need it. This would avoid placing them in an unfair situation. delete: <br /> delete: <br /> 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. delete: <br /> delete: <br /> 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. delete: <br /> delete: <br /> 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. delete: <br /> delete: <br /> insert: </p>insert: <p>
b. Arguments Opposing the Proposal delete: <br /> delete: <br /> insert: </p>insert: <p>
The possible effect of this proposal is a growth of global routing tables to levels that, together with 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. delete: <br /> delete: <br /> 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. delete: </p> delete: <p> A temporary /32 assignment should not be seen as a waste of address space. insert: </p>insert: <p>
It would bring the advantage of removing a need for new special filters and avoiding renumbering to those that could become LIRs. delete: </p> delete: </div> delete: <hr /> delete: <p> delete: <b> Acknowledgments: delete: </b> delete: </p> delete: <div> delete: <p> I would like to acknowledge input received for the first version of this proposal from Marcelo Bagnulo and Lea Roberts. delete: </p> delete: </div> delete: </div> is expected that organisations requesting an IPv6 PI prefix under this policy, which may need in the future a standard PA block, will apply for that according to existing policies and will need to renumber. insert: </p>
Qualification for an IPv6 Provider Independent (PI) Assignment:
To qualify for a direct assignment, the organisation must become a RIPE NCC member Local Internet Registry (LIR) or have a similar contractual relation (to be defined by the board) with the RIPE NCC (to be defined by the board) and must demonstrate a need for an allocation demonstrate, by means of IPv6 address space. showing contracts, that is going to be multihomed. The PI assignment can’t be further assigned to other organisations.
PI IPv6 Assignment Size to End User Organisations:
The minimum size of the assignment is /32. /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified.
Subsequent Assignment Size to End User Organisations:
Whenever possible, further assignments will be made from adjacent address blocks, but only if duly documented and justified.
Assignment 'Super Block':
Assignments will be allocated from a separate 'super block' to allow LIRs to filter them, if required.
Expiry for Assignments: delete: </b> delete: <br /> Assignment blocks made under Note: insert: </b> This note is not part of the policy statement and should be removed at implementation time. It is required, in order to implement this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date policy, that the board defines the contractual relation, either being a LIR or an alternative technically valid and deployable solution becomes available and is accepted by the one. The policy statement “must become a Local Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix. delete: </p> Registry (LIR) or have a similar contractual relation (to be defined by the board) with RIPE NCC” will be adapted to refer to the contract defined by the board. insert: </p>