2024-02 New Policy Proposal (IPv6 Initial Allocations /28)
Dear colleagues, A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now available for discussion. This proposal aims to change the initial IPv6 allocation size from /29 to /28. 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 the Discussion Phase is to discuss the proposal and provide feedback to the proposer. 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 12 November 2024. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
I see in the new policy text, this was added to 5.7: """[one or more IPv6 allocations] that were originally issued directly by the RIPE NCC as a single prefix may request [embiggening]""". Can the authors explain why this text was added? -peter On 2024 Oct 14 (Mon) at 15:18:58 +0200 (+0200), Angela Dall'Ara wrote: :Dear colleagues, : :A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now :available for discussion. : :This proposal aims to change the initial IPv6 allocation size from /29 to :/28. : :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 the :Discussion Phase is to discuss the proposal and provide feedback to the :proposer. : :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 12 November 2024. : : :Kind regards, :Angela Dall'Ara :Policy Officer :RIPE NCC -- It's illegal in Wilbur, Washington, to ride an ugly horse.
Moin, On Mon, 2024-10-14 at 15:45 +0200, Peter Hessler wrote:
I see in the new policy text, this was added to 5.7: """[one or more IPv6 allocations] that were originally issued directly by the RIPE NCC as a single prefix may request [embiggening]""".
Can the authors explain why this text was added?
I am not the authors, but I assume that this is to prevent an entity holding a /32 from a /29 having that extended to /28 not, i.e., creating a new full- size allocation out of a single /32. I would argue, though, that given the recent notes on v6 hoarding (and in the same spirit as that restriction) the policy should also include a limit to one allocation for which this can be done per LIR; And ideally, some mechanic limiting abuse of this by people holding _a lot_ of initial allocations. With best regards, Tobias
Hi Tobias, As I just said, we have been strongly encouraged to do small steps …. My personal preference will be a single big proposal with all the changes, but it seems is not good for the discussion (even if we sucesfully did multiple times). 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. Regards, Jordi @jordipalet
El 14 oct 2024, a las 16:35, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> escribió:
Moin,
On Mon, 2024-10-14 at 15:45 +0200, Peter Hessler wrote:
I see in the new policy text, this was added to 5.7: """[one or more IPv6 allocations] that were originally issued directly by the RIPE NCC as a single prefix may request [embiggening]""".
Can the authors explain why this text was added?
I am not the authors, but I assume that this is to prevent an entity holding a /32 from a /29 having that extended to /28 not, i.e., creating a new full- size allocation out of a single /32.
I would argue, though, that given the recent notes on v6 hoarding (and in the same spirit as that restriction) the policy should also include a limit to one allocation for which this can be done per LIR; And ideally, some mechanic limiting abuse of this by people holding _a lot_ of initial allocations.
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/
********************************************** 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.
On Mon, 14 Oct 2024 at 08:17, jordi.palet--- via address-policy-wg < address-policy-wg@ripe.net> wrote:
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.
My concern is that people won’t voice their opinion when reading “0-“, but because of the above weird legal disclaimer If it off-ftoipc away…. Kind regards, Job
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
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. 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. 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. 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. 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/
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.
Hi Marco, On Tue, Oct 15, 2024 at 12:44:35PM +0200, Marco Schmidt wrote:
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.
I think it would be good if the IA could say a few words on how the NCC would deal with this case. Basically there's a few options - "you are out of luck, as there is no space to make this a /28" or "you can trade in your /32-reserved-/29, and get a new /28 instead", or something else. Allocating a second noncontiguous /29 "to get to a /28" would sound like a bad idea to me as the proposal talks about "nibbles" and "aggregation" :-) (I'm sure you've thought of all of this already, but just wanted to mention my thoughts on this) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert, In a previous draft or the proposal we had some text to explicitly indicate that if a contiguous allocation is not possible, the RIPE NCC should offer either a complementary prefix or a new unique prefix and the time for renumbering and returning the previous one. However, in talks with the policy development team, as this is already the current practice and just works, they seem to prefer not to make this explicit in the text, adding unnecessary complexity. In any case, definitively agree that the IA should confirm that. Regards, Jordi @jordipalet
El 27 oct 2024, a las 14:20, Gert Doering <gert@space.net> escribió:
Hi Marco,
On Tue, Oct 15, 2024 at 12:44:35PM +0200, Marco Schmidt wrote:
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.
I think it would be good if the IA could say a few words on how the NCC would deal with this case. Basically there's a few options - "you are out of luck, as there is no space to make this a /28" or "you can trade in your /32-reserved-/29, and get a new /28 instead", or something else.
Allocating a second noncontiguous /29 "to get to a /28" would sound like a bad idea to me as the proposal talks about "nibbles" and "aggregation" :-)
(I'm sure you've thought of all of this already, but just wanted to mention my thoughts on this)
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ----- 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.
The point may be a single extension to /28 for each original allocation per organization instead of per LIR? Regards, Jordi @jordipalet
El 14 oct 2024, a las 20:02, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> escribió:
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/
********************************************** 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.
I think per LIR would already suffice to deal with the 100s of /29s issue; Per organization might even be better. On Tue, 2024-10-15 at 13:31 +0200, jordi.palet--- via address-policy-wg wrote:
The point may be a single extension to /28 for each original allocation per organization instead of per LIR?
Regards, Jordi
@jordipalet
El 14 oct 2024, a las 20:02, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> escribió:
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/
********************************************** 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.
----- 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/
-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
To give some context: Only 14 LIRs have more than 50 /29 allocations (see https://labs.ripe.net/author/marco_schmidt/ipv6-stockpiling-a-trojan-horse-i...) About 100 LIRs have more than 10 /29 allocations, and around 1,000 have more than 2 allocations. I don't see a major issue with allowing LIRs with two allocations to extend both to a /28 (assuming the allocations were made after 2006, as earlier allocations may not be contiguous). With RIPE NCC enforcing stricter rules on organizations with multiple LIRs ,particularly preventing additional /29 requests when existing allocations aren't announced, the stockpiling problem should not worsen. The core intent of this "Only one LIR can get /28" rule is to prevent the top 100 "stockpilers" from getting a /28 instead of a /29. To be clear, I support the rule of limiting each LIR or organization to one /28 extension. However, we should also consider that all those /29s that are reserved will remain unusable because they are blocked. regards, Rinse Kloek On 15-10-2024 18:44, Tobias Fiebig via address-policy-wg wrote:
I think per LIR would already suffice to deal with the 100s of /29s issue; Per organization might even be better.
On Tue, 2024-10-15 at 13:31 +0200, jordi.palet--- via address-policy-wg wrote:
The point may be a single extension to /28 for each original allocation per organization instead of per LIR?
Regards, Jordi
@jordipalet
El 14 oct 2024, a las 20:02, Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> escribió:
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/
********************************************** 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.
----- 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/
Hi, On Thu, Oct 17, 2024 at 05:06:03PM +0200, Rinse Kloek wrote:
However, we should also consider that all those /29s that are reserved will remain unusable because they are blocked.
I'm not sure I understand this. If a /29 is reserved, it's reserved because the initial allocation was a /35 or /32 - so those allocations can not grow to a /28. Bad luck. Indeed, if we get a lot of returns "I must have a /28, so here's my /32-reserved-/29 back!" we would have a fragmented address pool at the NCC, with /29s that can not form a /28. OTOH, do you expect every new LIR to ask for a /28? I admit I have not read the proposal yet, but if it's in line with what we currently have, a LIR could just signal "a /32 is good for me" and get one of those /29 holes... (Our /32 has lasted us 26 years so far, and we'll never fill it - so we've never extended it to a /29, because, why?) Gert Doering -- 2nd IPv6 allocation made by RIPE NCC -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I was referring to the /29 initial allocations after 2016, when the RIPE NCC began reserving a /28 by default for those /29's. The proposal states: "LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 or /28 without needing to supply any additional information." This means it's either a /32 or a /28. It will depend on how the RIPE NCC handles the request. I assume that, by default, the RIPE NCC initially provides a /32 and informs the LIR that they have the option to extend it to a /28 without needing to supply further justification. Rinse Kloek On 17-10-2024 17:16, Gert Doering wrote:
Hi,
On Thu, Oct 17, 2024 at 05:06:03PM +0200, Rinse Kloek wrote:
However, we should also consider that all those /29s that are reserved will remain unusable because they are blocked. I'm not sure I understand this. If a /29 is reserved, it's reserved because the initial allocation was a /35 or /32 - so those allocations can not grow to a /28. Bad luck.
Indeed, if we get a lot of returns "I must have a /28, so here's my /32-reserved-/29 back!" we would have a fragmented address pool at the NCC, with /29s that can not form a /28.
OTOH, do you expect every new LIR to ask for a /28? I admit I have not read the proposal yet, but if it's in line with what we currently have, a LIR could just signal "a /32 is good for me" and get one of those /29 holes...
(Our /32 has lasted us 26 years so far, and we'll never fill it - so we've never extended it to a /29, because, why?)
Gert Doering -- 2nd IPv6 allocation made by RIPE NCC
On 17-10-2024 17:16, Gert Doering wrote:
OTOH, do you expect every new LIR to ask for a /28? I admit I have not read the proposal yet, but if it's in line with what we currently have, a LIR could just signal "a /32 is good for me" and get one of those /29 holes...
To give some numbers on this: Of the 628 allocations that have been done to LIRs in 2024 so far we have 560 /29 and only 68 /32. So the vast majority of LIRs (about 90%) have opted for /29 allocations, with only a small fraction choosing /32 allocations. If given the choice between /28 or /32, it's likely we would see a similar trend, with the majority of LIRs preferring the larger /28 block for future scalability and flexibility, similar to the pattern observed with the /29 allocations. (Data from delegated-ripencc-extended-20241017 file from the RIPE ftp server.)
Hi Peter, This has been proposed to avoid an entity to keep splitting, for example an original /29 into multiples /32, and then ask for the extension to /28 of each of them, abusing the system. Regards, Jordi @jordipalet
El 14 oct 2024, a las 15:45, Peter Hessler <phessler@theapt.org> escribió:
I see in the new policy text, this was added to 5.7: """[one or more IPv6 allocations] that were originally issued directly by the RIPE NCC as a single prefix may request [embiggening]""".
Can the authors explain why this text was added?
-peter
On 2024 Oct 14 (Mon) at 15:18:58 +0200 (+0200), Angela Dall'Ara wrote: :Dear colleagues, : :A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now :available for discussion. : :This proposal aims to change the initial IPv6 allocation size from /29 to :/28. : :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 the :Discussion Phase is to discuss the proposal and provide feedback to the :proposer. : :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 12 November 2024. : : :Kind regards, :Angela Dall'Ara :Policy Officer :RIPE NCC
-- It's illegal in Wilbur, Washington, to ride an ugly horse. ----- 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 Jordi, Thanks for the explanation, makes perfect sense. -peter On 2024 Oct 14 (Mon) at 17:02:08 +0200 (+0200), jordi.palet--- via address-policy-wg wrote: :Hi Peter, : :This has been proposed to avoid an entity to keep splitting, for example an original /29 into multiples /32, and then ask for the extension to /28 of each of them, abusing the system. : :Regards, :Jordi : :@jordipalet : : :> El 14 oct 2024, a las 15:45, Peter Hessler <phessler@theapt.org> escribió: :> :> I see in the new policy text, this was added to 5.7: """[one or more :> IPv6 allocations] that were originally issued directly by the RIPE NCC as :> a single prefix may request [embiggening]""". :> :> Can the authors explain why this text was added? :> :> -peter :> :> :> On 2024 Oct 14 (Mon) at 15:18:58 +0200 (+0200), Angela Dall'Ara wrote: :> :Dear colleagues, :> : :> :A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now :> :available for discussion. :> : :> :This proposal aims to change the initial IPv6 allocation size from /29 to :> :/28. :> : :> :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 the :> :Discussion Phase is to discuss the proposal and provide feedback to the :> :proposer. :> : :> :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 12 November 2024. :> : :> : :> :Kind regards, :> :Angela Dall'Ara :> :Policy Officer :> :RIPE NCC :> :> :> -- :> It's illegal in Wilbur, Washington, to ride an ugly horse. :> ----- :> 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. : : : :----- :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/ -- Pascal, n.: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984
Hi all, An important point about this proposal to keep in mind. Our initial goal is to address multiple changes as discussed in the IPv6 policy overall review during the last months, mainly moving all allocations to nibble boundary, replacing the HD-Ratio for a simpler method and facilitate aggregation. We have a draft text of the “complete" proposal, but it has been suggested that is better to split it in 2-3 proposals to simplify the discussion. This way the community can agree in every step even if it takes longer to reach consensus on the complete final goal, but if we agree only in a few changes, that’s better than nothing. Saludos, Jordi @jordipalet
El 14 oct 2024, a las 15:18, Angela Dall'Ara <adallara@ripe.net> escribió:
Dear colleagues,
A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now available for discussion.
This proposal aims to change the initial IPv6 allocation size from /29 to /28.
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 the Discussion Phase is to discuss the proposal and provide feedback to the proposer.
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 <mailto:address-policy-wg@ripe.net> before 12 November 2024.
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/
********************************************** 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.
So everyone gets a /28 and then the new billing scheme comes out and charges based on IPv6 usage starting from /32 (small) to /29 (medium) to /28 (xtra large)? 😂 On 14.10.24 15:18, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now available for discussion.
This proposal aims to change the initial IPv6 allocation size from /29 to /28.
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 the Discussion Phase is to discuss the proposal and provide feedback to the proposer.
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 12 November 2024.
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/
Dear all, Its good idea to give /27 because ripe ncc reserve /27 even if they give /29. And 2nd note. Its better ripe ncc allow normal transfers of IPv6 according the address polices. Thats nonsense, that community spend a lot of time and work for policy development. But some short mic speach can stop a lot of ipv6 movenent. If members need transfers of IPV6 ripe ncc should do, but not block transfers. As a fact Ripe ncc stopped transfers because they don't accept the answers from LIRs. If we follow the mic lets follow the mic everywhere. If we follow polices - lets follow polices. Yury B. On Fri, Oct 18, 2024, 19:24 Patrick Velder <lists@velder.li> wrote:
So everyone gets a /28 and then the new billing scheme comes out and charges based on IPv6 usage starting from /32 (small) to /29 (medium) to /28 (xtra large)? 😂 On 14.10.24 15:18, Angela Dall'Ara wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now available for discussion.
This proposal aims to change the initial IPv6 allocation size from /29 to /28.
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 the Discussion Phase is to discuss the proposal and provide feedback to the proposer.
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 12 November 2024.
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/
----- 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/
Hi, On Fri, Oct 18, 2024 at 07:34:54PM +0400, Yury Bogdanov wrote:
If members need transfers of IPV6 ripe ncc should do, but not block transfers.
Could you explain, in simple words, why "100 /29s in a single LIR" is something members *need*? Nobody has given a proper answer for that so far (and the question has been asked more than once) - and while stockpiling might be allowed according to previous policies, it's not good stewardship - and this is part of what we do here. Good stewardship of Internet resources. Policies permit allocation of huge blocks for huge networks, so if you need lots of addresses, come and get a /19 - no need to hoard /29s instead. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Is there a shortage of IPv6 that nobody told me about?? -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: Gert Doering <gert@space.net> Date: Friday, 18 October 2024 at 16:46 To: Yury Bogdanov <ipmarket.ae@gmail.com> Cc: address-policy-wg@ripe.net <address-policy-wg@ripe.net> Subject: [address-policy-wg] Re: 2024-02 New Policy Proposal (IPv6 Initial Allocations /28) [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Hi, On Fri, Oct 18, 2024 at 07:34:54PM +0400, Yury Bogdanov wrote:
If members need transfers of IPV6 ripe ncc should do, but not block transfers.
Could you explain, in simple words, why "100 /29s in a single LIR" is something members *need*? Nobody has given a proper answer for that so far (and the question has been asked more than once) - and while stockpiling might be allowed according to previous policies, it's not good stewardship - and this is part of what we do here. Good stewardship of Internet resources. Policies permit allocation of huge blocks for huge networks, so if you need lots of addresses, come and get a /19 - no need to hoard /29s instead. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-----Original message-----
Is there a shortage of IPv6 that nobody told me about??
Technically: no. Administratively: yes. Every request has to be verified by humans, RIPE NCC only has a limited amount of manpower to handle all requests. Hoarders put a disproportionate load onto that process.
Chapter 3 of the current policy explains the main goals, with Chapter 3.5 focusing on conservation, meaning every allocation should be reasonable. However, Chapter 3.4 talks about aggregation and comes before conservation, which suggests that keeping address space together (aggregated) is more important. I think having address space in large, continuous blocks is more important. This is why the change from /29 to /28 was made, so LIRs have enough space from the start. It also reduces the need for LIRs to gather multiple separate /29 blocks and transfer them, which will help reduce the workload for the RIPE NCC. Your point seems to support always giving a /28 and removing the option to ask for a /32 (90% already goes for the /29 option in the current policy). Having just one default allocation would make things simpler and stop LIRs from needing to request more space later, making the process easier for everyone. Rinse On 21-10-2024 09:02, Michiel Klaver via address-policy-wg wrote:
-----Original message-----
Is there a shortage of IPv6 that nobody told me about?? Technically: no. Administratively: yes.
Every request has to be verified by humans, RIPE NCC only has a limited amount of manpower to handle all requests. Hoarders put a disproportionate load onto that process.
----- 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/
Sure, members doesn't need that now. Currently we're talking about huge allocations compared to IPv4. But... Aren't we just slaves of our past based in IPv4 world, which in the fact created us? It's just a philosophical question. - Daniel On 10/18/24 5:45 PM, Gert Doering wrote:
Could you explain, in simple words, why "100 /29s in a single LIR" is something members *need*?
Hi, On Fri, Oct 18, 2024 at 10:35:56PM +0200, Daniel Suchy via address-policy-wg wrote:
Sure, members doesn't need that now. Currently we're talking about huge allocations compared to IPv4.
But...
Aren't we just slaves of our past based in IPv4 world, which in the fact created us?
It's just a philosophical question.
"Wouldn't it be nice!" is not a good argument for stockpiling 100+ /29s. RIPE policies still operate based on need, even if that is applied much more loose on IPv6. Demonstrate need. IPv6 policies can (and do) change over time, if need changes, or more experience leads to different views on the policy (/35 -> /32 -> /29), but "we do not need that now" is not a very compelling argument. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 21. 10. 24 18:06, Gert Doering wrote:
Aren't we just slaves of our past based in IPv4 world, which in the fact created us?
It's just a philosophical question.
"Wouldn't it be nice!" is not a good argument for stockpiling 100+ /29s.
RIPE policies still operate based on need, even if that is applied much more loose on IPv6. Demonstrate need.
Hey, This was sorted out at previous RIPE meeting at the APWG session. Marco asked for guidance and the feedback from the community was clear. According to the policy - every LIR has an initial allocation of /32 up to /29 without any need of additional documentation. Every additional allocation needs an explanation, and transfers of /29s now fall under that category, as that actually *is* an additional allocation. Something like: "You already have one /29, can you explain why you require another one? Show me the usage of the initial one and what kind of monster of a network you are building that you require another /29". Problem with hoarders solved (hopefully). Cheers, Jan
Hello, Policy but not the microphone should work in any case. If LIR have v6 it also has a right to transfer or receive other v6 from other LIRs. This is normal. If the LIRs asked for that then they need it. NCC doesnt ask ipv4 plan for transfers of ipv4, even ipv4 is not in use. For IPv6 should be the same! NCC gets request for v6 transfers but starts asking lot of question and NCC managers are not experts here how to build internet and business. There is normal limit that LIR get his initial allocation and thats it. It was comfortable. And NCC doesnt accept normal answers why do people need. As an example that they prefer to have /29 for each hardware location if it done by default in IT infrastructure. So I strongly disagree if NCC block transfers of IPv6. For last year we got a lot of angry talks from netizens about this. When people need some extra IPv6 they could go and get it from NCC or from other LIRs. And people prefer to go to LIRs because of NCC bureaucracy. And there not so many transfers around ipv6 for this year. Yury B. On Tue, Oct 22, 2024, 19:57 Jan Zorz - Go6 <jan@go6.si> wrote:
On 21. 10. 24 18:06, Gert Doering wrote:
Aren't we just slaves of our past based in IPv4 world, which in the fact created us?
It's just a philosophical question.
"Wouldn't it be nice!" is not a good argument for stockpiling 100+ /29s.
RIPE policies still operate based on need, even if that is applied much more loose on IPv6. Demonstrate need.
Hey,
This was sorted out at previous RIPE meeting at the APWG session. Marco asked for guidance and the feedback from the community was clear.
According to the policy - every LIR has an initial allocation of /32 up to /29 without any need of additional documentation. Every additional allocation needs an explanation, and transfers of /29s now fall under that category, as that actually *is* an additional allocation.
Something like: "You already have one /29, can you explain why you require another one? Show me the usage of the initial one and what kind of monster of a network you are building that you require another /29".
Problem with hoarders solved (hopefully).
Cheers, Jan
----- 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/
Hi, On Tue, Oct 22, 2024 at 08:26:44PM +0400, Yury Bogdanov wrote:
And NCC doesnt accept normal answers why do people need. As an example that they prefer to have /29 for each hardware location if it done by default in IT infrastructure.
And this would be a very good example of very poor network design unless you happen to be a hyperscaler. Most likely also violating address policy. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Tue, 22 Oct 2024 at 09:27, Yury Bogdanov <ipmarket.ae@gmail.com> wrote:
Hello,
Policy but not the microphone should work in any case. If LIR have v6 it also has a right to transfer or receive other v6 from other LIRs.
This is normal. If the LIRs asked for that then they need it.
That would be a policy change. The current policy is described in section 5.2: https://www.ripe.net/publications/docs/ripe-738/#52-subsequent-allocation That is what the RIPE NCC is implementing. Kind regards, Leo Vegoda, for the co-chairs
On 22. 10. 24 18:26, Yury Bogdanov wrote:
Hello,
Policy but not the microphone should work in any case.
I think this is exactly what's written in the policy :) Initial allocation is without documentation, additional IPv6 space needs explanation ;) The problem was that in the past the RIPE NCC did not deploy the policy as it was meant. Cheers, Jan
From my own experience with RIPE NCC: If you have an org with 2 or more LIRs and do have an /29 on the first LIR that is not used (not announce in the BGP table): When requesting an IPv6 /29 for the second or LIR, RIPE NCC will ask you if you really need this /29 as you have not announced the previous one. On 22-10-2024 17:57, Jan Zorz - Go6 wrote:
On 21. 10. 24 18:06, Gert Doering wrote:
Aren't we just slaves of our past based in IPv4 world, which in the fact created us?
It's just a philosophical question. "Wouldn't it be nice!" is not a good argument for stockpiling 100+ /29s.
RIPE policies still operate based on need, even if that is applied much more loose on IPv6. Demonstrate need. Hey,
This was sorted out at previous RIPE meeting at the APWG session. Marco asked for guidance and the feedback from the community was clear.
According to the policy - every LIR has an initial allocation of /32 up to /29 without any need of additional documentation. Every additional allocation needs an explanation, and transfers of /29s now fall under that category, as that actually *is* an additional allocation.
Something like: "You already have one /29, can you explain why you require another one? Show me the usage of the initial one and what kind of monster of a network you are building that you require another /29".
Problem with hoarders solved (hopefully).
Cheers, Jan
----- 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/
On 23. 10. 24 12:15, Rinse Kloek wrote:
From my own experience with RIPE NCC:
If you have an org with 2 or more LIRs and do have an /29 on the first LIR that is not used (not announce in the BGP table): When requesting an IPv6 /29 for the second or LIR, RIPE NCC will ask you if you really need this /29 as you have not announced the previous one.
...and that's a good question ;) Cheers, Jan -- Anything that can be configured can be misconfigured. [RFC5505]
On Oct 18, 2024, at 11:34, Yury Bogdanov <ipmarket.ae@gmail.com> wrote:
Dear all, Its good idea to give /27 because ripe ncc reserve /27 even if they give /29.
I would like to hear some justification for that motion. Something tangible, just a bit more than 'IPv6 deployment experience' from Jordi and you. -- Sergey
On 18-10-2024 17:34, Yury Bogdanov wrote:
Its good idea to give /27 because ripe ncc reserve /27 even if they give /29.
The reason RIPE reserves some space is to allow for growth and to be able to provide the LIR with a The goal is not to allocate an LIR a /27 or /26 if they only need a /32. This contiguous block is also made so that the LIR can have a single BGP announcement for their IPv6 routes (which we, as router maintainers, would appreciate since it reduces the need for routers with larger FIB capacity). Here is an random example from the RIPE Delegated file from ftp.ripe.net. You see that even a /25 is "reserved" if an allocation is done for a /29: 2001:3bc0:: 29 allocated to LIR 2001:3bc8:: 29 reserved 2001:3bd0:: 28 reserved 2001:3be0:: 27 reserved 2001:3c:: 29 (This hole is missing in the RIPE delegated file, somebody knows why ?) 2001:3c08:: 29 reserved 2001:3c10:: 28 reserved 2001:3c20:: 27 reserved
On 2024 Oct 18 (Fri) at 19:09:24 +0200 (+0200), Rinse Kloek wrote: :On 18-10-2024 17:34, Yury Bogdanov wrote: :> Its good idea to give /27 because ripe ncc reserve /27 even if they give :> /29. : :The reason RIPE reserves some space is to allow for growth and to be able to :provide the LIR with a :The goal is not to allocate an LIR a /27 or /26 if they only need a /32. This :contiguous block is also made so that the LIR can have a single BGP :announcement for their IPv6 routes (which we, as router maintainers, would :appreciate since it reduces the need for routers with larger FIB capacity). : :Here is an random example from the RIPE Delegated file from ftp.ripe.net. You :see that even a /25 is "reserved" if an allocation is done for a /29: : :2001:3bc0:: 29 allocated to LIR :2001:3bc8:: 29 reserved :2001:3bd0:: 28 reserved :2001:3be0:: 27 reserved :2001:3c:: 29 (This hole is missing in the RIPE delegated file, somebody knows why ?) 2001:3c:: is actually 2001:003c:: I think you mean 2001:3c00::/29 :2001:3c08:: 29 reserved :2001:3c10:: 28 reserved :2001:3c20:: 27 reserved : : -peter
On 18-10-2024 19:13, Peter Hessler wrote:
I think you mean 2001:3c00::/29
Yes, you are completely right, I meant|2001:3c00::/29|. However, we still have this "hole." Is there a technical reason for this?
I missed some records during import of the delegation files: 2001:3bc0:: 29 allocated to LIR 2001:3bc8:: 29 reserved 2001:3bd0:: 28 reserved 2001:3be0:: 27 reserved 2001:3c00:: 29 allocated to LIR (this record was missing in my import) 2001:3c08:: 29 reserved 2001:3c10:: 28 reserved 2001:3c20:: 27 reserved RIPE NCC explained that for every /29 they reserve a /26, so this matches the table above. However if we will go for nibble boundary, we will have a lot of reserved space left as the next step after /28 will be the /24. Rinse On 18-10-2024 19:17, Rinse Kloek wrote:
On 18-10-2024 19:13, Peter Hessler wrote:
I think you mean 2001:3c00::/29 Yes, you are completely right, I meant|2001:3c00::/29|. However, we still have this "hole." Is there a technical reason for this?
----- 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/
Hi, On Fri, Oct 18, 2024 at 05:24:17PM +0200, Patrick Velder wrote:
So everyone gets a /28 and then the new billing scheme comes out and charges based on IPv6 usage starting from /32 (small) to /29 (medium) to /28 (xtra large)? ????
I'm sure the board has heard often enough that this would be a highly undesirable change. We want to encourage use of IPv6, not give ISPs a financial incentive to squeeze their customers into a much smaller block, leading to unwanted effects like "customers can no longer get a /56" or even "customers will get a single IPv6 address". I happen to know that one of the board members understands IPv6 well and was involved in one of those BCP documents... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I am the Co-Chair of the Charging Scheme Task Force, and will speak on our behalf. This is a topic that we are well aware of, and will keep an eye on. Any of our recommendations will consider standard allocation sizes and historical guidelines from the RIPE community and RIPE NCC. -peter On 2024 Oct 18 (Fri) at 17:24:17 +0200 (+0200), Patrick Velder wrote: :So everyone gets a /28 and then the new billing scheme comes out and charges :based on IPv6 usage starting from /32 (small) to /29 (medium) to /28 (xtra :large)? 😂 : :On 14.10.24 15:18, Angela Dall'Ara wrote: :> Dear colleagues, :> :> A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is :> now available for discussion. :> :> This proposal aims to change the initial IPv6 allocation size from /29 to :> /28. :> :> 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 the :> Discussion Phase is to discuss the proposal and provide feedback to the :> proposer. :> :> 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 12 November 2024. :> :> :> Kind regards, :> Angela Dall'Ara :> Policy Officer :> RIPE NCC
Hi, On Mon, Oct 14, 2024 at 03:18:58PM +0200, Angela Dall'Ara wrote:
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 12 November 2024.
I'm somewhat neutral on the *need* for this change - a /29 is quite a huge block of addresses (= only few networks will not be able to fit into it) and - coming frmo a /35 - I do not see "DNS is made easier" as a compelling reason - this is setup once for the top level domain or domains ("8 ip6.arpa zones for a /29"), and then the much more interesting question on "how to deal with possibly zillions of records and subdomains?" starts. This said, I do not see much harm in this - the numbers permit doing /28s as minimum size for LIRs. OTOH, I do not see the need to state "/32 *or* /28" in the policy document, because both the NCC and the LIRs will need to deal with non-nibble-sized allocations forever - so forcing this now ("I need a /31, but have to take a /28, why?") is not something I'd go for. "allocation of /32 up to /28" would do the job for those who want a /28 just fine. (JFTR, we have a /32 that came from being a /35 - and it has never been extended to a /29, because, why? We're never going to fill it, unless our business model changes in very significantly). Short answer: neutral on the /28 thing, but permit a range. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (16)
-
Angela Dall'Ara -
Daniel Suchy -
Gert Doering -
Jan Zorz - Go6 -
Job Snijders -
jordi.palet＠consulintel.es -
Leo Vegoda -
Marco Schmidt -
Michele Neylon - Blacknight -
Michiel Klaver -
Patrick Velder -
Peter Hessler -
Rinse Kloek -
Sergey Myasoedov -
Tobias Fiebig -
Yury Bogdanov