Personally, I would suggest to increase the 2-years-period if the resulting merged LIR contains prefixes from 2 merged LIRs or more
Example:
A (has a /24) and B (has one historical /22 and another /22 from a previous merger) wants to merge: they would need to wait 3 years.
Next time, It would be 4 years, etc…
Also, if several mergers with the same LIR are requested, I honestly don’t recall if this is allowed, but it should not: one merge per LIR per year.
That should block serial-mergers, but not regular small LIRs with a real network activity.
There are probably loop-holes in my idea, or it’s perhaps too complex to implement.
David Ponzone Direction Technique
tel: 01 74 03 18 97
gsm: 06 66 98 76 34
Service Client IPeva
tel: 0811 46 26 26
Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
>My suggestion would be along the lines what was proposed on the APWG
>meeting already - earmark these /24s as non-transferrable, ever.
I don't think it is a good idea to split the IPv4 addresses into different types, transferable and non-transferrable. it puts those newcomers in a disadvantageous position compared to the older members, it is not fair and doesn't fix anything in long term.
Regards,
Arash
Hi,
On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
> As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.
As a member of the WG, I do share the sentiment that the intent of the
"IPv4 runout" policies have been "ensure that late comers to the game
can have a bit of IPv4 space, to number their IPv6 translators", and
not "grab some space for free, and sell it for more money elsewhere".
I do not think this can be fixed on the AGM level ("one legal entity
can only have one LIR account") - we've been there, in the rush to /22s,
and all it does it "make people hide behind shell companies", so in
the end, the address space goes out anyway, but registry quality suffers.
Trying to make the NCC require even more paperwork isn't going to stop
those that want to game the system, but will impact everyone else by
making the NCC more annoying to deal with.
My suggestion would be along the lines what was proposed on the APWG
meeting already - earmark these /24s as non-transferrable, ever.
Consequences:
- there is no more financial incentive to "get one cheap, sell it expensive"
- if you need space to run your business, this is exactly what it is
there for - you can still sell your business (with the /24), you
just need to keep the LIR account. But that's as with other
business assets.
- if you want to merge multiple LIR accounts, all having their own
/24 - then you need to keep around these accounts, or return some
of the /24s.
- corrolary: if you use these /24s to number your IPv6 translators,
then renumbering this translator into "your other /24" is actually
not very hard.
- corrolary2: If you use the /24s to directly number your customers,
you missed the boat already (wearing my RIPE unicorn t-shirt today).
Gert Doering
-- NetMaster
--
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
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg