On 04.08.2016 09:39, Ingrid Wijte wrote:
It was also stated that LIRs should not register any new assignments with the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments (with the exception of IXP PI assignments from our reserved address pool).
Does the current policy really states, that new IPv4 PI can't be made out of those assignments? I only read "The RIPE NCC no longer allocates or assigns PI address space".
APPROACH The RIPE NCC will contact the 38 LIRs holding allocations that contain address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). In the following months, these LIRs will check if their RIPE Database entries are still correct. Each LIR will check their records and with their customers to see under what conditions the assignments were originally provided.
Before that you said 50% don't have any contacts with the end-user, holding the PI. Who will be in the lead to contact those parties?
Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
That's the ugly part I don't like, but I'm biased. For those few of us being long enough around to have such allocations and with my current reading of the policy, you take away from us the possibility to assign PIs to end-users ... fair enough, if my reading is incorrect, this is not relevant anyway. But splitting current A-PI/-U is as such not really a nice thing. It will leave the initial holders of the ranges with little fragments. True, nothing which cannot be handled, but if I announce e.g. a /16 or have to announce 50+ (or more or less) /20-/24s, it makes a difference (operational and financially). Yes, more filters, reverse zones, ROAs, ... Yes, everything is possible, but I don't like it. OTOH, I understand the wish of the community -and support it-, to treat all PI owners equal ("Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region") and the end-users request to maintain their PI inetnum on their own. Even for the party with the A-PI/-U it might be a relieve no longer discussing and maintaining the PIs of non-customers. If I would have a choice, I would prefer RIPE NCC to think about how to lock PIs within these special allocations to allow the end-user to manage their PIs directly, force them to comply to the "Contractual Requirements", locking out the A-PI/-U owner to touch the inetnums of PIs ... but this probably will not work out or be too "complicated" or come with side effects someone will complain about later (e.g. the less-specific route object of the A-PI/-U holder, the A-PI/-U holder's ROA for it). TBC Markus PS: Yes, KPN's LIR have A-U. Thus I'm biased. But I know how bad it feels suddenly having to announce and handle smaller fragments instead of the full allocation, as a lot of address space (most of the AS517/AS286, Xlink/ EUnet allocations) moved to other KPN departments, leaving us (AS286) with some more specifics ... and yes, sometimes you have to pay per prefix ... -- Darmstädter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | <Markus.Weber@kpn.DE> | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Geschäftsführer Jesus Martinez & Jacob Leendert Hage