Hi Marco, all, Responding in-line below. Regards, Jordi @jordipalet
El 15 oct 2024, a las 12:44, Marco Schmidt <mschmidt@ripe.net> escribió:
Hello Tobias and colleagues,
While I don’t want to anticipate the formal RIPE NCC impact analysis, my initial understanding of the proposed wording is that any IPv6 allocation directly allocated can be extended to a /28. This means that your example of a /32 allocation, later extended to a /29, would still qualify for an extension to a /28.
Yes, that was the intent.
Important to note is that some older /32 IPv6 allocations (before 2016) might not be extendable, as the maximum reservation for this size at that time was /29. Additionally, if an original allocation was split, such as for a partial transfer, none of the split parts would be eligible for extension.
Our understanding from the conversations with the Policy Officer team, was that in those cases, either an additional complementary prefix, or a renumbering and return of the original one, is being offered as part of the actual RIPE NCC interpretation (when using existing policy text for subsequent allocation), and it was suggested that explicit text was not needed. In fact, our initial text had some renumbering stuff to cover that, which we removed. We received also detailed stats about all the actual allocations to consider the impact.
Regarding organisations holding 100+ /29 allocations, the current wording can be interpreted in two ways: If “IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request an extension” is understood broadly, then any allocation that hasn’t been split (or doesn’t have technical limitations) could be extended, even if it was moved to another LIR account.
With "original issued" we meant "the size", regardless of it has been transferred or not (so not the actual holder). So if transferred “as originally issued”, still can be extended. But, for example, if a /29 was issued originally, and is split in multiple /32s, then none of them can be extended.
However, a stricter interpretation is also possible, where the allocation is considered "originally issued" only to a specific LIR account. With this understanding after any transfer or consolidation to another LIR account such allocations would no longer qualify for an extension.
Maybe the proposers can clarify their intent and the working group can discuss and determine if there is agreement on this intent.
If the community prefers that we limit the intent, for example to avoid LIRs with multiple /29s to extend each of them to /28, we already have draft text, that we used in the discussions with the Policy Officer team. The risk is that limiting cases that clearly may be abusive like organizations holding 100+ /29s, we also limit valid cases of organizations that were somehow enforced to have multiple LIRs because even if the justification for needing more than /29 was “real”, was not accepted by the RIPE NCC analysis on the interpretation of the actual policy text. Let’s wait for further opinions and then we can make sure that the alternative text is what the community believes is better?
I hope this information helps the discussion.
Kind regards, Marco Schmidt Manager Registration Services
On 14/10/2024 20:02, Tobias Fiebig via address-policy-wg wrote:
Moin,
Anyway, I understood from Marco presentation in the previous meeting, that this is being already managed assuming that in those cases, you need to justify the need, which is not the case for the initial allocation. Happy to be corrected here and to incorporate some text for that if needed in our follow up proposal. My understanding is that a /29 transferred prior to the more strict handling by the NCC still remains an "IPv6 allocation originally issued directly by the RIPE NCC" after having been transferred. This means that several organizations holding 100+ /29s might expand these.
On the other hand, my /29 would not qualify, as I originally received a /32 and then expanded the initial allocation to a /29 under current policy.
It would be good if Marco could weigh in on that.
I would argue that it would make more sense to phrase this as 'one /29 -> /28 per LIR once', using a mechanic similar to the one discussed in the PI proposal 2024-1, i.e., a needs reevaluation upon transfer/enlargement combined with a single /28 being the maximum no- justification size per LIR, or limiting the maximum allocation without justification to a /28 (i.e., if you have two(+) /29, you can hand one (or the others except for one) back and get the other one expanded to a /28 without justification.
With best regards, Tobias
----- 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/
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.