IPv6 Sub-assignment Clarification

Summary of Proposal

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, more and more people are (thinking about) deploying IPv6 in their networks. Of these, some may have IPv4 PI assignments and thereby already be multi-homed and/or independent from an entity providing upstream services. In such instances, a multi-homed setup would need to be continued for IPv6. In other instances, 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 doing so.

Usually organisation networks today include some kind of guest networks, (public) WIFI hot-spots in their offices, PNI or PTP-VPN links to customers sites, or anything alike 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.

There are several consequences to all this: people may opt to postpone IPv6 migration; they might be less specific or less honest when requesting IPv6 PI and answering related questions from the RIPE NCC; some might ask to become an LIR, or ask an existing LIR for less flexible PA space, leading to potential 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.

As an example, some Freifunk Communities in Germany have been declined PI space because some 1-digit-number of subnets would have been used as a v6 prefix in public WIFIs. This usage of the IP space in an end-user’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "(sub-)assigned" to a user device within 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 in the AP-WG meeting, at RIPE72 and RIPE74, there have been some other Freifunk communities as well as others getting allocations for the same usage patterns. 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 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 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 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.

Policy Text

a. Current policy text

2.6. Assign

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.

[…]

7. IPv6 Provider Independent (PI) Assignments

[...]

The PI assignment cannot be further assigned to other organisations.

b. New policy text

2.6. Assign

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.

[…]

7. IPv6 Provider Independent (PI) Assignments

[...]

The PI assignment cannot be further sub-assigned to other organisations.

Rationale

a. Arguments supporting the proposal

With this clarification in place there will be no more room for interpretation whether using PI space in (public) WIFIs or installations alike will be in conflict with the policy.

This will even resolve some current policy violations - depending on the interpretation of the current policy - and avoid further ones regarding that point. This may even help further IPv6 deployment as there seem to be some people / organisations who would want 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 would also block a full /29 prefix when forced to become LIR which seems unproportioned.

b. Arguments opposing the proposal

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.

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 become an LIR of their own resulting in at least the same number of routes, maybe even more (aggregate routes for the PA space + assignments + TE prefixes e.g.).

A. RIPE NCC's Understanding of the Proposed Policy

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 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.
While LIRs have to consider this definition when providing assignments, the RIPE NCC will apply this understanding during the evaluation of IPv6 PI requests and when reviewing assignments within allocations during a potential audit of an LIR.

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, by using single IPv6 addresses for End User devices and services. If this policy change is accepted, the RIPE NCC will provide IPv6 PI assignments to these requesters, provided no prefixes will be provided to other entities.

This policy change will likely help with the deployment of IPv6 for organisations that provide services to 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 might provide incorrect information about the amount of IPv6 they actually plan to provide to customers in order to receive IPv6 PI.

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.

B. Impact of Policy on Registry and Addressing System

If this proposal is accepted, organisations with services that include the provision of separate IPv6 addresses to customers 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 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.

C. Impact of Policy on RIPE NCC Operations/Services

An increase of approved IPv6 PI requests is expected by Registration Services, as evaluation will focus on the requester’s documentation and the condition that no prefixes will be provided to other organisations.

The RIPE NCC might need to exert more effort during request evaluations, training and other outreach activities to explain the intent of this policy change and its limits. The examples mentioned in the policy text will help the RIPE NCC for their educational activities. 

D. Implementation

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.