Dear all,
I also support RIPE NCC's initiative for dealing with those ALLOCATED
PI/UNSPECIFIED assignments.
By the way, our company holds one of these PIs in KPN's /16. And as far
as we are concerned an annual fee of 50 EUR would be okay, too.
Kind Regards
Stefan Schiele
Am 18.08.2016 um 11:36 schrieb [email protected]:
Dear all,
From my point of view I support this initiative of the RIPE NCC as it
brings more clarity and simplicity regarding IPv4 resources management.
Hervé Clément
Orange
-----Message d'origine-----
De : address-policy-wg [mailto:[email protected]] De
la part de Ingrid Wijte
Envoyé : vendredi 5 août 2016 15:41
À : Gert Doering; Randy Bush
Cc : Larisa Yurkina; [email protected]
Objet : Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED
Dear colleagues,
>>> Also, it might lead to deaggs (Markus' case) where a /14 that was
>>> originally "in one LIR" would be "3x /16, plus some smaller
>>> fragments in the LIR" and "lots of /24 PI managed by the NCC" now -
>>> so the /14 won't get a ROA, and he'll have to announce more-specifics.
>> lemme see if i get this. to have the owner registration correct,
>> some address space will have to be broken up and owned by multiple
>> IRs, thus fragmenting routing? i like correct registration, but the
>> commons has become pretty polluted.
The main issue that we (the WG and the RIPE NCC) are trying to resolve
is the lack of clarity around the status and rights of these
assignments. It’s not necessarily the case that the End User
registration is incorrect. In many cases LIRs have put a lot of effort
into keeping this information up to date.
If there is a /16 “ALLOCATED UNSPECIFIED” block that contains "real"
Provider Independent assignments, that /16 would indeed be split in
order to carve out that assignment. The LIR would end up with multiple
PA allocations instead of one /16. The PI resource holder would be
able to decide who their sponsoring LIR should be. It is possible that
they would remain with that same LIR, or they could move to another
sponsoring LIR and take their PI assignment with them. If the resource
holder is an LIR themselves, the PI assignment could be registered
under their own LIR account.
This means that route and domain objects would need to be updated.
It’s also relevant to mention that several LIRs already allow for more
specific routes for the assignments.
The LIRs will be able to request a new ROA for their remaining blocks.
The sponsoring LIR can request a ROA on behalf of the PI resource
holder, or the PI holder can do that themselves if they wish.
I hope this answers your questions.
Ingrid Wijte
RIPE NCC
> I leave the definite answer to Ingrid to answer.
>
> My understanding of "normal" NCC<->LIR stockkeeping is that PI is
> never living inside blocks that "belong" to a given LIR. So, the LIR
> would never be able to get a ROA covering PI space.
>
> For some of these "old" blocks, there is a /16 which covers regular
> LIR/PA space, and "not real PI" space, and the LIR can get a ROA that
> covers their PA space, and also these "not real PI" blocks (because
> according to the NCC records, the /16 "belongs" to the LIR).
>
> From an aggregation PoV, this is ok-ish - but from a routing security
> PoV, I wonder if that's what we want (the "not real PI" block might be
> routed totally elsewhere now).
>
>
>>> So, to answer your question: for those "swampy PI", it would alter
>>> their rights (contracts according to 2007-01), costs (50 EUR/year)
>> whoops. that's gonna cause unhappiness.
> Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all
> the other PI holders, and the amount of unhappiness was not very big.
>
> Those cases that I was involved with my "LIR admin-c" hat on, PI
> holders seemed to be happy to have a clear contract with a known
> entity (us), and the assurance that this would ensure that nobody else
> could make claims to their address space.
>
> Gert Doering
> -- assorted hats
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
