Guidance Requested: Changing the Status of PI Address Space
Dear colleagues, The RIPE NCC has seen an increase in the number of organisations requesting to change the status of IP addresses from "assigned PI" to "allocated PA". At the Address Policy WG session during RIPE 66, we requested guidance from the RIPE community on what we should do with these requests. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the requests to turn PI assignments into PA allocations are coming from organisations that received a PI assignment in the past and have since become LIRs. These requests may also come from LIRs that have taken over End User organisations with PI addresses. PA allocations have more flexibility than PI assignments. With the scarcity of IPv4 addresses, organisations are looking to use this space for customer assignments or to transfer it, but are prevented from doing so by the policy for PI addresses. Problem: current RIPE Policy does not address the change in status from assigned PI to allocated PA. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) B. Do not allow LIRs to change the status of their PI assignments to PA allocations Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf Thank you in advance for your feedback Andrea Cima RIPE NCC
* andrea
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
This. I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway. There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA. Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation. Besides, it is some precedent here too afaict: 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 Tore
* andrea
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) I think, that allow changing purpose of address space from pi to pa will allow more optimal using of address space. Some of pi allocations which i know, are used only because there are "fixed" ip which can't be changed (vpn concetrators, dns servers). rest of pi space isn't used. Allow of translation would allow use of rest of this space and assign it to customers. I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway.
There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA.
Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation. I'm for this idea. If allocation is already made - and it's already visible in internet -
W dniu 20.06.2013 10:20, Tore Anderson pisze: there is no reason to treat it differently only because it's a bit smaller than others.
Besides, it is some precedent here too afaict:
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
Tore
-- Regards, Andrzej 'The Undefined' Dopierała http://andrzej.dopierala.name/
I agree with both his points: Allow translation and don't check allocation size. Do we still care about usage on v4? If yes, when does such a check happen? Before PI is translated to PA or afterwards, I.e. when they need more? Richard
* Tore Anderson
* andrea
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
This.
I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway.
There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA.
Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation.
Besides, it is some precedent here too afaict:
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
Tore
fully agreed +1 kind regards Christoph
Andrea, all - full ACK to both: * Allow status change from LIRs' PI assignments to PA allocations and to Tore's point: * Omission of the minimum allocation size constraint Cheers, -C. On 20.06.2013 10:20, Tore Anderson wrote:
* andrea
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
This.
I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway.
There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA.
Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation.
Besides, it is some precedent here too afaict:
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
Tore
Agreed. On Thu, 20 Jun 2013, Carsten Schiefner wrote:
Andrea, all -
full ACK to both:
* Allow status change from LIRs' PI assignments to PA allocations
and to Tore's point:
* Omission of the minimum allocation size constraint
Cheers,
-C.
On 20.06.2013 10:20, Tore Anderson wrote:
* andrea
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
This.
I cannot see how denying such requests could possibly be to the benefit of the community. On the other hand I can clearly see that denying them would be detrimental by making the NCC appear rigid, inflexible, and customer-unfriendly; and likely also running counter to the policy's Registration goal, as some of the LIRs that got such conversion requests refused would likely go ahead and use the addresses as if they were labeled PA anyway.
There is some related precedent, cf. section 5.4 regarding conversion from ALLOCATED PI and ALLOCATED UNSPECIFIED to ALLOCATED PA.
Personally, I'd even take it one step further and omit the minimum allocation size constraint too. I consider the minimum allocation size a policy mechanism that is only there to serve the Aggregation goal. However, as these delegations are already made, merely relabeling them does not make any difference when it comes to aggregation.
Besides, it is some precedent here too afaict:
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
Tore
Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
On 20.06.2013 13:28, Carsten Schiefner wrote:
Andrea, all -
full ACK to both:
* Allow status change from LIRs' PI assignments to PA allocations
and to Tore's point:
* Omission of the minimum allocation size constraint
Full +1 from my side. from ripe perspective the only difference I can see is the fact that PI is charged seperately. I clearly remember the (funny mentioned) words at last GM: "we are already trying hard to make a deficit, but obviously we failed again" ... so allowing new LIR to migrate there PI into PA could be at least a way to reduce the income ;) Regards -- Jens Ott Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
On 20/06/2013 14:29, Opteamax GmbH wrote:
On 20.06.2013 13:28, Carsten Schiefner wrote:
Andrea, all -
full ACK to both:
* Allow status change from LIRs' PI assignments to PA allocations
and to Tore's point:
* Omission of the minimum allocation size constraint
Full +1 from my side.
from ripe perspective the only difference I can see is the fact that PI is charged seperately. I clearly remember the (funny mentioned) words at last GM: "we are already trying hard to make a deficit, but obviously we failed again" ... so allowing new LIR to migrate there PI into PA could be at least a way to reduce the income ;)
I'm glad someone was listening :-) FWIW, and wearing my own personal hat (the grey-green waterproof one that I had to buy in Amsterdam one year to stop from drowning in the rain), I think this is a good idea. We're going to discuss it at the board meeting next week. Nigel
Hi Nigel, On 20.06.2013 16:09, Nigel Titley wrote:
FWIW, and wearing my own personal hat (the grey-green waterproof one that I had to buy in Amsterdam one year to stop from drowning in the rain), I think this is a good idea. We're going to discuss it at the board meeting next week.
would you dare to shed some light on the potential outcome of your deliberations in this regard? Or is it yet to early and the board intends to wrap it as a christmas gift? ;-) All the best, -C.
On 12/07/2013 13:44, Carsten Schiefner wrote:
Hi Nigel,
On 20.06.2013 16:09, Nigel Titley wrote:
FWIW, and wearing my own personal hat (the grey-green waterproof one that I had to buy in Amsterdam one year to stop from drowning in the rain), I think this is a good idea. We're going to discuss it at the board meeting next week.
would you dare to shed some light on the potential outcome of your deliberations in this regard? Or is it yet to early and the board intends to wrap it as a christmas gift? ;-)
Well, I'm happy to hold off until Christmas if you really want, but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list). All the best Nigel
Hi Nigel, On 12.07.2013 18:52, Nigel Titley wrote:
Well, I'm happy to hold off until Christmas if you really want,
no need at all for such modesty. REALLY! ;-)
but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list).
As this might not just interest members (aka. LIRs), could the concerning part of the minutes be published here - or on the RIPE list - as well, please? Thanks and best, -C.
Hi Nigel, On 12.07.2013 18:52, Nigel Titley wrote:
but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list).
I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere? Thanks and best, -C.
On 16/07/2013 22:45, Carsten Schiefner wrote:
Hi Nigel,
On 12.07.2013 18:52, Nigel Titley wrote:
but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list).
I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere?
Thanks and best,
Hmm, yes the discussion we had didn't get formally minuted. Looking back on the correspondence on the board mailing list after the meeting, where this lack of minuting was brought up, it was decided that as the discussion was still taking place on the AP-WG list that we shouldn't bias the discussion by minuting the board discussion. Which I've managed to completely put my foot in... <sigh> The upshot was that the Board agreed in principle that they thought that a move from PI to PA under the defined circumstances was fine in principle, as far as they could see, but that the discussion should run to a close in the community before coming to a final conclusion. Nigel
I think we should consider to remove the distinction between PI and PA. As the free pool is depleted I do no loger see this need for registry purposes. -hph On Wednesday, July 17, 2013, Nigel Titley wrote:
On 16/07/2013 22:45, Carsten Schiefner wrote:
Hi Nigel,
On 12.07.2013 18:52, Nigel Titley wrote:
but the draft board minutes are currently scheduled to go out on Monday (with an announcement to the members list).
I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere?
Thanks and best,
Hmm, yes the discussion we had didn't get formally minuted. Looking back on the correspondence on the board mailing list after the meeting, where this lack of minuting was brought up, it was decided that as the discussion was still taking place on the AP-WG list that we shouldn't bias the discussion by minuting the board discussion. Which I've managed to completely put my foot in... <sigh>
The upshot was that the Board agreed in principle that they thought that a move from PI to PA under the defined circumstances was fine in principle, as far as they could see, but that the discussion should run to a close in the community before coming to a final conclusion.
Nigel
-- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net | http://hph.oslo.net
Hi Hans Petter, On 17.07.2013 12:34, Hans Petter Holen wrote:
I think we should consider to remove the distinction between PI and PA. As the free pool is depleted I do no loger see this need for registry purposes.
interesting view point. :-) Maybe you want to elaborate on this a bit more and/or send some text wrt. a policy CR? Thanks and best, -C.
All - On 17.07.2013 12:30, Nigel Titley wrote:
On 16/07/2013 22:45, Carsten Schiefner wrote:
I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere?
Hmm, yes the discussion we had didn't get formally minuted. Looking back on the correspondence on the board mailing list after the meeting, where this lack of minuting was brought up, it was decided that as the discussion was still taking place on the AP-WG list that we shouldn't bias the discussion by minuting the board discussion. Which I've managed to completely put my foot in... <sigh>
The upshot was that the Board agreed in principle that they thought that a move from PI to PA under the defined circumstances was fine in principle, as far as they could see, but that the discussion should run to a close in the community before coming to a final conclusion.
I feel that this got stalled a bit in the meantime: any feelings on where we are and what to do next? AFAIR most, if not all contributions were in favour of the idea. Filiz Yilmaz on Fri, 12 Jul 2013, at 15:48:19 +0200 pledged to have a slightly more careful discussion, maybe even a PDP, about it: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008005.h... And the somewhat connected idea to completely abandon PI vs. PA distinction was floated by Olaf Sonderegger and Hans Petter Holen: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007951.h... https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008019.h... I am still in favour of the original approach and would like to see it implemented and/or executed, respectively. All the best, -C.
Hi Carsten, I'm in favor of LIR's being able to change the PI status to PA for their own assigned PI space. (Infrastructure) I think that the whole PI and PA discussion itself will take some time to complete, but this particular change should be fairly easy to implement imho. Regards, Erik Bais -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Carsten Schiefner Sent: woensdag 31 juli 2013 11:08 To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space All - On 17.07.2013 12:30, Nigel Titley wrote:
On 16/07/2013 22:45, Carsten Schiefner wrote:
I can't find anything in the minutes concerning a status change of PI space. Or did I miss something somewhere?
Hmm, yes the discussion we had didn't get formally minuted. Looking back on the correspondence on the board mailing list after the meeting, where this lack of minuting was brought up, it was decided that as the discussion was still taking place on the AP-WG list that we shouldn't bias the discussion by minuting the board discussion. Which I've managed to completely put my foot in... <sigh>
The upshot was that the Board agreed in principle that they thought that a move from PI to PA under the defined circumstances was fine in principle, as far as they could see, but that the discussion should run to a close in the community before coming to a final conclusion.
I feel that this got stalled a bit in the meantime: any feelings on where we are and what to do next? AFAIR most, if not all contributions were in favour of the idea. Filiz Yilmaz on Fri, 12 Jul 2013, at 15:48:19 +0200 pledged to have a slightly more careful discussion, maybe even a PDP, about it: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008005.h... And the somewhat connected idea to completely abandon PI vs. PA distinction was floated by Olaf Sonderegger and Hans Petter Holen: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007951.h... https://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-July/008019.h... I am still in favour of the original approach and would like to see it implemented and/or executed, respectively. All the best, -C.
W dniu 2013-07-31 13:50, Erik Bais pisze:
Hi Carsten,
I'm in favor of LIR's being able to change the PI status to PA for their own assigned PI space. (Infrastructure)
I think that the whole PI and PA discussion itself will take some time to complete, but this particular change should be fairly easy to implement imho.
Regards, Erik Bais
I think that is very simple, requiring only a decision which no one yet wants to take. Do we have any new ideas on this subject? Personally, I think that: 1. If an organization wants to become LIR status and declares, that alerady has the PI resources equal or more than /22, it should no longer receive the "initial" allocation of the /22 from the lat /8, but should be able to convert all, what was received before becoming the LIR status. 2. Existing LIRs should be able to convert his PI resources to PA regardless of the block size. All the best Tomasz
On 20 June 2013 08:49, andrea <andrea@ripe.net> wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations
This
(if equal or larger than the minimum allocation size)
but this makes no sense, since the object already exists in the db (and routing table) why restrict it? J -- James Blessing 07989 039 476
Am 20.06.2013 11:10, schrieb James Blessing:
A. Allow LIRs to change the status of their PI assignments to PA allocations
This
+1 -- Fredy Künzler Init7 (Switzerland) AG AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @kuenzler / @init7 http://www.init7.net/
+1 -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Fredy Kuenzler Sent: 20 June 2013 10:53 To: Address Policy Working Group Subject: Re: [address-policy-wg] Guidance Requested: Changing the Status of PI Address Space Am 20.06.2013 11:10, schrieb James Blessing:
A. Allow LIRs to change the status of their PI assignments to PA allocations
This
+1 -- Fredy Künzler Init7 (Switzerland) AG AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @kuenzler / @init7 http://www.init7.net/
James Blessing wrote:
On 20 June 2013 08:49, andrea <andrea@ripe.net> wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations
This
(if equal or larger than the minimum allocation size)
but this makes no sense, since the object already exists in the db (and routing table) why restrict it?
I soemwhat lost track about the RIPE Region's Address Transfer Policy (proposal/s), so please bear with me. IMHO we SHOULD try to remove insconsistencies and special cases in the various policies and their interpretation. Thus: if there is (or will be) a (lower) limit in a/the Transfer Policy, then the same SHOULD apply in moving blocks from PI to PA. OTOH, if the community agrees and lifting size restrictions, then this should be done consistently across the board.
J --
James Blessing 07989 039 476
Wilfried.
* Allow status change from LIRs' PI assignments to PA allocations +1 * Omission of the minimum allocation size constraint +1 -- Dan Luedtke http://www.danrl.de
Hi, I also think this is a good idea. So, +1. But shouldn't this go through the regular PDP...? (i.e. who really needs this should write a new policy proposal...) Regards, Carlos On Mon, 24 Jun 2013, Dan Luedtke wrote:
* Allow status change from LIRs' PI assignments to PA allocations +1
* Omission of the minimum allocation size constraint +1
-- Dan Luedtke http://www.danrl.de
Hi Carlos, On Wed, Jun 26, 2013 at 08:42:50AM +0100, Carlos Friacas wrote:
But shouldn't this go through the regular PDP...? (i.e. who really needs this should write a new policy proposal...)
We're not actually changing policy - we have something here where the policy text isn't specifying anything, so if we can agree how we want the RIPE NCC to handle this, we can do this in a quicker and more light-weight way of "just asking the community for guidance". One of the important aspects here is that this will not change the way the RIPE NCC hands out resources. 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 (89) 32356-444 USt-IdNr.: DE813185279
Hello, On 26 Jun 2013, at 14:48, Gert Doering <gert@space.net> wrote:
Hi Carlos,
On Wed, Jun 26, 2013 at 08:42:50AM +0100, Carlos Friacas wrote:
But shouldn't this go through the regular PDP...? (i.e. who really needs this should write a new policy proposal...)
We're not actually changing policy - we have something here where the policy text isn't specifying anything, so if we can agree how we want the RIPE NCC to handle this, we can do this in a quicker and more light-weight way of "just asking the community for guidance".
One of the important aspects here is that this will not change the way the RIPE NCC hands out resources.
I mentioned my similar worry on this at the last RIPE meeting in Dublin, but there was not enough time at that session for a proper discussion. I will try here again: I have a sense this is further than just stamping a best practice for the RIPE NCC and giving them guidance on a corner case. First of all that we are already talking about transfer policies and practices here in this thread is a sign that this is not just a simple guidance issue. PI assignments were given for a specific reason at the time. The recipient is an LIR or not is irrelevant here. The purpose was specific at the time of the assignment and obviously different than what a PA allocation is or was at the time. PI assignments are assignments to start with, while allocations are blocks to keep assignments within. We may like it or not, but the policy text still has various mentions of this criteria issue: --- All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. End Users requesting PI space should be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are still met and is also subject to the policies described in the RIPE NCC document entitled ... --- Accordingly I do not think changing the status of an address block from PI Assignment to PA Allocation abides completely with the current RIPE Policy as it is written today. And I think the policy text should be changed first to allow the RIPE NCC properly to perform such a practice. This will be good for the RIPE NCC, as they are supposed to be following the policy text to the letter. This will also be good for the community, I think, for transparency reasons: A lot of people who are not following the current debate in the list may never have the chance to be aware of this "specific" practice to be adopted by the RIPE NCC, unless it is properly documented through a proposal and then in the policy document, which is the main purpose of the PDP in my opinion. Finally I want to note that I do agree with the argument that the important thing here is to get the registration in the database right. I am not disagreeing with this and in fact I do agree with this overall goal. But I also am an advocate of doing things the right way. The policy documents and the PDP are there for a reason. We should be careful in by-passing them by adopting a practice after just holding a thread in a mailing list without a proper final-documentation for everyone. Cheers Filiz Yilmaz
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 (89) 32356-444 USt-IdNr.: DE813185279
* Wilfried Woeber
I soemwhat lost track about the RIPE Region's Address Transfer Policy (proposal/s), so please bear with me.
IMHO we SHOULD try to remove insconsistencies and special cases in the various policies and their interpretation.
Thus: if there is (or will be) a (lower) limit in a/the Transfer Policy, then the same SHOULD apply in moving blocks from PI to PA.
OTOH, if the community agrees and lifting size restrictions, then this should be done consistently across the board.
The current PA-only transfer policy states: «The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation». In other words blocks smaller than /22 may not be transferred, regardless of PI or PA status. Since the policy is quite explicit on this point, changing it would require the community to adopt a policy proposal that explicitly made such a change. [BTW: The policy also states that the minimum allocation size is /21, but there have been a couple of /22 transfers already. I assume the NCC is considering the /21 statement as superseded by the last /8 policy and considers the minimum allocation size to be /22 instead.] Tore
Tore Anderson wrote:
* Wilfried Woeber
I soemwhat lost track about the RIPE Region's Address Transfer Policy (proposal/s), so please bear with me.
IMHO we SHOULD try to remove insconsistencies and special cases in the various policies and their interpretation.
Thus: if there is (or will be) a (lower) limit in a/the Transfer Policy, then the same SHOULD apply in moving blocks from PI to PA.
OTOH, if the community agrees and lifting size restrictions, then this should be done consistently across the board.
The current PA-only transfer policy states: «The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation».
In other words blocks smaller than /22 may not be transferred, regardless of PI or PA status. Since the policy is quite explicit on this point, changing it would require the community to adopt a policy proposal that explicitly made such a change.
[BTW: The policy also states that the minimum allocation size is /21, but there have been a couple of /22 transfers already. I assume the NCC is considering the /21 statement as superseded by the last /8 policy and considers the minimum allocation size to be /22 instead.]
OK, thanks Tore! So - question to the IPRAs: what sizes of PI blocks did you see when the PI->PA conversion requests were submitted? Wilfried.
Tore
Hi All, On 6/25/13 11:58 AM, Wilfried Woeber wrote:
Tore Anderson wrote:
* Wilfried Woeber
I soemwhat lost track about the RIPE Region's Address Transfer Policy (proposal/s), so please bear with me.
IMHO we SHOULD try to remove insconsistencies and special cases in the various policies and their interpretation.
Thus: if there is (or will be) a (lower) limit in a/the Transfer Policy, then the same SHOULD apply in moving blocks from PI to PA.
OTOH, if the community agrees and lifting size restrictions, then this should be done consistently across the board.
The current PA-only transfer policy states: «The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation».
In other words blocks smaller than /22 may not be transferred, regardless of PI or PA status. Since the policy is quite explicit on this point, changing it would require the community to adopt a policy proposal that explicitly made such a change.
[BTW: The policy also states that the minimum allocation size is /21, but there have been a couple of /22 transfers already. I assume the NCC is considering the /21 statement as superseded by the last /8 policy and considers the minimum allocation size to be /22 instead.]
This statement is correct: we consider the /21 statement as superseded by the last /8 policy, according to which the minimum allocation size is /22.
OK, thanks Tore!
So - question to the IPRAs: what sizes of PI blocks did you see when the PI->PA conversion requests were submitted?
Most of the requests for conversion from assigned PI to allocated PA have been for IP blocks larger than the minimum allocation size (mainly /20 and /19 blocks). Just in very few cases the IP blocks were smaller than the minimum allocation size (/23 and /24 blocks). Best regards, Andrea Cima RIPE NCC
Wilfried.
Tore
On Thu, Jun 20, 2013 at 9:49 AM, andrea <andrea@ripe.net> wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
This solution is acceptable without the parenthetical limitation. If the limitation is removed, I support solution A. Solution B is not worth considering, IMHO. -- Jan
On Thu, Jun 20, 2013 at 09:49:43AM +0200, andrea wrote:
At RIPE 66, the RIPE NCC suggested the following potential solutions:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
Support, without the size limitation. rgds, Sascha Luck
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
+1, and prefer not to include the bit in parentheses. D. -- Donal Cunningham | DC323-RIPE Peering Coordinator, AirSpeed Telecom http://as29644.peeringdb.com/ Airspeed Telecom
* andrea <andrea@ripe.net> [2013-06-20 09:51]:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
I support this without the allocation size limit. There are a lot PI assignments smaller than the minimum allocation size. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) I support this without the allocation size limit. // Andreas Med vänlig hälsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-06-24 16:14 skrev Sebastian Wiesinger <ripe.address-policy-wg@ml.karotte.org>:
* andrea <andrea@ripe.net> [2013-06-20 09:51]:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
I support this without the allocation size limit. There are a lot PI assignments smaller than the minimum allocation size.
Regards
Sebastian
-- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Hi, sorry for my late contribution (and my poor english) On 20/06/2013 09:49, andrea wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
I do not support this since blindly allowing LIRs to change PI to PA would lead to very permissive reuse of space that was assigned in an exception mode to the aggregation principle for very specific reasons. So I consider if the purpose of this assignment is no valid anymore then it should be returned to free pool in the general case, not reused for whatever else. This is enforced by the ability for LIRs to transfer (I mean, to sell) PA space. Obviously converting PI to PA and sell it would be the right choice for anybody having unused PI subnets today. I know convervation looks like an old fashioned and void policy for many LIRs today, however free IPv4 still is a rare public ressource needed by many to survive. So available IPs should be returned to RIR. Best regards, Sylvain fr.opdop
Hi Sylvain, If the goal is to resell space, it will happen anyway. There are companies that start with PI space and become an LIR later. The policy for PI space stated that if you could justify 1 IP address, you would get a single /24. Anyone can justify a single IP address for their infrastructure. This change will allow PI space holders that are a LIR themselves to use the remaining space that might not be allowed under the PI assignment policy ( like sub-assignment to third-parties / customers ) Voting against this will not make these policy voilations go away ... And PI space will not go back to the free pool... Conservation is not a goal anymore by itself, as our RIR has depleted its free pool. Fair distribution isn't a task anymore, the primairy task keeping the registry correct. Will people sell space ( even if the policy won't allow it ?) YES !! I have seen incidents of people buying PI space and not changing the holder, side letters in place etc. If we have clear policies and procedures that would allow these situations to at least reflect in the registry, the registry will have a much better change of being accurate. This proposed change will remove limitations that were valid in a pre-depletion era .. However, times have changed. Regards, Erik Bais Verstuurd vanaf mijn iPad Op 11 aug. 2013 om 12:03 heeft Sylvain Vallerot <sylvain.vallerot@opdop.net> het volgende geschreven:
Hi, sorry for my late contribution (and my poor english)
On 20/06/2013 09:49, andrea wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
I do not support this since blindly allowing LIRs to change PI to PA would lead to very permissive reuse of space that was assigned in an exception mode to the aggregation principle for very specific reasons.
So I consider if the purpose of this assignment is no valid anymore then it should be returned to free pool in the general case, not reused for whatever else.
This is enforced by the ability for LIRs to transfer (I mean, to sell) PA space. Obviously converting PI to PA and sell it would be the right choice for anybody having unused PI subnets today.
I know convervation looks like an old fashioned and void policy for many LIRs today, however free IPv4 still is a rare public ressource needed by many to survive. So available IPs should be returned to RIR.
Best regards, Sylvain fr.opdop
On 11/08/2013 14:18, Erik Bais wrote:
Conservation is not a goal anymore by itself, as our RIR has depleted its free pool.
Except you're wrong, conservation is still a goal, and depletion is not done (otherwise I think we would have CEO suicide records a bit everywhere). According to the "math" I read in another list, with the current policies last /8 full depletion could take more than 10 years. It won't, for sure, but this and survival of the weakest will depend on the way we change these policies today and for the time dual stack will still be necessary.
Fair distribution isn't a task anymore, the primairy task keeping the registry correct.
Sorry, I can't continue discussing with this. Regards, Sylvain
Hi Sylvain, Maybe the definition must be taken a little different: conversion for own use. The reason is that some PI-Owner became LIR, e.g. because the size of their business grew, that it became reasonable. Earlier it didn't make sense for me to become LIR as two /24 were sufficient. With an eye on the "Last /8 Policy", your proposal would mean, these LIRs would have to return their space without having a chance to get new pa to satisfy their current need. Anyway, even if I'd return a /22 and receive another PA (my "last /22") this wouldn't give more aggregation. The only thing that changes, would be a huge amount of work for me... or (if not converting my PI to PA I have to pay 50 EUR more than e.g. Deutsche Telekom which holds many many more IPv4 than me, only that because my initial assignment has the label PI... BR Jens Sylvain Vallerot <sylvain.vallerot@opdop.net> schrieb:
Hi, sorry for my late contribution (and my poor english)
On 20/06/2013 09:49, andrea wrote:
A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size)
I do not support this since blindly allowing LIRs to change PI to PA would lead to very permissive reuse of space that was assigned in an exception mode to the aggregation principle for very specific reasons.
So I consider if the purpose of this assignment is no valid anymore then it should be returned to free pool in the general case, not reused for whatever else.
This is enforced by the ability for LIRs to transfer (I mean, to sell) PA space. Obviously converting PI to PA and sell it would be the right choice for anybody having unused PI subnets today.
I know convervation looks like an old fashioned and void policy for many LIRs today, however free IPv4 still is a rare public ressource needed by many to survive. So available IPs should be returned to RIR.
Best regards, Sylvain fr.opdop
!DSPAM:637,520763c7296831255961281!
participants (28)
-
andrea
-
Andrea Cima
-
Andreas Larsen
-
Andrzej Dopierała
-
Carlos Friacas
-
Carsten Schiefner
-
Christoph Neukirch
-
Dan Luedtke
-
Daniel Stolpe
-
Donal Cunningham
-
Erik Bais
-
Filiz Yilmaz
-
Fredy Kuenzler
-
Gert Doering
-
Hans Petter Holen
-
James Blessing
-
Jan Ingvoldstad
-
Nigel Titley
-
Nolan, Keith
-
Opteamax GmbH
-
Opteamax GmbH - RIPE-Team
-
Richard Hartmann
-
Sascha Luck
-
Sebastian Wiesinger
-
Sylvain Vallerot
-
Tomasz Śląski GMAIL
-
Tore Anderson
-
Wilfried Woeber