- address-policy-wg - mailman.ripe.net

2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28)
by Angela Dall'Ara 07 Nov '25

07 Nov '25

Dear colleagues,   A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.  Following the last round of discussion, this proposal has been updated and it is now at version 4.0.  The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/ As per the RIPE Policy Development Process (PDP), the purpose of this six-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(a)ripe.net before 7 November 2025.   Kind regards,   Angela Dall'Ara Policy Officer RIPE NCC

16 20

New Self-Service Form for Ending Sponsorships Now Live
by Marco Schmidt 04 Nov '25

04 Nov '25

Dear colleagues, As announced during the Address Policy session at RIPE 91, we have now deployed a new request form that allows RIPE NCC members to easily stop the sponsorship of Provider Independent (PI) resources (IPv4 PI, IPv6 PI, and AS Numbers). This new form introduces our first true self-service workflow in Registry Services. It enables immediate execution of the request, offers a clearer process, and significantly reduces manual handling. You will find the form in the LIR Portal under the same section previously used to notify the RIPE NCC about changes. Full details are available in this RIPE Labs article: https://labs.ripe.net/author/marco_schmidt/automated-self-service-to-end-sp… If your organisation sponsors independent resources, please take a moment to review your current customer agreements and use the new form to notify us of any sponsorships that have ended. Thank you for helping us maintain accurate registry data. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
by Wade, Clara 01 Nov '25

01 Nov '25

Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade

16 25

Re: 2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28)
by ember 30 Oct '25

30 Oct '25

> If you support this draft of the proposal, please indicate that with a > simple message. It can be a +1 or a 👍. Absolutely in favor of this! +1 from me ~ ember

1 0

Re: address-policy-wg Digest, Vol 161, Issue 9
by Hien Nguyen 30 Oct '25

30 Oct '25

Ekkomagicboy.senju ---------- Forwarded message --------- Từ: <address-policy-wg-request(a)ripe.net> Date: 4:53 Th 5, 30 thg 10, 2025 Subject: address-policy-wg Digest, Vol 161, Issue 9 To: <address-policy-wg(a)ripe.net> Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Randy Bush) 2. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Marco Schmidt) 3. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Max Emig) ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Oct 2025 18:05:53 -0700 From: Randy Bush <randy(a)psg.com> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: "Wade, Clara" <clarawad(a)amazon.com> Cc: RIPE address policy WG <address-policy-wg(a)ripe.net> Message-ID: <m2frb234b2.wl-randy(a)psg.com> Content-Type: text/plain; charset=ISO-8859-1 hi clara as usual, i am a bit confused; yes, a low bar. have sympathy; you have been doing this *far* longer than i. CSTFR sez: > it takes staff an average of 75 minutes to process each intra-RIR > transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six > hours for a legacy transfer between parties with contractual > relationships with the RIPE NCC looking at table 7, i think we're comparing "RIPE NCC Region Transfers" with "Legacy Updates," whatever the heck they are. i suspect that they are not inter-member transfers of legacy space. as you were on the CSTF, so i hope you remember what these numbers actually measure and could please whack me with a clue bat. Clara: > legacy status, regardless of whether there is a contractual > relationship or not, need to undergo a more stringent diligence > process for transfers that puts additional burden on the NCC i naïvely assume that the extra diligence of provenance is incurred once when the space is first registered, e.g. when the holder becomes a member or it is acquired by a member. and that cost would be a one time cost. from then on, why is it not just space with a different paint job? if member A transfers legacy space to member B why the heck would it take significantly more effort than if A transfers non-legacy space to B? can someone from the registry comment? similarly if A transfers legacy space to B as non-legacy, does it really require less effort than if B receives it as legacy space? randy, trying to understand what problems we really need to solve ------------------------------ Message: 2 Date: Wed, 29 Oct 2025 14:16:34 +0100 From: Marco Schmidt <mschmidt(a)ripe.net> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: Randy Bush <randy(a)psg.com>, "Wade, Clara" <clarawad(a)amazon.com> Cc: RIPE address policy WG <address-policy-wg(a)ripe.net> Message-ID: <f075336f-b51d-46d9-b1c2-da01d4df9341(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Hello Martin, Randy, all Please allow me to provide a bit more context regarding the processing times shown in the report of the Charging Scheme Task Force. First, these figures are averages based on samples and experience in Registration Services. Actual cases may be completed faster, or sometimes significantly slower. Second, the four categories mentioned in the Charging Scheme Task Force report cover a range of scenarios, and this grouping creates some cluster effects that can be confusing. For example, policy transfers of PI resources within the RIPE NCC region can involve: - two members, - a member and a non-member - two non-members. Transfers between two members are usually below the average of 75 minutes, while those involving non-members usually take a bit longer, especially when the receiving party is new to the RIPE NCC and additional checks are required. The Legacy Updates group is similar. Randy is correct, updates of legacy resources under contract between two existing members are typically far below the 360-minute average, but they represent only a small portion of this group. The longer processing times mainly occur when a new contract must be signed with the RIPE NCC or a sponsoring member, or when only one party has a contractual relationship. In particular, cases where the offering party has no contract (while the receiving party has or will have one) can take significantly longer, as the RIPE NCC must perform extensive due-diligence checks before the Legacy update can be completed. I hope this clarifies. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 29/10/2025 02:05, Randy Bush wrote: > hi clara > > as usual, i am a bit confused; yes, a low bar. have sympathy; you have > been doing this *far* longer than i. > > CSTFR sez: >> it takes staff an average of 75 minutes to process each intra-RIR >> transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six >> hours for a legacy transfer between parties with contractual >> relationships with the RIPE NCC > looking at table 7, i think we're comparing "RIPE NCC Region Transfers" > with "Legacy Updates," whatever the heck they are. i suspect that they > are not inter-member transfers of legacy space. as you were on the > CSTF, so i hope you remember what these numbers actually measure and > could please whack me with a clue bat. > > Clara: >> legacy status, regardless of whether there is a contractual >> relationship or not, need to undergo a more stringent diligence >> process for transfers that puts additional burden on the NCC > i naïvely assume that the extra diligence of provenance is incurred once > when the space is first registered, e.g. when the holder becomes a > member or it is acquired by a member. and that cost would be a one time > cost. from then on, why is it not just space with a different paint > job? > > if member A transfers legacy space to member B why the heck would it > take significantly more effort than if A transfers non-legacy space to > B? can someone from the registry comment? > > similarly if A transfers legacy space to B as non-legacy, does it > really require less effort than if B receives it as legacy space? > > randy, trying to understand what problems we really need to solve > ----- > 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/ ------------------------------ Message: 3 Date: Wed, 29 Oct 2025 22:53:21 +0100 From: "Max Emig" <ripe(a)emigm.ax> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: Wade, Clara <clarawad(a)amazon.com> Cc: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net>, peter.hessler(a)zayo.com <peter.hessler(a)zayo.com> Message-ID: <1ad4e135-4e93-0f0f-5b84-a957a86056f0(a)emigm.ax> Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_ org_NGMime-66-1761774801.073449-1------" Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" < address-policy-wg(a)ripe.net> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: * “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. * “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: * RIPE registration services fees. * The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. * Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade

1 0

Re: address-policy-wg Digest, Vol 161, Issue 11
by Wade, Clara 30 Oct '25

30 Oct '25

Hi Dominik, > I believe changing the policy will lead to exactly more of 1 - change won't be registered with the NCC in order for the resource not to lose its legacy status. This behavior is an anti-pattern and it also goes explicitly against the RIPE NCC process for legacy resource transfers. Hopefully, anyone engaging in these practices understands the risks they are assuming (for them and their customers if they are a service provider) by doing so. For clarity, this policy does not aim to affect transfers among LIRs within the same member account - understanding this would be effectively like M&A/organization restructure cases, which we understand can happen among higher ed and research entities that tend to be legacy resource holders too. The NCC would clarify this in the impact analysis report. > This is significant especially that these changes don't have to be registered in order to be able to use the space - i.e. be creating route objects in alternate DBs. This too is an anti-pattern we aim to prevent and it hinders RPKI adoption. > For that reason I oppose the proposal. If this is more of "extra work required" type of issue - then let's solve it by putting the correct price tag on it. This portion will be addressed by the proposed charging scheme models that the NCC is working on presenting soon, following the Charging Scheme Task Force report. However, incentives will not be enough to stop certain actors from exploiting this loophole in RIPE policy. Thank you, Clara On 10/30/25, 9:43 AM, "address-policy-wg-request(a)ripe.net <mailto:address-policy-wg-request@ripe.net>" <address-policy-wg-request(a)ripe.net <mailto:address-policy-wg-request@ripe.net>> 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. Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net> To subscribe or unsubscribe via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net <mailto:address-policy-wg-request@ripe.net> You can reach the person managing the list at address-policy-wg-owner(a)ripe.net <mailto:address-policy-wg-owner@ripe.net> When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Dominik Nowacki) ---------------------------------------------------------------------- Message: 1 Date: Thu, 30 Oct 2025 14:41:09 +0000 From: Dominik Nowacki <dominik(a)clouvider.co.uk <mailto:dominik@clouvider.co.uk>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: "address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>" <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>> Message-ID: <DB9PR10MB49710786C4D9F9386DDD1D89F2FBA(a)DB9PR10MB4971.EURP <mailto:DB9PR10MB49710786C4D9F9386DDD1D89F2FBA@DB9PR10MB4971.EURP> RD10.PROD.OUTLOOK.COM> Content-Type: multipart/alternative; boundary="_000_DB9PR10MB497107 86C4D9F9386DDD1D89F2FBADB9PR10MB4971EURP_" Dear Colleagues, I agree with Max. We don't quite have a horse in this race. Clouvider has 1x legacy subnet and is a member of the RIPE NCC regardless. We use it pretty much in the same way as if it was a PA. Clara, > 1 Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date. I believe changing the policy will lead to exactly more of 1 - change won't be registered with the NCC in order for the resource not to loose its legacy status. This is significant especially that these changes don't have to be registered in order to be able to use the space - i.e. be creating route objects in alternate DBs. For that reason I oppose the proposal. If this is more of "extra work required" type of issue - then let's solve it by putting the correct price tag on it. Kind Regards, Dominik ________________________________ From: Wade, Clara via address-policy-wg <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>> Sent: 30 October 2025 14:29 To: Max Emig <ripe(a)emigm.ax <mailto:ripe@emigm.ax>> Cc: address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net> <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>>; peter.hessler(a)zayo.com <mailto:peter.hessler@zayo.com> <peter.hessler(a)zayo.com <mailto:peter.hessler@zayo.com>> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status Hi Max, I’m a little confused by the counter-argument here. Could you clarify how you believe this proposal would this lead to out-of-date data and less RPKI adoption? 1. Keeping legacy status when the resources are no longer held by the organization that received these pre-RIR administration is not really keeping the database accurate/up-to-date. 2. Legacy resource holders by default do not have access to RPKI. (You may get access by signing an agreement with the NCC, but unless you do, RPKI services are not included in the basic package offered to legacy resource holders who are not members.) Thank you, Clara From: Max Emig <ripe(a)emigm.ax <mailto:ripe@emigm.ax>> Date: Wednesday, October 29, 2025 at 4:54 PM To: "Wade, Clara" <clarawad(a)amazon.com <mailto:clarawad@amazon.com>> Cc: "address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>" <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>>, "peter.hessler(a)zayo.com <mailto:peter.hessler@zayo.com>" <peter.hessler(a)zayo.com <mailto:peter.hessler@zayo.com>> Subject: RE: [EXTERNAL] [address-policy-wg] Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status 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. Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade -------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 14864 bytes Desc: not available ------------------------------ Subject: Digest Footer ----- 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/> ------------------------------ End of address-policy-wg Digest, Vol 161, Issue 11 **************************************************

1 0

2024-01 Discussion Phase (Revised IPv6 PI Assignment Policy)
by Angela Dall'Ara 30 Oct '25

30 Oct '25

Dear colleagues,   A new version of RIPE policy proposal 2024-01 "Revised IPv6 PI Assignment Policy" is now available for discussion.   Following the last round of discussion, this proposal has been updated and it is now at version 2.0.  The main difference from version 1.0 is that the definition of 'End Site' has been removed along with the re-evaluation of addressing needs when requesting an additional or larger assignment. The authors made this version more concise and readable, and moved Purposes and Considerations under the Motivation section. 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 six-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(a)ripe.net before 28 November 2025.   Kind regards,   Angela Dall'Ara Policy Officer RIPE NCC

1 0

my last comment in the Q&A
by jordi.palet＠consulintel.es 23 Oct '25

23 Oct '25

I’ve one comment in the Q&A before the session was closed: From experience: It is true that being more generic in policy text will be better (and it is reflected in the analysis impact), but some times this works clearly against the needs of the community, because then the NCC has too strict interpretations of the text. We have seen this in the IPv6 allocation several times! So properly balancing it is the difficulty. I then realized a mistake on my text … and corrected part of it: "a small mistake in my previous text. what I wanted to say about analysis impacts is that sometimes they work against being generic in the policy text" By the way, it will be good that before closing the session, specially when there is time, we pay attention to the Q&A, otherwise, remote participation is not efficient. This is the third time that I’ve this issue in RIPE meetings ... Regards, Jordi @jordipalet ********************************************** 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.

1 0

draft proposal for resolving the sub-assignment issues with RFC9663 and RFC8273
by jordi.palet＠consulintel.es 23 Oct '25

23 Oct '25

Hi all, As I’ve already indicated this morning, a few days ago I already worked a draft for resolving those issues. I commented it in the IETF v6ops list when somebody raised the problem there. A bit of history. This is not new. The problem was clear when we had the RFC8273 and for this reason, I objected to the previous assignment definition change, and not being acknowledge, I proposed the policy 2018-02 (https://www.ripe.net/community/policies/proposals/2018-02/) So refreshing that now will be in the line of: Summary: This proposal aims to clarify the definition of "Assign" in RIPE-738 (section 2.6). The proposal solves the inconsistencies raised during community discussions on the policy proposal 2016-04, “IPv6 Sub-Assignment Clarification” where the RIPE NCC’s understanding, as explained in the impact analysis, didn’t match with the current policy text. The policy text says “Providing another entity with separate addresses (not prefixes)”, while the impact analysis said “as long as the subnet size does not exceed a /64”. In addition to cases where a /64 is used for a point-to-point link, VPNs and similar, where typically a single address is used on the “customer side” (in addition to the one used at the LIR side), the IETF has several ways to assign unique /64 prefix per interface/host (RFC 8273, RFC 9663) instead of a unique address. This, for example, allows users to connect to a hotspot, receive a /64 such that they are “isolated” from other users (for reasons of security, regulatory requirements, etc.) and they can also use multiple virtual machines on their devices with a unique address for each one (within the same /64). Another case involves a third party contracted by the End User to provide services in their network that require the deployment of other devices, servers, network equipment, etc. For example, a security surveillance system may involve the contractor providing their own cameras, recording system, even their own firewall and/or router for a dedicated VPN. In many cases, this surveillance system would need to use the addressing space of the End User. We need to understand that the concept of BYOD (Bring Your Own Device), even in enterprise networks, universities, etc., doesn't limit the number of addresses that a single device may decide to use. In fact, previous standards already allow this because a single device can get an IPv6 address by means of SLAAC, another with DHCPv6, and one more using privacy addresses. The actual policy text will not allow this, while the RIPE NCC’s understanding seems to support it. 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. 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 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 addressing space to third party devices including addresses for point-to-point links and/or non-permanently providing addressing space to third parties, for use on a network managed and operated by the assignment holder, shall not be considered a sub-assignment. The provision of addressing space for permanent or semi-permanent connectivity, such as broadband services, is still considered a sub-assignment and is prohibited under this policy. Rationale: a. Arguments Supporting the Proposal This proposal will avoid the above-mentioned discrepancies, align the policy with standards and simplify RIPE NCC clarifications and avoid misunderstandings. The proposal already continue prohibiting the use of PI for ISP services. b. Arguments Opposing the Proposal None foreseen beyond the impact analysis of 2016-04, which is still very relevant here. Inputs welcome! Also if anyone want to join the proposal, etc., etc, please let me know. Regards, Jordi @jordipalet ********************************************** 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.

1 0

Re: 2024-01 New Version Policy Proposal (Revised IPv6 PI Assignment Policy)
by Wade, Clara 18 Oct '25

18 Oct '25

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(a)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(a)fiebig.nl <mailto:tobias@fiebig.nl> <mailto:tobias@fiebig.nl <mailto:tobias@fiebig.nl>> > > Max-Planck Institut für Informatik > > Clara Wade > > clarawad(a)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/>

1 0