Revised IPv6 PI Assignment Policy

Summary of the Proposal

This proposal aims to reduce operational burden operators working with PI experience, while clarifying long-standing issues in the IPv6 addressing policy. Specifically, it makes the following changes:

• Separate notions of assignment requirements and End Sites for ‘PI Assignments’ and ‘Assignments from IPv6 Allocations to End Users’.
• Clarify permitted and non-permitted use cases of PI Assignments.
• Clarify wording, definitions, and requirements in the text.
• 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, and it is not allowed to 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 located at the same geographical End Site as the holder’s network 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 static addresses when connecting a server or appliance to 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, if 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 bit to connect a separate End Site of another entity to the Internet 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. 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 from IPv6 allocations

Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 made from IPv6 allocations must be based on address usage or because of 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, for example, by documenting the current and/or planned routing policies in place for each End Site or the expected utilisation according to 2.7 within the next 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), 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 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 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

If the requested extension to the next nibble boundary cannot be 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 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 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 proposal text, leading to a PI assignment maximum size of /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, 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.

b. Arguments Supporting the Proposal

In the discussions prior to this 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 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).
• 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 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.
  • 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.
  • Counter-Argument: At the moment, a /46 is usually reserved for a /48 PI assignment, already leading to comparable address space utilisation (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.
• The unlimited renumbering period may be abused for IPv6 PI hoarding.
  • Counter-Argument: While, in general, this might be true, use of held PI for, e.g., transfers is limited by the mandated return introduced in this document. Furthermore, End Users need to regularly demonstrate their continuous inability to renumber, as well as that the addresses are still in active use, to receive an extension.
• The load on the RIPE NCC might increase due to an influx of requests by End Users wanting to aggregate their existing prefixes.
  • Counter-Argument: The author acknowledges that, especially initially, the proposal may temporarily increase load, while also necessitating changes to existing management systems. However, in the long run, the load should be significantly reduced 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 not necessarily truthful information about End Sites.
  • Counter-Argument: Given the challenges of the current PI policy encountered 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 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.
  • Counter-Argument: 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.
  • Counter-Argument: 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.