I also support the proposal. Definitely better than the current policy. best regards Wolfgang

On 3. Apr 2026, at 13:48, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> wrote:

Dear Colleagues,

...

Version 2 of RIPE policy proposal 2024-01 "Revised IPv6 PI Assignment Policy" is now available for discussion again.

The proposers and the APWG Chairs decided to open a new Discussion Phase because of the limited feedback received in the previous one.

Thank you again for re-opening the discussion phase.

I would like to use this opportunity to encourage those who already voiced their support before the discussion phase to do so again, so it is formally voiced during the discussion phase and in compliance with the PDP.

-- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov, Alexander Hüsch Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne

Hi all, While I support the intent of the proposal, I can’t support it in the current stage. Let me explain all the points: 1) Length of the assignment. Why, again we want to restrict it? If I get a PI, it may be perfectly valid that I sub-assign /52 instead of /56. It is an operational decision/need what is the size of the prefix sub-assigned. So my proposal is: Actual: 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. Proposal: Providing connectivity to another entity inside the assignment holder’s network, at the same geographical End Site, *regardless of the prefix length*, is not considered a sub-assignment. 2) Reasons for the assignment. Why we want to make it, again, restrictive? Any operational need must be valid. Removing the wording “for example” limits whatever is not specifically worded out. Also we are making, in my opinion, the text longer, without adding extra value. Also instead of static (to avoid confusion with dynamic - DHCP), I will suggest to use persistent, as described in BCOP690. Actual: 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 Proposal: This includes *for example* letting visitors connect to the assignment holder's network, providing *persistent* addresses *or prefixes* for *devices, applications, services or point-to-point links* or other operational needs. 3) Why we want to limit the planning of an organization to 24 months? Several years ago already decided that the address planning depends on each organization, each business plan. Some organizations may plan for just 1 year, others for 5 years. We have this very clear text in 5.1.2 “… the segmentation of infrastructure for security and the planned longevity of the allocation.” PI must allow the same, no difference. By the way, I’m not sure about the “–“ must be finished with another “–“ at some point in the sentence (I think so), as it is not clear to me if the sentence should be read as “everything is part of the example” or the "within the next 24 months" is not part of the example. Actual: … – 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 Proposal: … – for example, by documenting each End Site’s current and/or planned routing policies, or expected utilisation (see 2.7) *– for the planned longevity of the allocation*. 4) Again, not sure if this is restrictive. If we allow an assignment /32, why not?, we may have an organization that prefers a PI instead of PA and is perfectly valid. Actual: 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). Proposal: 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, /36 *and so on*, in steps of 4 bits). 5) Last, but not least, I think that if renumbering is needed as per 7.1.2,, 6 months may be too short, according to many previous discussions about that. I will suggest 12 or 24 months, or a text that allows an extension of the 6-months if justified. Actual: 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. Proposal: 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 *twelve-month* renumbering period. *If justified to the RIPE NCC, this period could be extended.* All those changes, will allow the IPv6 policy to be consistent *without artificial restrictions* with RFC9762. Someone could say “let’s move on and later on we submit another proposal”, but this doesn’t work, specially if we can agree in small modifications now. I’ve been there. Some years ago, when we had a policy proposal for “assign” and I said it was restrictive and no sense to allow only addresses, not prefixes, and look now is clear I was right. Also I was told “you send too many proposals, we already discussed this a few months ago with a previous proposal”, etc., etc. Let’s do the things as perfect as we can once! Regards, Jordi @jordipalet

El 3 abr 2026, a las 13:48, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> escribió:

Dear Colleagues,

...

Version 2 of RIPE policy proposal 2024-01 "Revised IPv6 PI Assignment Policy" is now available for discussion again.

The proposers and the APWG Chairs decided to open a new Discussion Phase because of the limited feedback received in the previous one.

Thank you again for re-opening the discussion phase.

I would like to use this opportunity to encourage those who already voiced their support before the discussion phase to do so again, so it is formally voiced during the discussion phase and in compliance with the PDP.

I am also reaching out to several people who already voiced their support for an earlier revision, or who had strong opinions otherwise, to do the same, i.e., read the new version of the document and share their thoughts.

(I am adding those colleagues into Bcc: to not clutter the headers.)

With best regards, Tobias

-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl Pronouns: he/him/his ----- 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/

********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Tobias, Some responses below, in-line. Saludos, Jordi @jordipalet

El 7 abr 2026, a las 14:05, Tobias Fiebig <tobias@fiebig.nl> escribió:

Hello Jordi,

Thank you for reaching out. Please let me respond to individual points below.

...

1) Length of the assignment. Why, again we want to restrict it? If I get a PI, it may be perfectly valid that I sub-assign /52 instead of /56. It is an operational decision/need what is the size of the prefix sub-assigned.

As you may have noticed, 2024-01 has been going on for a bit, and there were a lot of discussions on the text. An earlier revision of the proposal actually limited this to /49 and more specific, i.e., anything that is not announcable. The current state is a /64. However, this drags the tail of the end-site definition with it, which was removed from 2024-01 to make the proposal more digestible.

Hence, to make the actual change in this revision smaller, the idea was to only expand to a /56, as this is another common size in PD.

The point to understand is that this community is not making standards at IETF, which is the right place. The IETF did a standard that doesn’t put a limit like /56. Consequently if anyone in this community wants to change that, must address it at the right venue: the IETF. Note also that this limitation places RIPE “below" what other RIRs already had (allowing prefixes without any limit of size, not just addresses). In other words, our work here must be coherent and fully respecting the IETF standards. In the end, we are several organizations working together: RIRs, IETF, other standard bodies, ICANN, etc. and each one has its own limits and must not step in the job of others or alter or limit that. Otherwise, we can have weird several situations: 1) Tomorrow, at Routing WG or DNS WG, or others, we can alter the IETF standards by limiting them artificially. Clearly, not right. 2) IETF could approve an RFC that step in the work that we do by means of policies.

...

So my proposal is:

Actual:

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.

Proposal: Providing connectivity to another entity inside the assignment holder’s network, at the same geographical End Site, *regardless of the prefix length*, is not considered a sub-assignment.

With the proposal passing, though, it would be up to the community, to propose further relaxing this requirement, e.g., as you proposed. I would suggest submitting the change you are suggesting there as a dedicated proposal after 2024-01 has been implemented.

We have been there already. One proposal after other after other, changing the same, doesn’t work, and even chairs reject them (which I think is beyond their authority/PDP, but that’s a different discussion). As said, this community can’t limit what standards don’t limit.

...

2) Reasons for the assignment. Why we want to make it, again, restrictive? Any operational need must be valid. Removing the wording “for example” limits whatever is not specifically worded out. Also we are making, in my opinion, the text longer, without adding extra value. Also instead of static (to avoid confusion with dynamic - DHCP), I will suggest to use persistent, as described in BCOP690.

Actual:

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

Proposal:

This includes *for example* letting visitors connect to the assignment holder's network, providing *persistent* addresses *or prefixes* for *devices, applications, services or point-to-point links* or other operational needs.

First of all, I believe that the use of persistent vs. static is an editorial issue, and I am very much open to align with BCOP690 there.

Yes, this is editorial, we can change it without a big discussion, hopefully.

Beyond that, the section carries the implications of using PI for PA reserved purposes, which is a major concern from the NCC side, as well as several members of the community. Again, as the end-site revisions were removed from the text, this part is also kept more slim. As before, I would suggest implementing the proposed change in a dedicated policy proposal.

As said before, a proposal after another after another, doesn’t work. We must fix it in a single step. Not wait years for it.

...

3) Why we want to limit the planning of an organization to 24 months? Several years ago already decided that the address planning depends on each organization, each business plan. Some organizations may plan for just 1 year, others for 5 years. We have this very clear text in 5.1.2 “… the segmentation of infrastructure for security and the planned longevity of the allocation.” PI must allow the same, no difference. By the way, I’m not sure about the “–“ must be finished with another “–“ at some point in the sentence (I think so), as it is not clear to me if the sentence should be read as “everything is part of the example” or the "within the next 24 months" is not part of the example.

Actual: … – 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

Proposal: … – for example, by documenting each End Site’s current and/or planned routing policies, or expected utilisation (see 2.7) *– for the planned longevity of the allocation*.

The 24 months are, to the best of my knowledge, aligned with current procedures. Again, as before, a larger change should be implemented in a follow-up proposal, instead of expanding the scope of this document.

I’m not proposing to change the current practice, but to stick to the actual *existing* text.

...

4) Again, not sure if this is restrictive. If we allow an assignment /32, why not?, we may have an organization that prefers a PI instead of PA and is perfectly valid.

Actual:

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).

Proposal:

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, /36 *and so on*, in steps of 4 bits).

Again, this is the larger discussion about the purpose of PI/PA, and some members feeling that there should be a qualitative difference between PI and PA.

Unless I’m wrong, there is no text in the actual policy that limits a PI size. So why we want to limit it now?

Again, in the spirit of more restrictive changes in a single intervention, this point is being kept consciously restrained.

Also, again, as before, I would suggest bringing in this further change in a follow-up proposal, ensuring that the specific intent voiced can receive the necessary focus and attention from the community.

Repeating myself … proposal after a proposal …. doesn’t work.

...

5) Last, but not least, I think that if renumbering is needed as per 7.1.2,, 6 months may be too short, according to many previous discussions about that. I will suggest 12 or 24 months, or a text that allows an extension of the 6-months if justified.

Actual:

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.

Proposal:

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 *twelve-month* renumbering period. *If justified to the RIPE NCC, this period could be extended.*

The six month renumbering period is a commonly used time-frame for renumbering within NCC policy documents. Again, as before, opening that box was considered outside the scope of the document. If there is a strong push to deviate from these numbers in either direction as highlighted by several members voicing it, that change could be easily considered, I believe.

Will not repeat myself, why we want to leave it for the future … doesn’t work.

...

Someone could say “let’s move on and later on we submit another proposal”, but this doesn’t work, specially if we can agree in small modifications now.

Your argument is circular. Either the modifications are small now, so it should not be an issue to have the, hence small, follow up proposal pass. Or the follow-up proposal would not work, because the changes are not that small. However, then it also would not make sense to now quickly slip them through here.

...

I’ve been there. Some years ago, when we had a policy proposal for “assign” and I said it was restrictive and no sense to allow only addresses, not prefixes, and look now is clear I was right. Also I was told “you send too many proposals, we already discussed this a few months ago with a previous proposal”, etc., etc. Let’s do the things as perfect as we can once!

I hear your concerns and appreciate you sharing your personal experiences with other policy proposals. I would, however, prefer to keep this discussion focused on 2024-01; And, in best engineering practice, I would deeply prefer following the small-badge-principle instead of trying to submit something--eventually, but likely never reaching the state--perfect once.

...

With best regards, Tobias

-- Univ.Prof. Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.at

********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi all, I still 100% support this policy as it is clearly superior to the old one. Even if I wanted to see changes, I would rather use this as the common ground rather than the old one. Do you really prefer people obtaining multiple /48 instead of one /44? If not, please add your support to this policy. Cheers Max On 03 April, 2026 15:03 CEST, Jori Vanneste via address-policy-wg <address-policy-wg@ripe.net> wrote:  Dear all, (Re-sending this under the proper thread as per compliance with the PDP. :) ) As I have personally stated since the first time this policy proposal was put forth, I believe this revision is a step towards the right direction. Having sponsored/requested around 2 gross worth of resources, the policy regarding IPv6 PI was quite vague and often difficult for both: - Us trying to enforce it properly without passing unqualified requests onward to the Resource Analysts - End Users trying to see if it would fit their use-case. Thus adding a lot of back and forth, and ultimately, a lot of operational overhead. Both for the RIPE NCC and LIRs / End Users. I am curious to see how this pans out, and would like to put my +1 in the hat for the go-ahead. :) Kind regards, and wishing everyone a nice rest of the week, Jori Vanneste AS41051 (9-5) / AS212123 (24/7)  On 26 March 2026 14:41:31 CET, Angela Dall'Ara <adallara@ripe.net> wrote:Dear colleagues, 
 Version 2 of RIPE policy proposal 2024-01 "Revised IPv6 PI Assignment Policy" is now available for discussion again. The proposers and the APWG Chairs decided to open a new Discussion Phase because of the limited feedback received in the previous one. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-01 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. 
 The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 
We encourage you to review this proposal and send your comments to 
address-policy-wg@ripe.net before 24 April 2026. 
 Kind regards, 
 Angela Dall'Ara Policy Officer RIPE NCC______________________________________________________________________________ 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/