Summary of the Proposal

This proposal aims to reduce the operational burden that operators experience when working with PI. It also clarifies some operational burden operators working with PI experience, while clarifying 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 Separate notions of assignment requirements and End Sites for ‘PI Assignments’ and ‘Assignments from IPv6 Allocations to End Users’.
• Clarifies Clarify permitted and non-permitted use cases of PI assignments.
• Clarifies Assignments.
• Clarify wording, definitions, and requirements in the text.
• Introduces PI assignments at the nibble Introduce PI Assignments at the Nibble boundary, an aggregation principle for PI, and registration in a single object for assignments.
• Clarify how to handle assignments issued before the implementation of this proposal.

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, organisations, and it is not allowed to fully or partially sub-assign them to another entity. create further sub-assignments to another entity from address space partially or fully covering an assignment.

Providing connectivity to another entity inside the assignment holder’s network, network located at the same geographical End Site, Site as the holder’s network with a prefix size of /56 or longer from the assignment, assignment is not considered a sub-assignment. This includes letting visitors connect to the assignment holder's network,providing persistent static addresses when connecting a server or appliance to the an 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 if the purpose of the assignment is the operation of that infrastructure. Any other use of a prefix from an assignment (up up to prefixes of /128) to connect the /128 bit to connect a separate End Site of another entity to the Internet without the exchange of Internet routing information always constitutes a prohibited sub-assignment.

2.6 Purpose and Considerations

2.6 Purpose:

• Clarify that even assignment holders may, for example, host a customer’s server or VM in their network, providing more than a single IPv6 address as common for IPv6 (at least /64).
• Explicitly also allows static prefixes for, e.g., servers.
• Codify that the customer's server or device must be at the assignment holder's End Site and part of their network.
• This removes 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) routed to the LL of the connected server's interface.
• This spells out the delegation of prefixes used in Internet infrastructure, i.e., routable prefixes, already implied in the previous version of the policy.
• Explicitly prohibits using PI to connect remote End Sites of customers to the Internet, except for p2p links to other ISPs.

2.6 Considerations:

• There may be a fear that this leads ISPs to leverage PI to connect residential customers, or to create a hosting business.
  However, this provision is already hard to control (and even harder to police), making it unlikely that this risk materialises beyond the scale it already has.
  Furthermore, assignment sizes remain limited by the provisions of "7. IPv6 Provider Independent (PI) Assignments", further reducing this risk.
• The use of PI for servers was explicitly listed as an intended use for the last revision of this policy, while the interpretation did not allow for this.
• Given best practices, /64 is often considered a reasonable prefix size used for end devices.
• Using PI for connecting access customers is now explicitly prohibited.

2.9 Current policy text

2.9 End Site

An End Site is defined as the location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

• that service provider assigning address space to the End User location.
• that service provider providing transit service for the End User location to other sites.
• that service provider carrying the End User's location traffic.
• that service provider advertising an aggregate prefix route that contains the End User's location assignment.

2.9 New policy text

2.9 End Site

2.9.1 End Site for Assignments Made from Allocation

An End Site for assignments made from an allocation is defined as the topological location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:

• that service provider assigning address space to the End User location.
• that service provider providing transit service for the End User location to other sites.
• that service provider carrying the End User's location traffic.
• that service provider advertising an aggregate prefix route that contains the End User's assignment.

2.9.2 End Site for PI Assignment

An End Site for provider independent assignments (PI) is defined as any topological location in the RIPE NCC Service Region where the End User deploys Internet-connected devices and that has a different routing policy than other End Sites of that End User.

Furthermore, the following considerations hold:

• different routing policies can be realised to ensure that traffic towards an End Site does not traverse other End Sites of the assignment holder, unless, for example, there is a loss of outbound connectivity at the End Site where a prefix from the assignment is used.
• a Layer 2 connection between two End Sites does not make them one End Site as long as both End Sites have different routing policies.
• a single device with the main purpose of providing Internet access to a single End User / Customer from a location does not constitute an End Site of an assignment holder.
• multiple sites with the primary purpose of announcing the same prefix from different locations that are not interconnected (i.e. Anycast setups) are counted as a single site.

2.9 Purpose and Considerations

2.9 Purpose:

• Differentiate between End Sites in the PI and IPv6 allocation cases.
• Define the meaning of End Site via specific routing policies expressed by how prefixes are propagated in the GRT.
• Clarify that an L2 connection between two sites does not make them one site as long as separate routing policies exist.
• Clarify that announcing aggregates or prepended prefixes from other End Sites does not merge routing policies.
• Prevent anycast setups from being sufficient justification for large prefixes.
• Make it explicit that placing a single device at another geographical location (CPE) with the main purpose of providing a single End User with Internet access does not make that location an End Site of an assignment holder.
• Clarify that PI End Sites must be topologically located in the RIPE NCC Service Region.

2.9 Considerations:

• Major issues encountered with PI stem from PI Assignments and assignments from allocations to End Users having been treated alike.
• There were some unclear formulations in the previous version of the text that now are more closely specified based on the intent of the policy.

5.4 Current policy text

5.4 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 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 total of a /48 made from IPv6 allocations must be based on address usage or routing requirements.

5.4 Purpose and Considerations

5.4 Purpose:

PI assignments and assignments from allocations differ in nature. The former is described in Section 7 of this document. However, the unclear wording of, especially, Section 5.4 cause ambiguity as to which policies apply to PI assignments. Explicating this now removes that ambiguity.

5.4 Considerations:

The concept of "address usage" / "addressing needs" has been inherited from earlier versions of the policy. It might be good to consider addressing this in the future, e.g., in the scope of a more general rewrite of IPv6 allocation policy/the planned nibble boundary change.

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.

More specific regulations for additional special purpose PI assignments may deviate from generic PI assignment criteria.

To avoid fragmentation, shorter assignments are possible based on addressing need analogous to Section 5.4.2 and for End Users with multiple End Sites according to Section 2.9.2 “End Site for PI Assignment,” e.g. when different routing requirements exist for these End Sites.

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 – justified, for example, by documenting each End Site’s the current and/or planned routing policies, or expected utilisation (see 2.7) policies in place for each End Site or the expected utilisation according to 2.7 within the next 24 12 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). bits), instead of assigning multiple shorter prefixes. 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 is left unused whenever a PI assignment is issued.

Registrations for PI assignments made after <DATE OF PROPOSAL IMPLEMENTATION> cannot be split up into smaller prefixes (for example, a /44 assigned PI cannot be broken into two or more independent assignments). 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 multiple PI assignments issued after <DATE OF PROPOSAL IMPLEMENTATION> needs more IPv6 PI address space, they must submit a request for an extension of their current assignment 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. assignment

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

7.1.3. Existing PI Assignments

An End User or LIR holding PI assignments issued before <DATE OF PROPOSAL IMPLEMENTATION> will have their addressing needs reevaluated as per 7.1.2 “Requesting a Larger Assignment" when they request an additional or larger assignment, or when they explicitly request a reevaluation of their addressing needs.

They will receive a single assignment corresponding to the result of that evaluation.

If the new assignment can be issued using or extending the prefix of an existing assignment including any or all of the following:

• Existing PI assignments to the same holder.
• Contiguous available address space.

Then that prefix should be used to make the new assignment.

If multiple existing assignments satisfy this requirement, the End User's preference for which assignment to expand should be considered.

All previously issued PI assignments must be returned to the RIPE NCC after renumbering once the new PI assignment has been issued or an existing one was extended.

The renumbering period for PI assignments issued after <DATE OF PROPOSAL IMPLEMENTATION> is six months.

For PI assignment requests evaluated before <DATE OF PROPOSAL IMPLEMENTATION> the initial renumbering period is twelve months, which can be extended by twelve months every twelve months, if the End User provides the RIPE NCC with documentation demonstrating that:

• A renumbering is currently not feasible, and
• The prefixes are currently in use.

Even though, technically, the renumbering period can thereby be extended indefinitely, return of these PI assignments remains mandated.

7.1 Purpose and Considerations

7.1 Purpose:

• Ensure that the current discussion around what constitutes an End Site is resolved, especially when L2 interconnectivity exists.
• Specifying how need can be documented leaves less room for discussions around this point when applying for resources.
• Clarify terminology around the 'minimum size' of PI, i.e., that it is /48 or-longer.
• Clarify that either addressing needs or the presence of multiple End Sites per 2.9 qualify for shorter prefixes.
• Limit the maximum size of PI assignments to be smaller than the smallest possible allocation, which is at the moment a /36, the largest nibble boundary below the minimum allocation size of /32.
• The current policy disagrees with the policy for IXP PI assignments (RIPE-451), which allows /64s to be assigned. Hence, this clarifies that other policies for specific types of PI may deviate from size requirements.

7.1 Considerations:

The concept of “address usage” / “addressing needs" has been inherited from earlier versions of the policy. It might be good to consider addressing this in the future, e.g., in the scope of a more general rewrite of IPv6 allocation policy/the planned nibble boundary change.

Limiting the size of PI based on the minimum allocation size should be a reasonable step, considering that—if networks of that size are needed—the operational overhead of obtaining an allocation instead should be negligible.

7.1.1 Purpose:

This change adds a specific reference to the End Site notion from 2.9. Furthermore, it clarifies how an End User can justify a specific need.

• Ensure that the current discussion around what constitutes an End Site, especially when L2 interconnectivity exists, is resolved.
• Specifying how need can be documented leaves less room for discussions around this point when applying for resources.
• Clarify terminology around the ‘minimum size’ of PI, i.e., that it is /48 or-longer.
• Clarify that either addressing needs or the presence of multiple End Sites per 2.9 qualify for shorter prefixes.

7.1.2 Purpose:

• Make the process for receiving larger assignments clear; detail how cases where no fitting reservation is in place are to be handled.
• Clarify what happens if no sufficiently sized reservation is available.
• Discourage deaggregation by not allowing the receipt of multiple smaller assignments to satisfy a request for additional assignment size if the requirements are met.

7.1.2 Considerations:

The requirement to renumber, i.e., not permitting receipt of multiple, e.g., /48s if a justified /44 request cannot be implemented from a reservation for an existing /48, should discourage deaggregation. Given that PI networks are--comparatively--small, this should be a viable trade-off to prevent further deaggregation.

7.1.3 Purpose:

• Make the process for receiving larger assignments clear; detail how cases where no fitting reservation is in place are to be handled.
• Clarify what happens if no sufficiently sized reservation is available; ensure that new assignments cover as much of prior assignments as possible.
• Discourage deaggregation by not allowing the receipt of multiple smaller assignments to satisfy a request for additional assignment size if the requirements are met.

7.1.3 Considerations:

The requirement to renumber, i.e., not permitting receipt of multiple, e.g., /48s if a justified /44 request cannot be implemented from a reservation for an existing /48, should discourage deaggregation. Given that PI networks are--comparatively--small, this should be a viable trade-off to prevent further deaggregation.

Rationale

a. Motivation for the Proposal

The purpose of this proposal is to reduce reducing the operational overhead of PI assignment requests for End Users, LIRs, and RIPE NCC Registration Services. This overhead is mostly due to the ambiguity in the current policy proposal text, leading to a PI assignment maximum size of /48 per End Site. /48. 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 prefixes, as well as an increased load on the RIPE NCC, as these are currently handled via multiple independent 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: proposal being formulated in its current version, the following arguments were made in favor of the document:

• 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 they are mandated to 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 The proposal eases request evaluation by the RIPE NCC by focusing on End Sites while providing a clear documentation of what does and does not constitute an End Site. Furthermore, fewer requests will be necessary if an End User has already received an assignment longer than a /48 and only needs one additional prefix.
• The updated policy clarifies a disagreement with the IPv6 IXP PI policy, which allows /64s to be assigned to IXPs by allowing more specific policies to deviate from the minimum assignment size defined in this policy.

c. Arguments Against the Proposal

In the discussions prior to this version of the proposal, the following counterarguments were made: proposal being formulated in its current version, the following arguments were made against the proposed changes in the document:

• Allowing for larger PI assignments might lead to ISPs being inclined to utilise PI for, e.g., Broadband services.
  • Counterargument: the proposal Counter-Argument: This document introduces several points where these uses of concern are explicitly prohibited.
• Reserving up to the next nibble boundary is wasting address space.
  • Counterargument: at Counter-Argument: At the moment, a /46 is usually reserved for a /48 PI assignment, already leading to comparable address space utilisation (1/4 (1/4th 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.
space, and—more importantly—reduces deaggregation.

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 Link: https://www.ripe.net/publications/docs/ripe-738/#26-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 Link: https://www.ripe.net/publications/docs/ripe-738/#7-ipv6-provider-independent-pi-assignments , 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 Link: https://www.ripe.net/publications/docs/ripe-738/#72-ipv6-provider-independent-pi-assignments-for-lirs , 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 Link: /publications/docs/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 Link: https://www.ripe.net/publications/docs/closure , 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 Link: https://www.ripe.net/publications/docs/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.