Update on ALLOCATED PI/UNSPECIFIED
Dear colleagues, During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input. BACKGROUND Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation. In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be. ACTION TAKEN At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs. The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below. The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC. 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). 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. After the LIRs have finished their research, the RIPE NCC will: - Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA. We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations. In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution. We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016. Kind regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC
Hello Ingrid That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC? Best regards Patrick On 04.08.2016 09:39, Ingrid Wijte wrote:
Dear colleagues,
During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input.
BACKGROUND
Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation.
In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be.
ACTION TAKEN
At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs.
The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below.
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
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).
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.
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations.
In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution.
We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016.
Kind regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
Patrick Velder пишет 04.08.2016 11:12: Hi
Hello Ingrid
That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC?
Best regards Patrick
My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it? With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
On 04.08.2016 09:39, Ingrid Wijte wrote:
Dear colleagues,
During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input.
BACKGROUND
Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation.
In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be.
ACTION TAKEN
At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs.
The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below.
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
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).
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.
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations.
In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution.
We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016.
Kind regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
--
Hi PI (Provider Independent) should be "Provider Independent" - any space which is assigned by a LIR is not really "provider independent". I think it's a good idea to change that. Regards Patrick On 04.08.2016 12:36, Larisa Yurkina wrote:
Patrick Velder пишет 04.08.2016 11:12:
Hi
Hello Ingrid
That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC?
Best regards Patrick
My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it?
With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
On 04.08.2016 09:39, Ingrid Wijte wrote:
Dear colleagues,
During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input.
BACKGROUND
Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation.
In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be.
ACTION TAKEN
At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs.
The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below.
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
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).
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.
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations.
In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution.
We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016.
Kind regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
Patrick Velder пишет 04.08.2016 13:59:
Hi
PI (Provider Independent) should be "Provider Independent" - any space which is assigned by a LIR is not really "provider independent". I think it's a good idea to change that.
Regards Patrick
Thanks for explanation Patrick :) Let's change 'status' from 'ASSIGNED PI', 'ASSIGNED PA' to 'ASSIGNED-BY-LIR', 'ASSIGNED-BY-RIPE NCC' since this is the same. 'Aggregatable', 'Independent', are very much obsoleted words only confusing people.
On 04.08.2016 12:36, Larisa Yurkina wrote:
Patrick Velder пишет 04.08.2016 11:12:
Hi
Hello Ingrid
That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC?
Best regards Patrick
My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it?
With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
On 04.08.2016 09:39, Ingrid Wijte wrote:
Dear colleagues,
During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input.
BACKGROUND
Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation.
In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be.
ACTION TAKEN
At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs.
The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below.
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
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).
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.
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations.
In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution.
We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016.
Kind regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
-- With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it?
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
i am perennially confused by the different colors of integers. as you know, i prefer magenta and comic sans. ingrid/ncc can you explain in terms an antique router geek can understand what the actual pragmatic effect would be on these PI/PA holders? does it alter holders' rights? costs? processes? ... i suspect that you, larisa, already understand that. in this case, why, in pragmatic terms a router geek can understand (yes, i know that's a high bar, sorry), do you not like it? randy
Hi, On Thu, Aug 04, 2016 at 08:12:56PM +0900, Randy Bush wrote:
i am perennially confused by the different colors of integers. as you know, i prefer magenta and comic sans.
Not all prefixes belong to Rüdiger, so, magenta is out...
ingrid/ncc can you explain in terms an antique router geek can understand what the actual pragmatic effect would be on these PI/PA holders? does it alter holders' rights? costs? processes? ...
Right now, there are two different shades of "PI colour" - "real PI" and "not really real PI". The first shade has the full obligations and protection of 2007-01 - namely, a contractual relationship (via a sponsoring LIR) with the NCC that clearly identifies who has "rights" to that prefix. The other shade is also labeled "PI", but whether or not contracts exist, and who is the legitimate holder, is less well defined. This proposal aims to unify all PI into one colour, which I think is good for the resource holders (no uncertainity) - but there is potential fallout, like "we've been doing IPv4 PI assignments all the years, and nobody bothered!" - which technically could be done from "ALLOCATED UNSPECIFIED" blocks, but was always outside RIPE policies - and if these are now properly labeled and tagged, certain business practices might no longer be possible. 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. There is no "truly nice" solution to this. It's swampy space that will smell when you try to clean it up (but some people insist that parts of that swamp is *theirs* and want all the titles that come with that...). So, to answer your question: for those "swampy PI", it would alter their rights (contracts according to 2007-01), costs (50 EUR/year), processes (sponsoring LIR, instead of "no clear process"). Quite some change. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Right now, there are two different shades of "PI colour" - "real PI" and "not really real PI".
is there a list of all the colors and what they mean?
This proposal aims to unify all PI into one colour, which I think is good for the resource holders (no uncertainity) - but there is potential fallout, like "we've been doing IPv4 PI assignments all the years, and nobody bothered!" - which technically could be done from "ALLOCATED UNSPECIFIED" blocks, but was always outside RIPE policies - and if these are now properly labeled and tagged, certain business practices might no longer be possible.
are certain business practices to be compared to uncertain business practices? :) i have this feeling you are trying to say something here. i.e. if i am the LIR, can i move "not really real PI" between customers and no one knows?
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.
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. randy
Hi, On Thu, Aug 04, 2016 at 08:59:07PM +0900, Randy Bush wrote:
Right now, there are two different shades of "PI colour" - "real PI" and "not really real PI". is there a list of all the colors and what they mean?
I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", and those are well-defined. Add "Legacy" to it (outside RIR framework). We have learned that there are more interesting shades, namely "ALLOCATED PI", "ALLOCATED UNSPECIFIED" and "ASSIGNED PI (not really)" - these are not seen often, and their meaning is not all that clear. [..]
i have this feeling you are trying to say something here. i.e. if i am the LIR, can i move "not really real PI" between customers and no one knows?
Maybe. "not really real PI" is happening outside the RIPE policy framework - namely, no 2007-01 contracts, the NCC has no idea who the "real" address holder is, and the holder cannot complain to the NCC if all of a sudden "his" address space is registered to someone else... There seems to be "old stuff that happened 15+ years ago" and "new stuff that is still ongoing", so there won't be "one solution" either.
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.
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 -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Thu, Aug 04, 2016 at 02:10:33PM +0200, Gert Doering wrote:
Hi,
[Randy]> 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.
Acting, amongst other tasks on the LIR side of the table, as a consultant to/representative of an organization holding & actively using several PI assignments from AU space I can fully second that. We can happily live with the fees. But not being able to "act fully autonomously" with regard to those netblocks is considered quite annoying and has even hindered some network redesign efforts in the past ("how can we be sure $NETBLOCK will still be routed properly once we touch sth?" etc.). So leaving that uncertainty behind us and having a clear contractual relationship with RIPE NCC would be very welcome, from this specific common's perspective. Me seems a cleaned up RIPE DB is a good thing, too. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
Hi Gert,
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.
No. It was big. But you prefer not to mention that. That’s your perception, please don’t say ‘we’.
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.
By the way, 2007-01 has produced a new market with ~2 MEUR/yr volume. Do you really think that PI holders were happy to pay such amount? -- Kind regards, Sergey Myasoedov
Hi, On Thu, Aug 04, 2016 at 04:29:59PM +0200, Sergey Myasoedov wrote:
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.
No. It was big. But you prefer not to mention that. That???s your perception, please don???t say ???we???.
"We" was related to "we rolled out 2007-01", and yes, that was "all of us". It might be that *you* were unhappy about it, but that's not the general sentiment I heard from other markets.
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.
By the way, 2007-01 has produced a new market with ~2 MEUR/yr volume. Do you really think that PI holders were happy to pay such amount?
In this thread, you've seen statements from PI holders, clearly stating that they do not care at all for 50 EUR/year if they get clear contractual rights in return. As a network administrator, I do have my "own" /24 PI (... dating back to 1993 or so), and I also pay 50 EUR/year for it. I have considered whether that is enough of an annoyance to return it to the IPv4 pool, and decided that it has enough sentimental value for me to keep it. So yes, PI holders are OK with that. Note that I did not say "everybody was happy and celebrated". I said "the amount of unhappiness was not very big" - which translates to "a bit of grumbling and cursing here and there, but nobody decided to raise a big stink in the AGM or ask their regulator to take over from the RIPE NCC". Right? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Fri, Aug 5, 2016, at 08:25, Gert Doering wrote:
of grumbling and cursing here and there, but nobody decided to raise a big stink in the AGM or ask their regulator to take over from the RIPE NCC". Right?
Hi, Wasn't this also because those that were unhappy did not have access to the AGM ? I am aware of cases where "someones" lost pretty big chunks of PI (up to /21) because they wanted way to much independence (including independence from RIPE and RIPE NCC).... except they were too small and were missing some local administrativia for the regulator to even read their complaint. I do agree that those cases were a minority for the whole service area, but there were cases where things were less clear (e.g. dating back to a time where some of us were stuck to "NIR"s a.k.a "last resort registries" which could do whatever they wanted).
On 5 Aug 2016, at 16:11, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote: dating back to a time where some of us were stuck to "NIR"s a.k.a "last resort registries" which could do whatever they wanted)
Registries of last resort were allocated their own blocks, separate to the main lir allocations. Fwir, all cc.zz assignments should have been from these blocks and were assigned pi. Nick
I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", and those are well-defined. Add "Legacy" to it (outside RIR framework).
inetnum: 198.180.150.0 - 198.180.153.255 netname: RG79-198-180-150 country: US org: ORG-RG79-RIPE sponsoring-org: ORG-SSP3-RIPE admin-c: RB366-ARIN tech-c: RB366-ARIN status: LEGACY mnt-by: MAINT-RGNET mnt-domains: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT created: 2016-03-16T15:13:51Z last-modified: 2016-04-14T10:44:25Z source: RIPE randy
Hi, On Thu, Aug 04, 2016 at 11:37:48PM +0900, Randy Bush wrote:
I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", and those are well-defined. Add "Legacy" to it (outside RIR framework).
inetnum: 198.180.150.0 - 198.180.153.255 netname: RG79-198-180-150 country: US org: ORG-RG79-RIPE sponsoring-org: ORG-SSP3-RIPE admin-c: RB366-ARIN tech-c: RB366-ARIN status: LEGACY
Well. Sorry for not being precise in my wording. What I tried to say is that LEGACY is a special status that acknowledges that these prefixes have been given out before the RIRs existed. They live "outside the RIR framework" as far as being subject to RIPE policy is concerned - except in well-defined documents, RIPE policy does not apply to LEGACY space. They *do* live "within" the RIR framework as far as documentation is concerned, and this is very good :-) In any case, they have a very distinct shade of grey... ;-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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
Hi Ingrid,
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.
So in the current situation such a PI resource holder has "Provider Independent" space, but only if they stay with the LIR that holds the ALLOCATED UNSPECIFIED. After the change the PI holder will have a normal PI assignment that they can register with any sponsoring LIR they want. So I guess that PI holders will be happy about this, it turns their "kind-of" PI into "real" PI. And the affected LIRs might be less happy because they lose some grip on their customers. And then there seem to be cases where the ALLOCATED PI/UNSPECIFIED is used more like PA space (managed, aggregated and routed by the LIR) in which case converting it to ALLOCATED PA might be more reasonable (for route objects, ROAs etc) but that might make the "PI" holder less happy. Although in such a case it seems to me that the address space isn't really independent to begin with, so in reality things will probably remain the same for them, just better formally documented. Cheers, Sander
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:address-policy-wg-bounces@ripe.net] De la part de Ingrid Wijte Envoyé : vendredi 5 août 2016 15:41 À : Gert Doering; Randy Bush Cc : Larisa Yurkina; address-policy-wg@ripe.net 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.
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 herve.clement@orange.com:
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:address-policy-wg-bounces@ripe.net] De la part de Ingrid Wijte Envoyé : vendredi 5 août 2016 15:41 À : Gert Doering; Randy Bush Cc : Larisa Yurkina; address-policy-wg@ripe.net 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.
On 04.08.2016 13:59, Randy Bush wrote:
i have this feeling you are trying to say something here. i.e. if i am the LIR, can i move "not really real PI" between customers and no one knows?
These PIs are real PIs (at least thought to be), but not "fully registered" with RIPE as other PIs. Yes, in theory the LIR could withdraw these PIs, but certainly will run into trouble and get complaints doing so. If such a PI is returned to the LIR, the LIR could re-assign them to other end-users. Or create new PIs even RIPE itself does not longer issue PIs (as Gert wrote "but was always outside RIPE policies", but IMHO also not explicitly prohibited). Markus -- 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
Randy Bush wrote:
Gert Doering wrote: 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
Well, my example was for a /16 (not the /14, which comes with another story), currently announced by the LIR as /16 and partially as /17, with 6 smaller ranges announced by another entity of this LIR and 23 PIs announced out of 38 (so much for "accuracy" ...) by other ASes. Breaking up the /16 into PIs and PAs would end up with 42 new prefixes in the routing table (beside the current 3+6+38 seen ones). OTOH, at least the 23 announced prefixes would become PIs as the others (50€ for the LIR or a direct agreement with RIPE) and the remaining 15 PIs would be either returned or registered as the rest. @Ingrid: Have you made an analysis, how many new prefixes would show up in the routing table by de-aggregation the A-PI/A-U allocations (best case/ worst case), how many of the PIs in there are currently seen (or not) as separate announcement? Just to get a feeling ... (yes, everyone can do this, but everyone is busy ... ;-). Markus -- 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
On Thu, 4 Aug 2016, Netmaster (KPN Eurorings B.V. Germany) wrote: (snip)
@Ingrid: Have you made an analysis, how many new prefixes would show up in the routing table by de-aggregation the A-PI/A-U allocations (best case/ worst case), how many of the PIs in there are currently seen (or not) as separate announcement? Just to get a feeling ... (yes, everyone can do this, but everyone is busy ... ;-).
http://www.cidr-report.org/as2.0/ 04-08-16 = 622607 It seems nobody really cares about the routing table... ;-) Cheers, Carlos
Markus
-- 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
Hi Gert, Gert Doering wrote: [...]
Right now, there are two different shades of "PI colour" - "real PI" and "not really real PI". The first shade has the full obligations and protection of 2007-01 - namely, a contractual relationship (via a sponsoring LIR) with the NCC that clearly identifies who has "rights" to that prefix. The other shade is also labeled "PI", but whether or not contracts exist, and who is the legitimate holder, is less well defined.
Can you please expand on this? What are the risks that registrants of "not really real PI" face? Andrea's slide included a bullet stating that: "Many LIRs do not have contact with ASSIGNED PI customers anymore" Should I understand that to mean that there is a risk the LIR could take back the assignment? Kind regards, Leo Vegoda
Hi, On Thu, Aug 04, 2016 at 04:33:48PM +0000, Leo Vegoda wrote:
Gert Doering wrote:
[...]
Can you please expand on this? What are the risks that registrants of "not really real PI" face? Andrea's slide included a bullet stating that:
"Many LIRs do not have contact with ASSIGNED PI customers anymore"
Should I understand that to mean that there is a risk the LIR could take back the assignment?
This is one potential risk, or someone else could try to grab it and claim "this is mine", with no contractual data at the NCC to settle the dispute. Without a clear agreement and clear policies to govern these numbers, it's hard to rely on anything. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Randy Bush пишет 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address space >> was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", >> all of them have agreement with the LIR, which also was within the >> policy, at least not against. Why should we change anything here? Just >> because some LIRs lost their control over 50% of the address space >> allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, “Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region”. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, why, > in pragmatic terms a router geek can understand (yes, i know that's a > high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
Hi, On Thu, Aug 04, 2016 at 02:39:48PM +0300, Larisa Yurkina wrote:
[...] creates a lot of additional job for my LIR.
That is why I'd prefer not to change anything here.
wow. that's a really (RIPE) community-oriented statement. and a technically sound argument, too. cheers Enno
-- With respect,
*Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> ??.: +7 495 737-0604
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
Hi Everybody, I agree with Larisa. As a LIR 'responsible for ALLOCATED UNSPECIFIED blocks, the amount of work to change all that would be huge compared to the gain. Back in 2002, I did a review of these blocks and managed to get a good number of assignments back, that we re-used as ASSIGNED PA. It also allowed us to update the real PI records. But this was quite a time-intensive exercise I'd prefer not to do again. Furthermore, knowing that our allocations are full to 90%, there's not much room for 'misuse' the PI policy (which actually does not apply in this case!) by assigning PI ourselves -> so benefit is quite inexistent Regards, André -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Larisa Yurkina Sent: Thursday, August 04, 2016 1:40 PM To: Randy Bush <randy@psg.com> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Randy Bush пишет 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address >> space was not aggregated and was used as "ASSIGNED PI within >> ALLOCATED PI", all of them have agreement with the LIR, which also >> was within the policy, at least not against. Why should we change >> anything here? Just because some LIRs lost their control over 50% of >> the address space allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, “Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region”. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, > why, in pragmatic terms a router geek can understand (yes, i know > that's a high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
Once again since it seems not to have gone through... -----Original Message----- From: Chapuis André, INI-ON-EPC-IPE Sent: Thursday, August 04, 2016 3:15 PM To: 'l.yurkina@ripn.net' <l.yurkina@ripn.net>; Randy Bush <randy@psg.com> Cc: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Hi Everybody, I agree with Larisa. As a LIR 'responsible for ALLOCATED UNSPECIFIED blocks, the amount of work to change all that would be huge compared to the gain. Back in 2002, I did a review of these blocks and managed to get a good number of assignments back, that we re-used as ASSIGNED PA. It also allowed us to update the real PI records. But this was quite a time-intensive exercise I'd prefer not to do again. Furthermore, knowing that our allocations are full to 90%, there's not much room for 'misuse' the PI policy (which actually does not apply in this case!) by assigning PI ourselves -> so benefit is quite inexistent Regards, André -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Larisa Yurkina Sent: Thursday, August 04, 2016 1:40 PM To: Randy Bush <randy@psg.com> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Randy Bush пишет 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address >> space was not aggregated and was used as "ASSIGNED PI within >> ALLOCATED PI", all of them have agreement with the LIR, which also >> was within the policy, at least not against. Why should we change >> anything here? Just because some LIRs lost their control over 50% of >> the address space allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, “Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region”. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, > why, in pragmatic terms a router geek can understand (yes, i know > that's a high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina@ripn.net <mailto:l.yurkina@ripn.net> / www.ripn.net <http://www.ripn.net> Т.: +7 495 737-0604
On Thu, 4 Aug 2016, Larisa Yurkina wrote:
Patrick Velder ????? 04.08.2016 11:12:
Hi
Hello Ingrid
That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC?
Best regards Patrick
My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it?
Yes, if it aint broken, don't try to fix it. However Ingrid is right that "data accuracy must have the highest priority" and if the status tag causes confusion maybe something have to be done. The problem is that we aim for a very binary black and white world and forget that all of these labels were not there in the beginning. In our particular case we have been handling address space for three decades and the line between legacy in 1991 and the NCC era in 1992 was not very sharp. First none of the space had any status. Then (still in the 1990's) a colleague arbitrarily put the "ALLOCATED PI/ASSIGNED PI" status everywhere. Then (a couple of years ago) the NCC decided some blocks where LEGACY (assignments were made before 1992) and some not (assignments were made in 1992 or shortly afterwards), however all of the space have been treated both as LEGACY and PA earlier on. The use of PI was obviously based on a misunderstanding and the non-legacy blocks have been PA all the time so apparently you learn as long as you live. I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes the database more readable but I still agree with you Larisa that if we have been going on like this for decades, why the sudden urge to change it now? The end users will certainly be a bit worried by the sudden change. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
Hi, On Thu, Aug 04, 2016 at 05:58:26PM +0200, Daniel Stolpe wrote:
I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes the database more readable but I still agree with you Larisa that if we have been going on like this for decades, why the sudden urge to change it now? The end users will certainly be a bit worried by the sudden change.
maybe, maybe not. Quite some won't be reachable or won't exist any more and won't even know that the assignment ever existed (or, for that matter, what an IP address is). Still I expect that a few of those being aware of the issue and actively running services in those netblocks will not be worried. I can only speak for one (ex-) end user organization (albeit one holding several [AU] PI assignments from different [covering] LIRs, so probaly a "large one" in those terms) but I can state that we will be not be worried but in fact *very relieved* once clarity wrt administrative responsibility is reached. It might be noteworthy that these assignments were handed out in the 90s as part of "Internet service" contracts in the corporate space, hence usually (not too tiny) amounts of money were involved. I leave the conclusions to the reader... best Enno
Cheers, Daniel
_________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
On Thu, 4 Aug 2016, Enno Rey wrote:
Hi,
On Thu, Aug 04, 2016 at 05:58:26PM +0200, Daniel Stolpe wrote:
I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes the database more readable but I still agree with you Larisa that if we have been going on like this for decades, why the sudden urge to change it now? The end users will certainly be a bit worried by the sudden change.
maybe, maybe not. Quite some won't be reachable or won't exist any more and won't even know that the assignment ever existed (or, for that matter, what an IP address is). Still I expect that a few of those being aware of the issue and actively running services in those netblocks will not be worried. I can only speak for one (ex-) end user organization (albeit one holding several [AU] PI assignments from different [covering] LIRs, so probaly a "large one" in those terms) but I can state that we will be not be worried but in fact *very relieved* once clarity wrt administrative responsibility is reached.
It might be noteworthy that these assignments were handed out in the 90s as part of "Internet service" contracts in the corporate space, hence usually (not too tiny) amounts of money were involved. I leave the conclusions to the reader...
You are right. "Mixed reactions" is probably a better description of the forecast. We have hundreds of customers/end users in theese blocks. Some will know and understand. Some will not. As always. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm
On 04.08.2016 09:39, Ingrid Wijte wrote:
Dear colleagues,
During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input.
BACKGROUND
Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation.
I had all my ASSIGNED PIs changed to status:LEGACY. If it was done to all my legacy allocations why can't it be done for these as well? -Hank
In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be.
ACTION TAKEN
At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs.
The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below.
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
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).
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.
After the LIRs have finished their research, the RIPE NCC will:
- Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA.
We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations.
In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution.
We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016.
Kind regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
Hi, On Thu, Aug 04, 2016 at 02:21:25PM +0300, Hank Nussbacher wrote:
I had all my ASSIGNED PIs changed to status:LEGACY. If it was done to all my legacy allocations why can't it be done for these as well?
I assume that your allocations actually have been legacy allocations all along, pre-dating the RIPE NCC. These had been converted to "PI" at one point, but the legacy policy gave you the option to convert them back to "legacy". *This* is about PIs that came from the RIPE NCC's stock, so, no "legacy" in the sense of "pre-NCC allocations from Internic" here. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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
Am 04.08.2016 um 13:05 schrieb Netmaster (KPN Eurorings B.V. Germany):
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. I represent one of the PI resource holders especially in one of "your" /14 unspecified blocks, thus let me point out some things, I of course have the resource hold hat on, too:
- It is not on the side of the resource holders that they can't be contacted, it is just that it is difficult to us to find a LIR contact that is responsive. You probably know about the dificulties with big organisations and there have been no approach to contact us in the last years. - At the time your company received the /14 from the *liquidator* of KPNQwest, the unspecified and PI attributes were already installed. This means: Your company knew, what they bought, and they knew, that there were third party rights *already*. This means: These third party PI has to be respected (and in our case: We got a statement from RIPE NCC that we received and use it in good favor, and yes, we still use it and do not intend to change this). - There are of course no contracts any more, bankrupt LIR means bankrupt LIR means bankrupt LIR (in this case: KPNQwest had been *liquidated*, *no* transfer of rights, because otherwise KPN would have had to pay the old KPNQwest debts what they didn't). - Thus in general: If the solution is to split, if there is *no other* agreement and the RIPE NCC wants to separate this spaces, it has to. "Big companies effort" is no reason to interfere with third party rights or just grab them. - *However*: Reasonable people typically find reasonable solutions. The current /24 over /14 works for us - as long as KPN routes any traffic misrouted then to correct destination, provides RDNS (this is a thing that should be discussed how to handle), does not block maintainers (dto.!) etc. - For us it is just important to clarify that the current situation does not give the unspecified "holder" any specific rights, which means: Any solution like that above works as long as the third party rights are *respected* by the big party, too. It is on the side of the "unspecified" holder (LIR) to reach mutual agreement, because they want to reduce the effort. - It is as with all resources: At the end, organization rules here or there, it ends up that resources are something important to individuals or organisations and resources that have been registered as independent for more than 15 years are obviously covered by EU law, thus this is not a decision that can be done just by majority vote or company policy or whatever, it is as with other resources something that is protected by law. With respect Oliver -- Bartels System GmbH + 80935 München, Germany + Ust. Id. DE129296210 oliver@bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG München HRB85259 + Geschäftsführer Oliver Bartels
Further below some comments on Oliver's statement, which (*) probably do not contribute much to this discussion, but I felt some words are needed. (*) which = the comments, if the majority of statements do, I leave up to you to decide. But Oliver brought up indeed one interesting aspect (beside the operational question on how to secure RDNS): What about legal aspects (for both "sides")? Oliver Bartels wrote:
It is as with all resources: At the end, organization rules here or there, it ends up that resources are something important to individuals or organisations and resources that have been registered as independent for more than 15 years are obviously covered by EU law, thus this is not a decision that can be done just by majority vote or company policy or whatever, it is as with other resources something that is protected by law.
Have there at all ever been a case where a LIR holding A-PI/-U space withdraw an end user's PI on purpose and against the will/without the agreement of the end user and the end user went to court as RIPE NCC couldn't have this sorted out? Markus Oliver Bartels wrote:
It is not on the side of the resource holders that they can't be contacted, it is just that it is difficult to us to find a LIR contact that is responsive. You probably know about the dificulties with big organisations and there have been no approach to contact us in the last years.
I agree that finding the right contacts in big organizations might be difficult. But if you state, it's always easy to find contacts for PIs, I do not agree at all ... you've probably never tried to do some "cleanups". BTW: the email address you had last contact with K* about your address ranges back in 2002 still works ... so at least you should have had no problems ...
- At the time your company received the /14 from the *liquidator* of KPNQwest, the unspecified and PI attributes were already installed. [...] This means: [...]
Just to make it clear, as your statements could be read quite negative: KPN always respected (and will continue to respect) the "rights" of the PI owners out of the former de.xlink allocations. Further, all main contact email addresses of Xlink, KPNQwest in regards to address management still work.
If the solution is to split, if there is *no other* agreement and the RIPE NCC wants to separate this spaces, it has to. "Big companies effort" is no reason to interfere with third party rights or just grab them.
Who is grabbing which rights?
- *However*: Reasonable people typically find reasonable solutions. The current /24 over /14 works for us - as long as KPN routes any traffic misrouted then to correct destination, provides RDNS (this is a thing that should be discussed how to handle), does not block maintainers (dto.!) etc.
The routing ... where should we route the traffic to if the Internet does not already do this and you are not connected to KPN? (The only thing I could think of would be the case where some networks in the middle do filter on some questionable allocation sizes and traffic ends up within our network AND there's a known path from us to you.) RDNS is indeed a very valid point as the /16 is delegated to KPN and we delegate further. I do understand the concerns and consider this as well a non-optimal solution. About the "does not block maintainers". This is an agreement / out- come of an old discussion between RIPE NCC and us as LIR years ago. It has been re-verified recently and RIPE NCC confirmed: "yes, don't give out maintainers". So whom are you blaming for what? -- 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
Am 04.08.2016 um 23:50 schrieb Netmaster (KPN Eurorings B.V. Germany):
Further below some comments on Oliver's statement, which (*) probably do not contribute much to this discussion, but I felt some words are needed. (*) which = the comments, if the majority of statements do, I leave up to you to decide.
They contribute a lot, because your reaction including the "co not contribute" statement is a nice demonstration of the problems arising regarding from the nearly non-existing relation between "unspecified" and PI holders. There *are* different interests. Period.
But Oliver brought up indeed one interesting aspect (beside the operational question on how to secure RDNS): What about legal aspects (for both "sides")? That *is* a point.
With IPv4 we are no longer talking about administrative issues only, like it was in the times when I administered a full LIR. The only way to obtain IPv4 space except for the initial /22 is to use money and buy it on the free market. This is why RIPE changed their policies. And when money is involved, standard commercial law applies.
Have there at all ever been a case where a LIR holding A-PI/-U space withdraw an end user's PI on purpose and against the will/without the agreement of the end user and the end user went to court as RIPE NCC couldn't have this sorted out? I believe you that *you* won't withdraw or grab such resource.
However, the company you work for belongs to the free share market, a lot of shares currently belong thru a holding to a single person who already decided to sell Eplus to Telefonice, which then decided to "integrate" (means: take customers and some base stations, liquidate/close the remaining stuff) it. Besides the liquidation act of KPNQwest. There is no gurantee at all that not tomorrow someone decides to sell your divsion to an x far east hedge fonds, which then decides to close the german NOC including your position, monetarize everything regardless of the rights of PI holders etc. We as as small company survived big XLINK, big KPNqwest, big KPN as a state owned company (now: 0% Netherlands), we survived several big equipment vendors (last: Alcatel, sad enough) etc. We want true *independence* on our resources. And this is why the issue should be solved formally by registering PI as PI, which it is, and not as "dependend from the good will of x until bought by hedge fonds y". This means: PI should be *independent* in the database, from what I read from your statement, you do not like the current RDNS solution, too, thus there should be some independent (RIPE based) solution. We can talk about not splitting the routing table, your company will probably see our announcement and thus forwarding in case of (typically not used) more specific filters should work.
About the "does not block maintainers". This is an agreement / out- come of an old discussion between RIPE NCC and us as LIR years ago. It has been re-verified recently and RIPE NCC confirmed: "yes, don't give out maintainers". So whom are you blaming for what? PI space should show up in the database as: mnt-by: RIPE-NCC-END-MNT mnt-by: resource-holder-MNT and there is no reason to lock out the resource holder as it is practiced. Regardless who says this, there are rules.
Kind Regards Oliver -- Bartels System GmbH + 80935 München, Germany + Ust. Id. DE129296210 oliver@bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG München HRB85259 + Geschäftsführer Oliver Bartels
Oliver Bartels wrote:
There *are* different interests. Period.
Agree. You and some others like "a true independence resource", others really don't care as long as it works, some don't like to pay money as long is not needed, some don't like to pick up the work, some probably don't like changes, some others probably don't like the outcome and what it does mean and others ... This is why we are talking about it. While you are open to swap your PIs out of our A-U, others would never consider renumbering as an option. Different interests, different approaches ...
There is no gurantee at all that not tomorrow someone decides to sell your divsion to an x far east hedge fonds, which then decides to close the german NOC including your position, monetarize everything regardless of the rights of PI holders etc.
Either PI holders have rights or they don't. In your other email you stated
This means: Your company knew, what they bought, and they knew, that there were third party rights *already*.
Why wouldn't this be valid for Far East hedge funds?
About the "does not block maintainers". This is an agreement / outcome of an old discussion between RIPE NCC and us as LIR years ago. [...] PI space should show up in the database as: mnt-by: RIPE-NCC-END-MNT mnt-by: resource-holder-MNT and there is no reason to lock out the resource holder as it is practiced. Regardless who says this, there are rules.
This should be discussed with RIPE NCC (again) as source of this "lock out" rule ... rule vs. rule ... but eventually not needed as the final approach should cover this. Markus -- 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
Oliver Bartels wrote:
This means: Your company knew, what they bought, and they knew, that there were third party rights *already*. Why wouldn't this be valid for Far East hedge funds? In *theory* it is valid. In *theory* if you have deposits in Icelandic banks, you have
Am 05.08.2016 um 07:44 schrieb Netmaster (KPN Eurorings B.V. Germany): the right to get them back, covered by international agreements. You may even take Hypo Alpe Adria/HETA bank bonds *guaranteed* by the Austrian (!) federal state Kaernten, that is not too far away. A state gurantee says and means: 100% money back plus interest. In *theory* Great Britain is a stable member of the European Union and your big investements there should give you access to the EU common market under *current* GB and EU law. In *practice*: Good luck ... And: Have you ever tried to handle a dificult non-scheme problem calling your mobile operators call center located in India ... We are living in difficult and unstable times, and RIPE NCC provides international services, it is quite easy to move resources between different countries, it is quite difficult to apply a constant legislation on them. Thus the party insuring the resources should be RIPE and no one else. KInd Regards Oliver -- Bartels System GmbH + 80935 München, Germany + Ust. Id. DE129296210 oliver@bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG München HRB85259 + Geschäftsführer Oliver Bartels
Returning to the initial discussion ... Ingrid Wijte wrote:
The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC.
It reads like this is already written in stone ... is it ??? If this would be the case, the only way to achieve this (to have PIs out of A-PI/-U to be treated as all other PIs, give their holders the same rights, "safety" and obligations) is - to split up the A-PI/-U as you proposed or - move all PIs out of the A-PI/-U (or convert them to PA and move some PIs) => renumbering PI holder, address space win for LIR or - have the LIR even return the full A-PI/-U (and if wanted get back a same sized PA) => renumbering LIR, "loss" of A-PI/-U (which brings up again the question, if assigning "new" PIs out of A-PI/-U would be really against currently policy) Did I miss anything? Even if the object could be locked within the RIPE DB, contractual everything could be secured and e.g. RDNS is fixed as well: the PI as being a more specific within LIR's A-PI/-U and the issues arising of this could probably never be solved within other ways (or it's too early). If things suddenly don't work out any more like they did the last 15++ years and the consensus is to have it "solved", it's the question what is the best approach, what does it mean, what are the drawbacks, is it worth taking multiple approaches and who at the end pays the bill. Markus -- 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
participants (19)
-
Andre.Chapuis＠swisscom.com -
Carlos Friacas -
Daniel Stolpe -
Enno Rey -
Gert Doering -
Hank Nussbacher -
herve.clement＠orange.com -
Ingrid Wijte -
Larisa Yurkina -
Leo Vegoda -
Netmaster (KPN Eurorings B.V. Germany) -
Nick Hilliard -
Oliver Bartels GmbH -
Patrick Velder -
Radu-Adrian FEURDEAN -
Randy Bush -
Sander Steffann -
Sergey Myasoedov -
Stefan Schiele