This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 Stockpiling
- Previous message (by thread): [address-policy-wg] IPv6 Stockpiling
- Next message (by thread): [address-policy-wg] IPv6 Stockpiling
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Fri Oct 29 12:54:16 CEST 2021
Hi, On Fri, Oct 29, 2021 at 12:03:15PM +0200, Marco Schmidt wrote: > There might be other options that this working group can consider and > discuss. I would be very interested to hear from a few LIRs that have more than 10 allocations what their reasoning is. I know at least one enterprise that has 3 LIR accounts for different parts of their business ("internal DC networks", "cloud stuff", "office networks") which are sufficiently disjoint that they effectively are 3 different companies, owned by the same mothership - so I do understand why some setups need/want "a handful" of allocations. I can also understand a setup where a multinational ISP is organized in a way so that every country network is served by a distinct LIR, so each can handle their local addressing needs as they find appropriate - and I'd also say that this is a good use of resources (and if the company decides that they want to merge all these LIRs into one umbrella account later, you'd end up with 10+ /29s). UUnet used to do that "back in the IPv4 days", and ended up with a big stack of red voting cards at AGM :-) So, these use cases I fully understand, and find them well within the goals of the IPv6 policy - make sure people have addresses to number their networks - make sure the RIPE NCC knows where these addresses are (registry) That said, I lack imagination why LIRs would need much higher numbers of /29, so it would be good to hear about the underlying reasoning - speculation won't adjust the policies in a positive way. *That* said, I'm not alarmed either, yet. 102 /29s is, in total, a /22 of IPv6 space. If this happens a few times per RIR, it won't make a noticeable dent in the available IPv6 space - which is, of course, the other aspect we need to take into account "will $this make us run out of address space in the next 50 years?". As of now, I'm more worried about deaggregation and routing table slots than I am about total address space burn rate. Gert Doering -- just a long time IPv6 policy geek -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20211029/f5ee5efe/attachment.sig>
- Previous message (by thread): [address-policy-wg] IPv6 Stockpiling
- Next message (by thread): [address-policy-wg] IPv6 Stockpiling
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]