This policy proposal has been accepted
You're looking at an older version: 1
The current (published) version is 2Luckily more and more people are (thinking about) deploying IPv6 in their networks. Some of these networks may already have IPv4 PI assignments and are already being multi-homed and/or independent from one entity providing upstream services – and wish to continue a multi-homed setup for IPv6. Some may want to rethink old habits of IPv4 networking and start fresh, independent and multi-homed for IPv6. The community should encourage and support people who are doing so.
Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers’ sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix. Strictly following the current RIPE policy regarding eligibility for IPv6 PI space, organisations aren't allowed to be provided with PI space when this is the case.
As a consequence, people may opt to postpone an IPv6 migration, be unspecific or less honest when answering the RIPE NCC’s questions, or to become an LIR or ask an existing LIR for less flexible PA space and possibly encounter problems with multi-homing. None of these options are ideal.
As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter).
This interpretation seems rather extreme and history shows that it's not even shared by every member of the RIPE NCC. As discussed at the Address Policy WG during RIPE 72, there have been some other Freifunk communities as well as others getting allocations for the same usage patters. Even the IPv6 prefixes used on the WIFI at RIPE 72 were ASSIGNED-PI. So currently there's an unequal treatment of people being honest and specific in what they want to do and those giving only high-level, incomplete, or even wrong answers to the RIPE NCC when requesting IPv6 PI.
Being more specific in the policy about what a sub-assignment is and setting it to a “/64 or shorter” solves this problem in a simple way and will help a number of (not only non-profit) organisations to smoothly design and set up independent and multi-homed IPv6 networks. Disallowing sub-assignments for “/64 or shorter” will still prevent ISPs from using “cheap” PI space for their subscribers.
To qualify for IPv6 PI address space, an organisation must 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”.
The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.
[...]
[...]
The details of any such contracts are outside the scope of this document.
However, at the minimum, all contracts must include:
[...]
* Notice that none of the provider independent resources may be sub-assigned to a third party
[...]
To qualify for IPv6 PI address space, an organisation must 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”.
Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.
The RIPE NCC will assign the prefix directly to the End User organisation upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.
[...]
With this clarification in place, there will be no more room for interpretation regarding whether using PI space in (public) WIFIs or installations is in conflict with the policy. As a /64 is the smallest meaningful prefix length to use in non-PTP links, there should be no worries of people misusing PI space for sub-assigned customer prefixes.
This will even resolve some current policy violations – depending on the interpretation of the current policy – and avoid further ones regarding this point. This may even help to further IPv6 deployment, as there seem to be some people and organisations who would like to use IPv6 PI space but have been denied.
Although the IPv6 address space is huge, it's still finite. Users only needing a /48 (or less) for their organisations would also block a full /29 prefix when forced to become LIRs. This seems unproportional.
The boundary of "/64 or shorter" has been chosen as this is the smallest meaningful prefix for IPv6. In theory, this policy change allows people to hand out /80 or smaller prefixes to their users/customers, but the risk of IPv6 PI misuse seems to be rather low here. Prefixes longer than a /64 are of no big use in reality and nobody in their right mind would use such a prefix for their paying users.
Increasing the number of PI assignments probably will increase the number of entries in the global v6 routing table. Some people might worry about an increase in the table size in the foreseeable future. Not going forward with this policy change will likely result in people getting /48 to /40 sub-assignments from an LIR or maybe becoming LIRs themselves, resulting in at least the same number of routes, maybe even more (aggregate routes for the PA space + sub-assignments).
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 for IPv6 PI assignment requests, subnets in the addressing plan smaller than a /64 will be exempt from being considered sub-assignments.
The RIPE NCC has been receiving an increasing amount of IPv6 PI requests where an organisation plans to use IPv6 PI to provide connectivity or other services to End Users with a /128 or other small prefix for each customer. If this policy change is accepted, the RIPE NCC will provide IPv6 PI assignments to these requesters, provided no subnets of a /64 or larger will be provided to entities outside of the requesting organisation.
While this policy change will likely help with the deployment of IPv6 for organisations that provide services to customers, some side effects should be noted:
If this proposal is accepted, organisations with services that include the provision of small amounts of IPv6 per customer can request IPv6 PI, resulting in an expected increase of IPv6 PI assignments. Currently the RIPE NCC assigns around 250 IPv6 PI assignments per year, the vast majority of which are a /48. Some organisations that would become LIRs and request an IPv6 allocation (minimum size /32) under the current policy, might instead choose for an IPv6 PI assignment instead (minimum size /48). This would have a slowing effect on the overall IPv6 consumption rate.
Overall, the RIPE NCC estimates that neither of these effects will have a significant impact on the RIPE NCC IPv6 pool.
A faster processing of IPv6 PI requests is expected by Registration Services, as evaluation will focus on the requester’s documentation and that no sub-assignments of /64 or bigger will be provided to other organisations.
The RIPE NCC might need to spend more effort during request evaluations, training and other outreach activities to explain the importance of sufficient subnet sizes for customers and the relevance of RFC recommendations for the deployment of IPv6.
With the information currently available, it is expected that implementation of the proposal would have a low impact in terms of the software development needed to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.