Changes to Provider Independent (PI) IPv6 Assignments for End User Organisations
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
This proposal introduced a solution for organisations that needed IPv6 Provider Independent (PI) address space.
Summary of Proposal:
This policy is intended to provide proposal introduces a solution for organisations that need IPv6 Provider Independent (PI) assignments. delete: </p> Typically, such organisations will require the address space. insert: </p>
insert: </div>The PI assignment to become Multihomed as happens for IPv4, but there may cannot be further assigned to other reason behind requests. This policy proposal is only trying to cover this type of PI assignments (for example data centers which are not an ISP, or content providers). organisations. insert: </p>
insert: <div>insert: </p>
Rationale:
insert: <div>a. Arguments Supporting the Proposal
In IPv4, At the moment 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: </p> delete: <p> This is currently not the case for IPv6, and no solution for the End User Organisations which require redundancy in IPv6. This is perceived as a clear barrier for deployment of IPv6 in some organisations. This policy proposal addresses that barrier by means of providing a direct assignment from the RIPE NCC.
Any organisation receiving such an assignment would not be allowed to make further assignments to All the other external organisations, but instead only to assign subnets internally within their own facilities. delete: </p> delete: <p> Assigning a /32 would make those blocks behave as other regular LIR allocated 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: </p> delete: <p> regions already have a policy for IPv6 PI address space. insert: <br />
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 this PI, the IPv6 PI address space will be in an equal position once the community agrees a long-term technical solution and will have to either move to this new solution or become an LIR, if they qualify. Newcomers will also be in the same position. Some organisations will not opt for PI under this policy because they do not need it. This would avoid placing them in an unfair situation.
b. Arguments Opposing the Proposal
The possible effect of this proposal is a the growth of the global routing tables to levels table to a level that, together with the existing and forecast forecasted 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.
It 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. delete: </p> insert: </p>
insert: </div>insert: <i> [Following text is to appear in the RIPE Policy document, IPv6 Address Allocation and Assignment Policy for the RIPE NCC Service Region if the proposal reaches consensus.] insert: </i> insert: </p>
insert: <h3>New: insert: </h3>
Qualification for an IPv6 Provider Independent (PI) Assignment: Assignments: delete: <br /> insert: </p>
insert: <p> To qualify for a direct assignment, the an IPv6 PI address space, an organisation must become a Local Internet Registry (LIR) or have a similar contractual relation (to be defined must: insert: <br />
a) not be an IPv6 LIR; insert: <br />
b) demonstrate that it will be multihomed (for example by the board) with RIPE NCC and must demonstrate, showing contracts of the peering partners) insert: <br />
c) meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region” insert: </p>
The prefix will be assigned by means of showing contracts, that is going to be multihomed. The PI assignment can’t be further assigned to other organisations. delete: </p> delete: <p> delete: <b> PI IPv6 Assignment Size to the RIPE NCC directly to the End User Organisations: delete: </b> delete: <br /> Organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. insert: </p>
insert: <p>The minimum size of the assignment is a /48. However, Organisations requesting a larger assignment (shorter prefix) can be provided if duly documented and must provide documentation justifying the need for additional subnets. insert: </p>
insert: <p>Additional assignments may also be made when there is a technical need demanding this or usage justified. delete: </p> delete: <p> delete: <b> Subsequent Assignment Size to End User Organisations: delete: </b> delete: <br /> Whenever When possible, these further assignments will be made from an adjacent address blocks, but only if duly documented and justified. delete: </p> delete: <p> delete: <b> Assignment 'Super Block': delete: </b> delete: <br /> block. insert: </p>
insert: <p>Assignments will be allocated from a separate 'super 'designated block' to allow LIRs to filter them, if required. delete: </p> delete: <p> delete: <b> Note: delete: </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 policy, that the board defines the contractual relation, either being a LIR or an alternative one. The policy statement “must become a Local Internet 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. delete: </p> facilitate filtering practices. insert: </p>