New Policy Proposal (PI - PA Transfer)
Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support. I think that we need this posibility. -- Alexey Ivanov LeaderTelecom 09.10.2013 03:57 - ksyu@netassist.ua написал(а): Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support. -- Oleksandr 09.10.2013 6:14, LeaderTelecom Ltd. пишет:
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support. I think that we need this posibility.
-- Alexey Ivanov LeaderTelecom
I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. On Oct 9, 2013, at 11:57 AM, ripe@vkc.com.ua wrote:
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support.
-- Oleksandr
09.10.2013 6:14, LeaderTelecom Ltd. пишет:
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support. I think that we need this posibility.
-- Alexey Ivanov LeaderTelecom
- Andrei Kushnireuski AK1065-RIPE regID: cz.alfatelecom
I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. On Oct 9, 2013, at 11:57 AM, ripe@vkc.com.ua wrote:
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support.
-- Oleksandr
09.10.2013 6:14, LeaderTelecom Ltd. пишет:
I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
I support. I think that we need this posibility.
-- Alexey Ivanov LeaderTelecom
- Andrei Kushnireuski
I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR. - Andrei Kushnireuski
* Andrew Noable
I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR.
I believe only LIRs may hold PA space in any case. However we might consider whether it should be possible for (non-LIR) PI holders to transfer their blocks to LIRs under the provisions in section 5.5, converting them to PA in the process. (I wouldn't be opposed to that.) It would be good to get an update from the NCC on which conclusions they've drawn from the «Guidance requested» thread and how they will change their procedures (if at all). To me the community's guidance seemed clear enough, but perhaps we need to run this through the PDP anyway? Tore
Sorry I was wrong with my procedure description =( Let me clarify: As you know currently there are a lot of assigned PI resources. Based on RIPE NCC policy as soon as resources are not in use they must be returned to RIPE NCC. Now I see a 'black market' of PI resources transfer from one company to another. So company B 'purchases' unused PI IPv4 assignment from company A based on fake buy/sell contract. my suggestion is to allow PI to PA transfer for original companies only. i.e. company A already has PI assignment from RIPE NCC, if they want to change status from PI to PA they need to became LIR. If the resources were transferred from one company to another they couldn't be changed to PA because this is a variant for 'legalization' i.e. company B 'purchases' PI resources and transfers them to PA... so RIPE NCC has no reasons to return resources which were not in use... because their status was changed and now they're Allocated PA. Or transfer with justification only. P.S.: I'm sure there are a lot of unused PI Ipv4 resources are on hold by the guys who want to monetirize them and PI to PA transfer without limits is a major variant for same legalized transfer. On Oct 9, 2013, at 1:02 PM, Tore Anderson wrote:
* Andrew Noable
I think the best opportunity is to allow PI to PA transfer for LIR only... so If a resources holder is interesting to transfer their resources from PI to PA they need to be a LIR.
I believe only LIRs may hold PA space in any case. However we might consider whether it should be possible for (non-LIR) PI holders to transfer their blocks to LIRs under the provisions in section 5.5, converting them to PA in the process. (I wouldn't be opposed to that.)
It would be good to get an update from the NCC on which conclusions they've drawn from the «Guidance requested» thread and how they will change their procedures (if at all). To me the community's guidance seemed clear enough, but perhaps we need to run this through the PDP anyway?
Tore
W dniu 2013-10-09 01:34, ksyu@netassist.ua pisze:
Hello everybody
I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
Best regards, Kseniya Sokol
Full support to convert PI to PA. Many people use PI breaking policy, because they have no other way. Conversion PI to PA solves many problems. Regards Tomasz
Hi all, I think this subject was covered on this list earlier this year in the thread named; “Guidance Requested: Changing the Status of PI Address Space”. I’m just not sure what the status is right now? Do we really need to restart the discussion? Regards, Adrian [cid:image113dcb.PNG@f7d5beb6.4a8a3d8c] e-Quest | Adrian Hardy Technical Consultant T: +31 492 392626 | Support: +31 492 780780 Schootense Dreef 26 | 5708 HZ | Helmond KVK:17121883 | BTW:8009998348B01 | http://www.e-quest.nl Van: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens ksyu@netassist.ua Verzonden: woensdag 9 oktober 2013 01:35 Aan: address-policy-wg@ripe.net Onderwerp: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol
Dear Adrian, I think this subject was covered on this list earlier this year in the thread named; “Guidance Requested: Changing the Status of PI Address Space”. I’m just not sure what the status is right now? I not sure too about status, but ready to work in working group if it already exist. Could someone update about current status? -- Alexey Ivanov 09.10.2013 11:19 - Adrian Hardy написал(а): Hi all, I think this subject was covered on this list earlier this year in the thread named; “Guidance Requested: Changing the Status of PI Address Space”. I’m just not sure what the status is right now? Do we really need to restart the discussion? Regards, Adrian e-Quest | Adrian Hardy Technical Consultant T: +31 492 392626 | Support: +31 492 780780 Schootense Dreef 26 | 5708 HZ | Helmond KVK:17121883 | BTW:8009998348B01 | [1]http://www.e-quest.nl Van: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens ksyu@netassist.ua Verzonden: woensdag 9 oktober 2013 01:35 Aan: address-policy-wg@ripe.net Onderwerp: [address-policy-wg] New Policy Proposal (PI - PA Transfer) Hello everybody I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter. Best regards, Kseniya Sokol [1] http://www.e-quest.nl
Dear colleagues, Following the increasing number of requests from LIRs that want to convert their PI assignments into PA allocations, we proposed the following options at RIPE 66: 1) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size) 2) Do not allow LIRs to change the status of their PI assignments into PA allocations After RIPE 66, the discussion was continued on the Address Policy Working Group Mailing List. There seemed to be a lot of support for allowing LIRs to change the status of their resources, but people also wanted the minimum allocation size to be disregarded. This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change. We will be addressing this as part of our "Feedback From RIPE NCC Registration Services" presentation at RIPE 67. Based on the feedback we receive from here, we will work with the Working Group Chairs on a way forward. Kind regards, Andrea Cima RIPE NCC On 10/9/13 1:34 AM, ksyu@netassist.ua wrote:
Hello everybody
I would like to draw attention of the public to the next moment . According to the RIPE policy, a PI network should be used only as it was assigned. However, the time comes, the amount of clients increases, the number of services is growing up, and v4 addresses are not assigned any more. What should provider do in this case? The network was assigned for the particular service and can't be used for other services? Just returned back . But no one in their right mind will do this ) . It may be a topical solution for this situation - to return the opportunity to transfer PI blocks into the PA? This will give the opportunity to breathe more freely, not to violate the rules of RIPE policy . I suggest to discuse the question of transference of PI blocks to PA, and invite all caring to speak on the matter.
Best regards, Kseniya Sokol
Hi Andrea and thanks for the update!
This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change.
Out of curiousity, how did these come about then? ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated FWIW, I've always considered the minimum allocation size the minimum size *that the RIPE NCC may allocate* - not the minimum allocation size that may exist in the database at a given point in time. The existence of the above four allocations appears to preclude the latter interpretation in any case. With the former interpretation PI->PA conversions for blocks smaller than the minimum allocation size is quite OK by policy, as it isn't an allocation performed by the RIPE NCC from the free pool. Besides, I can't think of any reason for having a minimum allocation size in the first place except to prevent deaggregation, but these as those PI blocks are already deaggregated that's not applicable here either. IMHO, anyway... Tore
Hi Tore, On 10/10/13 1:20 PM, Tore Anderson wrote:
Hi Andrea and thanks for the update!
This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change. Out of curiousity, how did these come about then?
These are 'historical' allocations, issued a long time ago. Please find the details below.
ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated
This block was issued according to ripe-211. At that time, users requesting an allocation smaller than the default allocation size were issued an allocation from the blocks reserved for PI assignments.
ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated
The actual entry in the RIPE Database is 193.218.208.0 - 193.218.221.255.
ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated
The actual entry in the RIPE Database is 194.117.0.0 - 194.117.49.255.
ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated
The actual entry in the RIPE Database is 194.153.192.0 - 194.153.213.255. The delegated stats show allocations only on bit boundaries, resulting in multiple entries for allocated PA ranges that are not on bit boundaries. For example, 194.153.192.0 - 194.153.213.255 would be aggregatable on the following bit boundaries: 194.153.192.0/20 194.153.192.0 - 194.153.207.255 [4096] 194.153.208.0/22 194.153.208.0 - 194.153.211.255 [1024] 194.153.212.0/23 194.153.212.0 - 194.153.213.255 [512] This results in having the IP range 194.153.192.0 - 194.153.213.255 as three separate entries in the delegated stats file. We can look into changing the format output of the delegated stats file if this is considered to be a problem.
FWIW, I've always considered the minimum allocation size the minimum size *that the RIPE NCC may allocate* - not the minimum allocation size that may exist in the database at a given point in time.
The Registration Services Department has always been clear that we interpret the policy as "the minimum size of allocated PA address space". This is true both when the address space is issued as well as after it has been issued. That this is the intended spirit of the policy can also be found in section 5.5 of ripe-592, according to which allocations cannot be broken into IP blocks smaller than the minimum allocation size for transfers: "The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation". You can find the relevant section here: http://www.ripe.net/ripe/docs/ripe-592#Transfers-of-Allocations
The existence of the above four allocations appears to preclude the latter interpretation in any case.
With the former interpretation PI->PA conversions for blocks smaller than the minimum allocation size is quite OK by policy, as it isn't an allocation performed by the RIPE NCC from the free pool. Besides, I can't think of any reason for having a minimum allocation size in the first place except to prevent deaggregation, but these as those PI blocks are already deaggregated that's not applicable here either.
Please understand that I am not disputing your reasoning or opinion. We base our procedures on policy text that is set by the RIPE community. If the RIPE community believes that a policy is no longer relevant and changes this through the PDP, the RIPE NCC will change its procedures accordingly. Best regards, Andrea Cima RIPE NCC
IMHO, anyway...
Tore
On 10/10/2013 11:57, Andrea Cima wrote:
1) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size) 2) Do not allow LIRs to change the status of their PI assignments into PA allocations
Andrea, On May 7 2009, Alex le Heux posted a breakdown of IPv4 PI assignment statistics:
http://www.ripe.net/ripe/mail/archives/address-policy-wg/2009-May/004212.htm...
This indicated at at the time, only ~20% of all ipv4 PI assignments were /22 or larger. The two choices presented here mean that the 80% of people with PI assignments of /23 or less would be disenfranchised by this policy regardless of which way it might go. Also it's not compatible with the efforts under way to unify pi/pa ipv6. I.e. I don't think that either of these options is necessarily a good idea. Nick
Hi Nick, On 10/10/13 2:36 PM, Nick Hilliard wrote:
On 10/10/2013 11:57, Andrea Cima wrote:
1) Allow LIRs to change the status of their PI assignments into PA allocations (if equal or larger than the minimum allocation size) 2) Do not allow LIRs to change the status of their PI assignments into PA allocations Andrea,
On May 7 2009, Alex le Heux posted a breakdown of IPv4 PI assignment statistics:
http://www.ripe.net/ripe/mail/archives/address-policy-wg/2009-May/004212.htm... This indicated at at the time, only ~20% of all ipv4 PI assignments were /22 or larger.
The two choices presented here mean that the 80% of people with PI assignments of /23 or less would be disenfranchised by this policy regardless of which way it might go.
I would like to clarify that, by definition, IP address space with the status "ALLOCATED PA" can only be allocated to an LIR. Around 2,800 PI blocks have been assigned to organisations that later became LIRs. Approximately 1,000 of these PI assignments are equal to, or larger than, a /22. Approximately 1,800 of these PI assignments are smaller than a /22.
Also it's not compatible with the efforts under way to unify pi/pa ipv6.
I.e. I don't think that either of these options is necessarily a good idea.
We presented these two options at RIPE 66 based on feedback we had received from LIRs in our day-to-day work. After becoming LIRs, many of these organisations were asking us to change the status of their PI assignments. If the community feels there are different or better options than the ones we have suggested, we hope that these can be brought forward and discussed. Best regards, Andrea Cima RIPE NCC
Nick
participants (10)
-
Adrian Hardy -
Andrea Cima -
Andrew Noable -
Andrey Kushnireuski -
ksyu＠netassist.ua -
LeaderTelecom Ltd. -
Nick Hilliard -
ripe＠vkc.com.ua -
Tomasz Śląski GMAIL -
Tore Anderson