Dear APWG,
We would appreciate your feedback on the proposed new version of RIPE
policy proposal 2024-02, “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-02*
*Policy Proposal Name:* Revised IPv6 PI Assignment Policy
*Authors:* Tobias Fiebig
[email protected] <mailto:[email protected]>
Max-Planck Institut für Informatik
Clara Wade
[email protected] <mailto:[email protected]>
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/
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/
