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 ]