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
* Assignment holders may assign more than a single IPv6 address (/64)
for custom servers/VMs within their End Site, static prefixes and routable
prefixes.
* Explicitly prohibit PI assignments from being used to connect remote
customer End Sites (except for p2p links to other ISPs).
* Remove the implicit need for addresses used for interconnectivity to
be on a shared prefix, i.e., the shared link can be numbered with LL addresses
and a /128 (or /64).
* Distinguishing assignment types and sizes
* Make a clear distinction between PI assignments and allocation-based
assignments.
* Set a standard minimum size (/48 or longer) and a maximum size limit
(/36) for PI assignments.
* Define a path to qualify for shorter prefixes based on documented
addressing needs or requirements due to the presence of multiple End Sites.
* Clarifying End Site use-cases and documentation requirements
* Address the current discussion around what constitutes an End Site in
L2 interconnectivity scenarios. The definition of End Site initially proposed
under 2.9 will be spun off into a separate policy proposal to avoid confusing
discussion of this proposal.
* Specify documentation requirements for End User justification,
including technical need and infrastructure requirements.
* Streamline PI assignment request process
* Provide a structured process for large assignment requests to avoid
de-aggregation and reduce the need for renumbering in case of growth by
following nibble boundaries.
Considerations
* Operational risk management
* Controlled risk of PI misuse for residential customers or hosting
businesses through size limitations, End Site requirements and explicit
prohibition of customer connection.
* Following technical best practices
* Aligning on /64 as the standard prefix size for end devices.
* Explicitly permitting server usage to clarify previous policy
ambiguity.
* Allow addressing scheme flexibility while maintaining routing
efficiency.
* Policy evolution
* Retained legacy concepts such as “address usage” and ”addressing
needs” for continuity.
* Future policy updates may address modernised addressing metrics,
nibble boundary adjustments and general IPv6 allocation policy revisions.
* Routing efficiency
* Balance operational flexibility and routing table management to
prevent deaggregation.
* Introducing an aggregation principle, suggesting renumbering
requirements and size limitations relative to allocation sizes.
b. Arguments Supporting the Proposal
In the discussions prior to this version of the proposal, the following
supporting arguments were made:
* There are use cases that benefit from more than one routable prefix. At
the moment, these are serviced with multiple, often subsequent, assignments,
leading to increased deaggregation and fragmentation of the address pool, as
well as cluttering the database. This proposal mitigates that.
* The proposal strives to prevent renumbering in case of growth, even if
requirements change.
* The proposal ensures that PI cannot be easily hoarded, as unused
assignments must be returned to the RIPE NCC, preventing transfers.
* The proposal more explicitly addresses the issue of PI being abused for
providing ISP services, while not limiting reasonable use cases previously
included in the intent of the policy but prevented by the wording (e.g., public
Wi-Fis and assigning prefixes shorter than /128).
* Fewer requests will be necessary if an End User has already received an
assignment longer than a /48 and only needs one additional prefix.
c. Arguments Against the Proposal
In the discussions prior to this version of the proposal, the following
counterarguments were made:
* Allowing for larger PI assignments might lead to ISPs being inclined to
utilise PI for, e.g., Broadband services.
* Counterargument: the proposal introduces several points where these
uses are explicitly prohibited.
* Reserving up to the next nibble boundary is wasting address space.
* Counterargument: at the moment, a /46 is usually reserved for a /48 PI
assignment, already leading to comparable address space utilisation (1/4 of,
but with the same level of deaggregation). Furthermore, each subsequent request
that can be satisfied by the reservation, or that is not necessarily due to the
initial assignment’s size, preserves address space and, more importantly,
reduces deaggregation.
* The load on the RIPE NCC might increase due to an influx of requests by
End Users wanting to aggregate their existing prefixes.
* Counterargument: the authors acknowledge that, especially initially,
the proposal may temporarily increase load while also necessitating changes to
existing management systems. However, the load should be significantly reduced
over the long term by streamlining evaluations. Furthermore, the included
growth potential of assignments reduces overhead in case End Users’
requirements increase only slightly, up to a point where several individual
requests for additional assignments are no longer necessary.
* End Users might request unreasonably large assignments by presenting
untruthful information about End Sites.
* Counterargument: given the challenges of the current PI policy in
operational practice, the truthfulness of requests already can be improved. The
purpose of this proposal is ensuring that lying is no longer necessary to
receive required resources, while making it more difficult to lie in order to
receive more resources than necessary. This includes scoping the extent of
impact, as well as database clutter, when non-truthful assignment requests are
actually successful despite best efforts.
* It is no longer possible to hold PI in multiple prefixes for, e.g.,
multiple different purposes.
* Counterargument: while this argument is correct, the reason for not
permitting this is the trade-off between encouraging (re-)aggregation and the
added freedom of these use cases. Given the limited number of End Users holding
multiple PI assignments with specific purposes, this is considered an
acceptable trade-off by the proposer.
* Allowing larger PI assignments might lead to PI assignments of arbitrary
size being possible.
* Counterargument: in the newest version of the proposal, the size of PI
assignments is limited to always be more specific than the most specific
allocation. At the time of writing, this would be a maximum PI size of a /36.
-----
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/
