Revised IPv6 PI Assignment Policy

Summary of the Proposal

This proposal aims to reduce the operational burden that operators experience when working with PI. It also clarifies some long-standing issues in the IPv6 addressing policy. Specifically, it makes the following changes:

• Separates assignment requirements for ‘PI assignments’ from ‘assignments from IPv6 allocations to End Users’.
• Clarifies permitted and non-permitted use cases of PI assignments.
• Clarifies wording, definitions, and requirements in the text.
• Introduces PI assignments at the nibble boundary, an aggregation principle for PI, and registration in a single object for assignments.

Policy Text

2.6 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.

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.

2.6 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 that they operate. Assignments must only be made for specific purposes documented by specific organisations, and it is not allowed to fully or partially sub-assign them to another entity.

Providing connectivity to another entity inside the assignment holder’s network, at the same geographical End Site, with a prefix size of /56 or longer from the assignment, is not considered a sub-assignment. This includes letting visitors connect to the assignment holder's network, providing persistent addresses when connecting a server or appliance to the assignment holder's network, providing a single service with multiple addresses, or using a /64 or longer when setting up point-to-point links with other ISPs for the purpose of exchanging traffic and Internet routing information.

Finally, using more specific prefixes from a less-specific assignment for different parts of the same infrastructure within one organisation does not constitute a sub-assignment, provided the purpose of the assignment is the operation of that infrastructure. Any other use of a prefix from an assignment (up to prefixes of /128) to connect the separate End Site of another entity to the Internet without the exchange of Internet routing information constitutes a prohibited sub-assignment.

5.4 Current policy text

5.4 Assignment

5.4.2. Assignments shorter than a /48 to a single End Site

Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments.

5.4 New policy text

5.4 Assignments from IPv6 allocations

5.4.2. Assignments shorter than a /48

Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a /48 in total must be based on address usage or routing requirements.

7.1 Current policy text

7.1 IPv6 Provider Independent (PI) Assignment Size

The minimum size of the assignment is a /48.

The considerations of “5.4.2. Assignments shorter than a /48 to a single End-Site” must be followed if needed.

7.1 New policy text

7.1 IPv6 Provider Independent (PI) Assignment Size

PI assignments always have a prefix size longer than the minimum allocation size. The longest prefix size for PI assignments is a /48.

When requesting an assignment with a prefix shorter than a /48, an additional assignment, or an extension of an existing assignment to a size larger than a /48, the need must be justified – for example, by documenting each End Site’s current and/or planned routing policies, or expected utilisation (see 2.7) within the next 24 months.

7.1.1. PI Assignment at the Nibble Boundary

To aid aggregation and reduce the need for renumbering in case of growth, justified assignments are to be made in nibble boundary steps (i.e. starting with /48, followed by /44, /40, and /36, in steps of 4 bits). This means that an End User demonstrating the need for at least two /48s, e.g. due to two End Sites, should receive a /44, and an End User demonstrating the need for at least seventeen /48s, e.g. due to seventeen End Sites, should receive a /40, etc. It is recommended that RIPE NCC reserve the address space up to the next nibble boundary whenever a PI assignment is issued.

More specific prefixes from an assignment may be individually routed, as long as no sub-assignment takes place.

7.1.2. Requesting a Larger Assignment

If an End User or LIR already holding one or more PI assignments needs additional address space, they must submit a request for an extension to the next nibble boundary satisfying the new needs.

Such an extension can be granted if the policy requirements are met and if there is sufficient available space contiguous to the existing assignment.

If the requested extension to the next nibble boundary cannot be made, the assignment holder may request a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment(s) within a six-month renumbering period.

Rationale

a. Motivation for the Proposal

The purpose of this proposal is to reduce the operational overhead of PI assignment requests for End Users, LIRs, and RIPE NCC Registration Services. This overhead is mostly due to ambiguity in the current policy text, leading to a PI assignment maximum size of /48 per End Site. In turn, this leads to deaggregation of the routing table and cluttering of the RIPE Database if, e.g., routing requirements necessitate more independently routable prefixes. It also results in increased load on the RIPE NCC, as these are currently handled via multiple assignments.

Furthermore, the proposal aims to clarify use cases of PI that are currently either prohibited—despite being reasonable—or use cases where it is unclear whether they are permissible. This proposal explicitly enables reasonable uses, while restricting the non-desirable ones, e.g., hoarding or the use of PI for general broadband services.

Finally, by working with a nibble-boundary approach, the proposal enables a more structured handling of address space, preventing deaggregation in case of growth.

Purposes

• Clarifying PI assignment scope
  • Assignment holders may assign more than a single IPv6 address (/64) for custom servers/VMs within their End Site, persistent prefixes and routable prefixes.
  • Explicitly prohibit PI assignments from being used to connect remote customer End Sites (except for p2p links to other ISPs).
  • Remove the implicit need for addresses used for interconnectivity to be on a shared prefix, i.e., the shared link can be numbered with LL addresses and a /128 (or /64).
• Distinguishing assignment types and sizes
  • Make a clear distinction between PI assignments and allocation-based assignments.
  • Set a standard minimum size (/48 or longer) and a maximum size limit (/36) for PI assignments.
  • Define a path to qualify for shorter prefixes based on documented addressing needs or requirements due to the presence of multiple End Sites.
• Clarifying End Site use-cases and documentation requirements
  • Address the current discussion around what constitutes an End Site in L2 interconnectivity scenarios. The definition of End Site initially proposed under 2.9 will be spun off into a separate policy proposal to avoid confusing discussion of this proposal.
  • Specify documentation requirements for End User justification, including technical need and infrastructure requirements.
• Streamline PI assignment request process
  • Provide a structured process for large assignment requests to avoid de-aggregation and reduce the need for renumbering in case of growth by following nibble boundaries.

Considerations

• Operational risk management
  • Controlled risk of PI misuse for residential customers or hosting businesses through size limitations, End Site requirements and explicit prohibition of customer connection.
• Following technical best practices
  • Aligning on /64 as the standard prefix size for end devices.
  • Explicitly permitting server usage to clarify previous policy ambiguity.
  • Allow addressing scheme flexibility while maintaining routing efficiency.
• Policy evolution
  • Retained legacy concepts such as “address usage” and ”addressing needs” for continuity.
  • Future policy updates may address modernised addressing metrics, nibble boundary adjustments and general IPv6 allocation policy revisions.
• Routing efficiency
  • Balance operational flexibility and routing table management to prevent deaggregation.
  • Introducing an aggregation principle, suggesting renumbering requirements and size limitations relative to allocation sizes.

b. Arguments Supporting the Proposal

In the discussions prior to this version of the proposal, the following supporting arguments were made:

• There are use cases that benefit from more than one routable prefix. At the moment, these are serviced with multiple, often subsequent, assignments, leading to increased deaggregation and fragmentation of the address pool, as well as cluttering the database. This proposal mitigates that.
• The proposal strives to prevent renumbering in case of growth, even if requirements change.
• The proposal ensures that PI cannot be easily hoarded, as unused assignments must be returned to the RIPE NCC, preventing transfers.
• The proposal more explicitly addresses the issue of PI being abused for providing ISP services, while not limiting reasonable use cases previously included in the intent of the policy but prevented by the wording (e.g., public Wi-Fis and assigning prefixes shorter than /128).
• Fewer requests will be necessary if an End User has already received an assignment longer than a /48 and only needs one additional prefix.

c. Arguments Against the Proposal

In the discussions prior to this version of the proposal, the following counterarguments were made:

• Allowing for larger PI assignments might lead to ISPs being inclined to utilise PI for, e.g., Broadband services.
  • Counterargument: the proposal introduces several points where these uses are explicitly prohibited.
• Reserving up to the next nibble boundary is wasting address space.
  • Counterargument: at the moment, a /46 is usually reserved for a /48 PI assignment, already leading to comparable address space utilisation (1/4 of, but with the same level of deaggregation). Furthermore, each subsequent request that can be satisfied by the reservation, or that is not necessarily due to the initial assignment’s size, preserves address space and, more importantly, reduces deaggregation.
• The load on the RIPE NCC might increase due to an influx of requests by End Users wanting to aggregate their existing prefixes.
  • Counterargument: the authors acknowledge that, especially initially, the proposal may temporarily increase load while also necessitating changes to existing management systems. However, the load should be significantly reduced over the long term by streamlining evaluations. Furthermore, the included growth potential of assignments reduces overhead in case End Users’ requirements increase only slightly, up to a point where several individual requests for additional assignments are no longer necessary.
• End Users might request unreasonably large assignments by presenting untruthful information about End Sites.
  • Counterargument: given the challenges of the current PI policy in operational practice, the truthfulness of requests already can be improved. The purpose of this proposal is ensuring that lying is no longer necessary to receive required resources, while making it more difficult to lie in order to receive more resources than necessary. This includes scoping the extent of impact, as well as database clutter, when non-truthful assignment requests are actually successful despite best efforts.
• It is no longer possible to hold PI in multiple prefixes for, e.g., multiple different purposes.
  • Counterargument: while this argument is correct, the reason for not permitting this is the trade-off between encouraging (re-)aggregation and the added freedom of these use cases. Given the limited number of End Users holding multiple PI assignments with specific purposes, this is considered an acceptable trade-off by the proposer.
• Allowing larger PI assignments might lead to PI assignments of arbitrary size being possible.
  • Counterargument: in the newest version of the proposal, the size of PI assignments is limited to always be more specific than the most specific allocation. At the time of writing, this would be a maximum PI size of a /36.

Note: To provide additional information on the proposal, details of the RIPE NCC's impact analysis are provided below. The projections presented in this analysis are based on existing data. They should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

Executive Summary

The RIPE NCC assesses that the implementation of this proposal would have a high operational impact. Significant software development, process changes, documentation updates, and staff training would be required to replace the current IPv6 policy framework and support the new policy requirements.

The proposal, if accepted, would also introduce several policy requirements for IPv6 PI assignments and assignments made from IPv6 allocations that the RIPE NCC would not be able to efficiently verify, monitor, or enforce. This could reduce the accuracy and reliability of Registry data and create uncertainty regarding resource usage and responsibility.

In addition, the RIPE NCC has identified areas where further community guidance would be beneficial for defining policy interpretation, compliance expectations, treatment of existing assignments, and the intended handling of renumbering and transfers. Clarifying these aspects would help ensure consistent implementation and alignment with the proposal's objectives. More details are available in section “E. Implementation” below.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC’s understanding that this proposal, if accepted, will:

1. Change the allowed usage of IPv6 assignments (2.6)
2. Change the rules for making IPv6 assignments from allocations (5.4)
3. Set a maximum IPv6 PI size and require justification for >/48 (7.1)
4. Introduce new rules for determining the IPv6 PI assignment size (7.1.1)
5. Change the practice for assigning additional IPv6 PI space (7.1.2)

More in detail:

1. In ‘2.6 Assign’:
The following would apply to assignments made from IPv6 allocations and to IPv6 PI assignments directly made by the RIPE NCC to LIRs and End Users:

• Distributing subnets up to a /56 from the IPv6 assignment to separate entities would be allowed, but only if co-located.
• Using any address from IPv6 assignments to connect remote End Sites of separate entities would no longer be allowed (e.g. stretched p2p links, or hub-and-spoke VPNs, etc) unless this is realised with dynamic routing protocols.

2. In ‘5.4. Assignment from IPv6 allocations’:

• Instead of one /48 per End Site or separate routing policy, LIRs would be allowed to issue a single aggregated IPv6 assignment in case of multiple End Sites and routing instances.

3. In ‘7.1 IPv6 Provider Independent (PI) Assignment Size’:

• The maximum size of IPv6 PI assignments would be set at a /36, the nibble boundary smaller than the minimum IPv6 allocation (currently a /32).
• Utilisation needs for assignments exceeding a total of a /48 would need to be justified by a 24-month implementation plan.

4. In ‘7.1.1. PI Assignment at the Nibble Boundary’:

• Network growth would become a valid justification for requesting IPv6 PI assignments larger than a /48.
• The RIPE NCC would issue IPv6 PI assignments with the first nibble boundary prefix length that would satisfy the requester’s justified addressing needs.
• For each issued assignment, it is recommended that the RIPE NCC reserves contiguous space up to the next nibble boundary.

5. In ‘7.1.2. Requesting a Larger Assignment’:

• On approval of any request for additional IPv6 PI address space, including transfers, the RIPE NCC would issue a single assignment with a prefix at the first nibble boundary that would satisfy the new justified needs.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

After analysing currently available data, the RIPE NCC anticipates a higher consumption of IPv6 addresses due to:

• The larger size of the assignments being issued at the nibble boundary.
• The valid justification, including future growth and the provision of subnets up to a /56, to customers, visitors, or entities inside the assignment holder's network.
• The temporary holdership of existing and newly assigned IPv6 PI address space to allow renumbering.
• The sparse allocation behaviour resulting from the recommended reservation of contiguous space up to the next nibble boundary.

Fragmentation/Aggregation:

• The RIPE NCC does not anticipate a reduction of the global routing table size if this proposal is accepted, as it still allows the separate routing of more specific prefixes from IPv6 PI assignments.
• With more space available, organisations might even be less motivated to optimise the use of their PI space for aggregation, preferring de-aggregation due to traffic engineering.
• The proposal only mandates the return of existing PI space. It would still be possible to immediately transfer the newly assigned PI space, which is expected to undergo partial transfers. This would cause fragmentation of the blocks originally assigned at nibble boundaries, making the reservations unusable for extensions.

C1. Impact of Policy on RIPE NCC Operations/Services

Software Engineering:

Software development would be needed to update our systems to:

• Allow the extension of IPv6 PI assignments
• Set a maximum size for IPv6 PI assignments
• Check the holdership of previously assigned PI space;

and possibly:

• Create the reservation of contiguous space as recommended by the proposal
• Change the RIPE Database business rules to create hierarchically lower objects within assignments.

Registration Services:

If this proposal is implemented, the RIPE NCC Registration Services anticipates an increased short-term ticket volume due to:

• Requests for additional IPv6 PI address space to expand to nibble boundaries. We expect that End Users with one End Site, holding a single /48, will request additional space (e.g., for redundancy or disaster recovery) and request a /44, where we are recommended to reserve a /40.
• Requests for replacing multiple assignments with a single assignment at the nibble boundary.
• Addressing a needs evaluation (24-month implementation plan) for the above mentioned request.
• Monitoring the renumbering status of existing PIs after assigning a new PI block at the nibble boundary.
• A higher number of PI transfer requests, as no constraints were suggested by this proposal on transferring parts, or all, of the newly assigned PI space.
• Clarification requests from (sponsoring) LIRs that might challenge the RIPE NCC’s evaluation based on the new policy:
  - When requesting new PI assignments for purposes allowed by the previous policy.
  - When required to document the need justification as per 7.1
  - When required to renumber existing assignments, even if the actual addressing needs could be satisfied by the currently available contiguous free space (e.g. when a holder of a /48 needs only an additional /48, the current /46 reservation would not be sufficient for the extension at the nibble boundary /44). This would happen for most of the existing PI assignments.
  - About the disparity between the justified needs and the issued space intrinsic in aligning sizes on nibble boundaries: one End User with two End Sites and one End User with 16 End Sites would both receive a /44 with a /40 reservation, while one End User with 17 End Sites would qualify for a /40 with a /36 reservation.

Given that there is a negligible number of requests for additional IPv6 PI space at the moment, we do not expect this policy to bring about a significant workload reduction in the long term.

Temporary duplicate registration of inet6nums in the RIPE Database during the renumbering period might be confusing and lead to reports and complaints.

Learning and Development:

If this proposal is accepted, Learning and Development training and exam content would need to be updated, specifically the:

• LIR Fundamentals courses (in-person and e-learning)
• LIR Fundamentals certification exam
• IPv6 Fundamentals courses (in-person and e-learning)
• IPv6 Fundamentals certification exam

C2. RIPE NCC Board’s input

The RIPE NCC Executive Board strongly advises that the proposers revise the proposal based on the analysis in this document.

D. Legal Impact of the Policy

Under the current ‘IPv6 Address Allocation and Assignment Policy section 2.6. Assign’, assignments can be made to ISPs or End Users ‘for specific use within the Internet infrastructure they operate.’ With regard to the proposed changes, under ‘2.6 Assign’, if the proposal is accepted, assignment holders would be allowed to sub-assign IPv6 address space to an entity at the same ‘geographical End Site’ as them.

Considering that in ‘Section 2. Definitions’, there is no distinction made between ‘assignments from allocations’ (or else ‘PA assignments’) and ‘assignments from IPv6 allocations to End Users’ (or else ‘PI assignments’), we see that the rule would apply to both IPv6 PA and PI assignments.

In relation to IPv6 assignments in section 2.6, we want to flag two issues where we recommend relevant parts in the policy proposal be amended to avoid any future confusion on how to implement the policy if the proposal is adopted:

a) Reading the proposed Section 2.6 and Section 7 of the current IPv6 policy, we see a discrepancy: under the proposal, sub-assignments of IPv6 PI space would be allowed under certain conditions, whereas under Section 7 of the IPv6 policy, ‘the PI assignment cannot be further sub-assigned to other organisations.’

b) Reading the proposed Section 2.6 in conjunction with Section 7.2 of the current IPv6 policy, we understand that IPv6 PI assignments made to a member (LIR) as part of its infrastructure would not be allowed for ‘customer End Sites’ even if these were colocated.

We would also like to note that the policy proposal allows End Users to create sub-assignments from PI blocks. If an End User decides to become a member, these sub-assignments would no longer be compliant with Section 7.2 and therefore not allowed.

On another topic, guidance will be required on how to enforce and monitor compliance with the colocation requirement as the term ‘geographical End Site’ is not strictly defined. Is the entity receiving connectivity required to be at the same location as the assignment holder intended, such as country, city, address or building level?

Guidance would also be required on what the RIPE NCC is expected to do if the ‘expected utilisation’ does not happen within the next 24 months under the proposed change under Section ‘7.1 IPv6 Provider Independent (PI) Assignment Size’. Is it expected that the RIPE NCC would take steps to have the extension/additional assignment deregistered?

Under the proposed Section ‘7.1.2. Requesting a Larger Assignment’, “If the requested extension to the next nibble boundary cannot be made, the assignment holder may request a new Assignment as per 7.1.1… and must return the previous assignments within a six-month renumbering period.’ If the policy proposal is accepted, the RIPE NCC would review whether it would be required to update any relevant documentation to cover this case explicitly. This would state that after the six-month renumbering period, the RIPE NCC would have the right to deregister the previous assignment and follow the standard procedure for this.

E. Implementation

If the proposal is accepted, a new policy document, ‘IPv6 Address Allocation and Assignment Policy,’ would obsolete the current document (ripe-738).

Based on the information currently available, implementing this proposal would have a high impact on software engineering as software development would be needed to facilitate the policy changes in the RIPE NCC’s internal systems.

Internal and external processes and documentation, including training and exam materials, would also need to be updated and approved internally before publication.

If this proposal is accepted, it would require significant effort for the RIPE NCC to verify, monitor, and enforce compliance with some of the new policy requirements. Assigned IPv6 PI space could be used in the same way as allocations, without this being clearly reflected in the RIPE Database through proper registration, affecting the accuracy and reliability of Registry data, making it more difficult to keep track of actual usage and responsibility.

To avoid ambiguity in the policy interpretation and develop new procedures for handling IPv6 assignment-related requests that accurately reflect the proposal’s intent, the RIPE NCC invites the community to provide guidance during the next steps of the Policy Development Process on the following aspects.

Conflicting policy text:

Issuing IPv6 PI address space at the nibble boundary (7.1.1) would mostly provide an address range that is only partially utilised, similar to allocations.

As the specific purposes would not be documented when the assignment’s free space was used, this appears to conflict with ‘2.6 Assign’:

“Assignments must only be made for specific purposes documented by specific organisations, and it is not allowed to fully or partially sub-assign them to another entity.”

Alignment with previous policies:

The proposal removes the option to use IPv6 assigned space to provide connectivity to external devices. We expect some of the existing assignments would not be compliant with the new policy if this proposal is accepted.

Compliance:

1. It would require significant administrative effort for both the RIPE NCC and the resource holder to verify or monitor that the End Sites and the routing policy are implemented as documented in the request.
2. It would require significant administrative effort for both the RIPE NCC and the resource holder to verify compliance with the colocation requirement of third-party equipment and the prohibition on providing connectivity using the IPv6 assigned blocks.
3. The consequences of a partial or incomplete implementation after 24 months of the plan provided at the time of the request are unclear.
4. Enforcing the return of the existing PI space as mandated by the proposal might have unintended consequences if the renumbering is incomplete or undone after six months.
5. If non-compliance with any of the above policy requirements is identified, for example during an audit or after the defined periods have passed, the RIPE NCC would face a difficult choice: either enforce the applicable closure and deregistration procedures, potentially leading to resource deregistration and, in some cases, termination of RIPE NCC membership, which may be disproportionate to the nature of the violation; or tolerate the non-compliance for an undefined period, which would weaken the overall credibility of the IPv6 policy and the policy compliance and enforcement done by the RIPE NCC.
6. It is unclear whether the proposal suggests modifying the RIPE Database business rules to register hierarchically lower objects with specific contacts for each End Site, third party and routing policy in the RIPE Database.

Policy intent:

The intent of the proposal is to have different procedures in place:

1. If sufficient contiguous space is available, and the provided documentation justifies the request, one existing assignment would be extended (no return or transfer block will apply)
2. If sufficient contiguous space is not available, existing IPv6 PI assignment(s) would become non-transferable. After receiving a new assignment, renumbering must be completed and the previous PI assignment(s) must be returned within six months. Considering the current reservations, a request for additional PI space will require renumbering in almost all cases and might be highly impactful and time-consuming for network operators. The consequences of the incomplete or undone renumbering of existing assignments after six months are unclear.
3. As per ripe-807, “Transferred resources are no different from allocations or assignments made directly by the RIPE NCC and so must be used by the receiving party in accordance with the respective policy documents.”, if the proposal is accepted, the new policy would also apply to PI transfer requests.