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/members-discuss@ripe.net/
[members-discuss] IPv6 amount for one member
- Previous message (by thread): [members-discuss] IPv6 amount for one member
- Next message (by thread): [members-discuss] IPv6 amount for one member
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Paul Thornton
paul at prtsystems.ltd.uk
Wed Oct 16 12:41:33 CEST 2019
Hi Gert, On 15/10/2019 22:46, Gert Doering wrote: > I am fairly sure there is more to this than "just because receiving > party already had a /29" - nothing in the policies would forbid that. > > Gert Doering > -- NetMaster > As a datapoint, I certainly have been on the receiving end of this. Consider this scenario: LIR X has an existing /29, and LIR Y has a /32. Closing LIR Y and transferring all resources to LIR X triggered just such a question. I know that >/29 allocations are of course allowed - I think the issue arises when an LIR has their whole "initial largest" /29 allocation and then adds more through acquisition or transfer. Paul.
- Previous message (by thread): [members-discuss] IPv6 amount for one member
- Next message (by thread): [members-discuss] IPv6 amount for one member
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]