Hi all, First, I'd like to make a correction from my first email. The correct policy proposal number should be 2024-01 and not 2024-02. Moving on... Radu, thank you for your feedback. I can't speak to the specific cases you mentioned, but I believe the NCC is completing KYC at the organization level for compliance purposes with the legal entity they are entering a contractual relationship with and receiving payment from. The location of the network/resources won't necessarily be the same as the org's. I'd open this implementation question up to the community and the policy officers for the most practical approach, but the existing 'geoloc' attribute can already be used within inet6num objects in the RIPE database to specify geographic coordinates for a PI assignment so I don't think we'd need a new attribute. Thank you, Clara On 10/16/25, 11:07 PM, "Radu Anghel" <radu.anghel@xindi.ro <mailto:radu.anghel@xindi.ro>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi, Could you please help me understand how the proposed 2.6 "same geographical End Site" would be interpreted in practice? I’m thinking about situations where the End-User address is an anonymous PO Box that's already been verified and accepted through RIPE NCC's KYC process (such as ORG-AZ74-RIPE only 6 days ago). Another example could be a situation where the country: is listed as DE, but the address: corresponds to the HQ of Google Switzerland (also recently validated and accepted by RIPE NCC). In cases like these, would someone actually expect to find WiFi, servers, appliances, or ISPs using the assigned PI addresses at those geographical locations? Or would this mean we'd need a new DB object to better represent the actual geographical End Sites? (db-wg?) Thanks! Radu On 10/16/2025 10:16 PM, Wade, Clara via address-policy-wg wrote:
Dear APWG,
We would appreciate your feedback on the proposed new version of RIPE policy proposal 2024-01, “Revised IPv6 PI Assignment Policy”.
Following the latest round of discussion, we implemented changes we hope will address the concerns expressed by the community. To summarize, the main changes were the following:
* 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. * Section 7.1 has been simplified, including removing 7.1.3 from the proposal. * Overall, we strived to remove redundant statements and make this document more concise and readable. In line with this, we combined the Purposes and Considerations under the Motivation section, instead of pointing these out section by section.
While this will be posted by the RIPE NCC after RIPE 91, we are sharing the text here hoping we can hear your thoughts at the meeting next week when we present.
Thank you,
Clara Wade
-------------
*Number: 2024-01*
*Policy Proposal Name:* Revised IPv6 PI Assignment Policy
*Authors:* Tobias Fiebig
tobias@fiebig.nl <mailto:tobias@fiebig.nl> <mailto:tobias@fiebig.nl <mailto:tobias@fiebig.nl>>
Max-Planck Institut für Informatik
Clara Wade
clarawad@amazon.com <mailto:clarawad@amazon.com> <mailto:clarawad@amazon.com <mailto:clarawad@amazon.com>>
Amazon
*Proposal Version:* 2.0
*Submission Date:* 7/10/2025
*Suggested WG for Discussion and Publication:*Address Policy
*Proposal Type:* Modify
*Policy Term:* Indefinite
*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 static 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 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* o Assignment holders may assign more than a single IPv6 address (/64) for custom servers/VMs within their End Site, static prefixes and routable prefixes. o Explicitly prohibit PI assignments from being used to connect remote customer End Sites (except for p2p links to other ISPs). o 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* o Make a clear distinction between PI assignments and allocation- based assignments. o Set a standard minimum size (/48 or longer) and a maximum size limit (/36) for PI assignments. o 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* o 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. o Specify documentation requirements for End User justification, including technical need and infrastructure requirements. * *Streamline PI assignment request process* o 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* o 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* o Aligning on /64 as the standard prefix size for end devices. o Explicitly permitting server usage to clarify previous policy ambiguity. o Allow addressing scheme flexibility while maintaining routing efficiency. * *Policy evolution* o Retained legacy concepts such as “address usage” and ”addressing needs” for continuity. o Future policy updates may address modernised addressing metrics, nibble boundary adjustments and general IPv6 allocation policy revisions. * *Routing efficiency* o Balance operational flexibility and routing table management to prevent deaggregation. o 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. o Counterargument: the proposal introduces several points where these uses are explicitly prohibited. * Reserving up to the next nibble boundary is wasting address space. o 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. o 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. o 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. o 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. o 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.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>