Preamble: The primary focus of this proposal was the IPv6 PI related part of the address policy. During the development of the proposal, as we discussed various ideas on how to move forward in the process, the idea emerged to broaden the proposal’s scope. This would serve to clarify and thereby unify both the meaning of the terms “assignment” and “sub-assignment” and the rules associated with these processes. The proposal thus aims to fix the current IPv6 PI policy with respect to sub-assignments and unify the terms for PA and PI space. Given the primary focus on IPv6 PI, large parts of this rationale are based on thoughts about PI space.
Luckily, doing so.Usually organisation networks today who are doing so.Today, organisation networks usually
There are several consequences to all this: As a consequence, people may opt to postpone IPv6 migration; they might be less specific an IPv6 migration, be unspecific or less honest when requesting IPv6 PI and answering related questions from the RIPE NCC; some might ask answering the RIPE NCC’s questions, or to become an LIR, LIR or ask an existing LIR for less flexible PA space, leading to potential space and possibly encounter problems with multi-homing. All these courses of action are problematic and none of them represents the best solution. A strict interpretation of Section 2.6 of ripe-684 might even disallow the use of a PA assignment from an LIR for use in public WIFIs, etc. None of these options are ideal.
As an example, some Freifunk Communities in Germany have been declined PI space had their PI request declined because some 1-digit-number of subnets would have been used as a v6 prefix in IPv6 prefixes on public WIFIs. This usage of the IP space in an end-user’s the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "(sub-)assigned" "assigned" to a user device within of the public WIFI network as the device would get an IP address via SLAAC (or any other means, 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 in the AP-WG meeting, at RIPE72 and RIPE74, 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 patterns. patters. Even the IPv6 prefixes at RIPE72 to RIPE74 WIFI had been ASSIGNED-PI – as the RIPE NCC cannot become a member of itself. As a result, there's currently 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.
Explicitly allowing another entity to be provided with addresses from a subnet operated by the assignment holder 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 - for both IPv6 PI and PA assignments - and will help a number of (not only non-profit) organisations to smoothly design and set up independent and multi-homed IPv6 networks. Sub-assignments for networks (= whole subnets) that are not under the control of the assignment holder are still not allowed, which Disallowing sub-assignments for “/64 or shorter” will still prevent ISPs from using “cheap” PI space for their subscribers. A subnet in the spirit of this policy is a prefix from the PI/PA assignment with a prefix length of /64 or longer according to current IPv6 standards and BCPs.
Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal.
To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.
[…]
[...]
The PI assignment cannot be further assigned to other organisations.
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 “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.
Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.
[…]
[...]
The PI assignment cannot be further sub-assigned to other organisations.
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 place, there will be no more room for interpretation regarding whether using PI space in (public) WIFIs or installations alike will be 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 that this point. This may even help further IPv6 deployment to further IPv6 deployment, as there seem to be some people / and organisations who would want 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 organisation organisations would also block a full /29 prefix when forced to become LIR which seems unproportioned. LIRs. This seems unproportional.
This proposal consciously opens up the allowed use cases for IPv6 PI space - the intention is to spread IPv6 deployments. One could argue that some of the newly allowed use cases will prevent people from becoming an LIR which they should then providing hosting/housing services etc. This isn't considered a great risk.
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 /48 to /40 sub-assignments from an LIR or maybe become an LIR of their own becoming LIRs themselves, resulting in at least the same number of routes, maybe even more (aggregate routes for the PA space + assignments + TE prefixes e.g.). 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
an IPv6 assignment, the provision of separate addresses to customers of the assignment holder will not be considered a sub-assignment. In IPv6 terms, a single address is a /128. There are cases where a /64 is needed per customer to provide a separate address, for instance by using dedicated (v)lans to connect Wifi customers or other configuration mechanisms Link: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 discussed in the technical community. The RIPE NCC will consider such mechanisms as being in line with this policy and not a sub-assignment as long as the subnet size does not exceed a /64.
It is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time. Any permanent and static assignments of a prefix would still be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans.
This definition of sub-assignments will apply for assignments within IPv6 allocations and for IPv6 Provider Independent (PI) Assignments. other entities.This entities outside of the requesting organisation.While this
customers. Further this new proposal version addresses several side effects that would have occurred with the previous version. For example, there is no longer a difference between sub-assignment rules for PI assignments and assignments within allocations. The risk of conflicts with several RFCs has also been minimised.It should be noted that with this policy change, as with the current policy, there is still the risk that the requesting party customers, some side effects should be noted:
Further it is possible that, despite the intention of the proposer, broadband providers will request and receive IPv6 PI assignments as long they comply with the requirement to only provide separate addresses to customers.
To use an extreme example, even a broadband provider with millions of customers would qualify for an IPv6 PI assignment as long as he would follow the policy requirements. While the RIPE NCC cannot predict how many of such requests it will receive, there is the potential that broadband providers will provide too little IPv6 space to their customers, only to qualify for IPv6 PI assignment instead of using allocated address space.
The RIPE NCC would make any such requester aware that such IPv6 deployment is against IPv6 best current practices and the intent of this policy change, but ultimately it could not deny such an IPv6 PI request.
If this proposal is accepted, organisations with services that include the provision of separate IPv6 addresses to customers 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 opt 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.
An increase of approved A faster processing of IPv6 PI requests is expected by Registration Services, as evaluation will focus on the requester’s documentation and the condition that no prefixes that no sub-assignments of /64 or bigger will be provided to other organisations.
The RIPE NCC might need to exert spend more effort during request evaluations, training and other outreach activities to explain the
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.