-----Original Message----- From: "Ehsan Behbahani" <behbahani@soshiant.net> To: apwg@ripe.net Date: Sun, 08 May 2016 17:39:44 +0430 Subject: agreement Hi we are agree about theLast /8 Allocation Criteria Revision proposal . https://www.ripe.net/participate/policies/proposals/2015-05 [https://www.ripe.net/participate/policies/proposals/2015-05] RegID: ir.shnt best regards. Ehsan behbahani
Hello Ehsan,
we are agree about the Last /8 Allocation Criteria Revision proposal . https://www.ripe.net/participate/policies/proposals/2015-05
thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck.
RegID: ir.shnt
You don't need to state your RegID in this working group. This working group is open to all interested parties, not just RIPE LIRs. Discussions are always between people, not organisations. Cheers, Sander
Hello Ehsan,
we are agree about the Last /8 Allocation Criteria Revision proposal . https://www.ripe.net/participate/policies/proposals/2015-05 thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck. Can you please summarize us the main objections about this 2015-05
Hi Sander, Il 09/05/2016 10:42, Sander Steffann ha scritto: policy so that people can try to address a solution to those?
RegID: ir.shnt You don't need to state your RegID in this working group. This working group is open to all interested parties, not just RIPE LIRs. Discussions are always between people, not organisations.
Cheers, Sander
kind regards Riccardo -- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote: :Hi Sander, : :Il 09/05/2016 10:42, Sander Steffann ha scritto: :>Hello Ehsan, :> :>>we are agree about the Last /8 Allocation Criteria Revision proposal . :>>https://www.ripe.net/participate/policies/proposals/2015-05 :>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck. :Can you please summarize us the main objections about this 2015-05 policy so :that people can try to address a solution to those? My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market. Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side. I appreciate the effort put into this proposal, but I do not think any solution can be proposed. (note: my stance is based on forming a LIR simply to get any amount of announcable addresses.) -- Quick!! Act as if nothing has happened!
Hi Peter,
My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market.
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side.
Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem. I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC’s IPv4 pool was expected to last for around five years.".
I appreciate the effort put into this proposal, but I do not think any solution can be proposed.
The stated expected timescale already seems to be around the bare minimum lifetime that is accepted, and much less than what many people would like. I therefore have to agree that any proposal that shortens that lifetime even further will very probably not get consensus. Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this discussion to read the mailing list archives so they can get the full current picture before they propose a solution. Cheers, Sander
On Mon, 9 May 2016, Sander Steffann wrote:
Hi Peter,
My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market.
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side.
Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem.
I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC?s IPv4 pool was expected to last for around five years.".
I appreciate the effort put into this proposal, but I do not think any solution can be proposed.
The stated expected timescale already seems to be around the bare minimum lifetime that is accepted, and much less than what many people would like. I therefore have to agree that any proposal that shortens that lifetime even further will very probably not get consensus.
Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this discussion to read the mailing list archives so they can get the full current picture before they propose a solution.
Cheers, Sander
Very well written Sander. I Completely agree with you. 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 Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
I find the situation a little more complex than that: - First, the "in a few years with no IPv4" is not so far away. Even with current policy, it is for 2020, with a lot of chance 2021. With the proposal, worst case scenario is that we MAY loose up to 18 months (more likely something in the 6-12 months range ). Which is not completely sure (as Martin Huněk noted a few messages ago). - Second, right now the NCC is just handing out /22 to whoever can pay for them (with only a small extra administrative restriction during the last 6 months). For me this is plain "selling IP addresses" (concept that the NCC avoided like hell int the past), and it is also defeating the "keep space for later entrants" purpose. No need check (as in "do you really need that space" *), no requirement to deploy IPv6 of any kind, just a simple "pay to have it".
Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem.
Given the time we have left (very unlikely to have 60 moths left) anything starts being problematic.
I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC’s IPv4 pool was expected to last for around five years.".
It all depends on when we start counting. If we start counting from 09/2012, we will meet the 5 years lifetime even with the current proposal. If we start now (10/05/2016), we will most probably NOT reach 5 years. We will NOT get 10 years of "last /8". And we should probably stop thinking "X years starting from now on". Time passes. In the meantime, people do "whatever seems appropriate" to get more v4 space. And unfortunately more and more people find there is no other solution than cheating in some way or another. The policy was supposed to calm down this.
Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this
Does anybody feel that a more complex policy is acceptable ? Does making the policy more complex in order to get longer timespan for the free pool (which does not exclude extra allocations if conditions are met) is somthing that may get consensus ? (*) Some time ago, a lot of "new players" would have started by being single-homed and having one (or more) "ASSIGNED PA" block(s) from their upstream. Then they were taking an ASN, and then became LIRs. Those going LIR from day one were not exactly commonplace. Today, even for those that are ok with being single-homed with an "ASSIGNED PA" from their upstream, if the size of the requested block goes beyond a certain size (commonly /24, occasionally down to /26), they are recommended (or even pushed) to become a LIR and get their /22. There are others that just "can afford" to spend some money to become LIR and get some space, even if it's not really used, just in case things go wrong in the future. -- Radu-Adrian FEURDEAN fr.ccs
On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
Hi,
On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
I find the situation a little more complex than that: - First, the "in a few years with no IPv4" is not so far away. Even with current policy, it is for 2020, with a lot of chance 2021. With the proposal, worst case scenario is that we MAY loose up to 18 months (more likely something in the 6-12 months range ). Which is not completely sure (as Martin Huněk noted a few messages ago). - Second, right now the NCC is just handing out /22 to whoever can pay for them (with only a small extra administrative restriction during the last 6 months). For me this is plain "selling IP addresses" (concept that the NCC avoided like hell int the past), and it is also defeating the "keep space for later entrants" purpose. No need check (as in "do you really need that space" *), no requirement to deploy IPv6 of any kind, just a simple "pay to have it".
This could be solved without introducing yet another way to deplete the remaining pool. The problem with 2015-05, is its similarity to how certain acts of Congress in the US come to pass: You bundle what you want with something else, to sweeten the deal. So here is how you can fix the deadlock: Unbundle. Split the proposal in two parts. Part A: Additional requirements for IPv4 allocations Part B: Additional periodical IPv4 allocations for existing LIRs This would, for instance, make it easy for me to say "yes" to part A, and "no" to part B, instead of "no" to the entire package. -- Jan
Hi all, I have been following the discussion and I strongly support Jan's suggestion, especially since the bulk of the contention seems to be with what Jan describes as Part B. Does anyone know if it is possible to split the proposal into two parts? Best, -Michael __________________ Michael J. Oghia Istanbul, Turkey Journalist & editor 2015 ISOC IGF Ambassador Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia> On Tue, May 10, 2016 at 3:53 PM, Jan Ingvoldstad <frettled@gmail.com> wrote:
On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
Hi,
On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22".
I find the situation a little more complex than that: - First, the "in a few years with no IPv4" is not so far away. Even with current policy, it is for 2020, with a lot of chance 2021. With the proposal, worst case scenario is that we MAY loose up to 18 months (more likely something in the 6-12 months range ). Which is not completely sure (as Martin Huněk noted a few messages ago). - Second, right now the NCC is just handing out /22 to whoever can pay for them (with only a small extra administrative restriction during the last 6 months). For me this is plain "selling IP addresses" (concept that the NCC avoided like hell int the past), and it is also defeating the "keep space for later entrants" purpose. No need check (as in "do you really need that space" *), no requirement to deploy IPv6 of any kind, just a simple "pay to have it".
This could be solved without introducing yet another way to deplete the remaining pool.
The problem with 2015-05, is its similarity to how certain acts of Congress in the US come to pass:
You bundle what you want with something else, to sweeten the deal.
So here is how you can fix the deadlock:
Unbundle. Split the proposal in two parts.
Part A: Additional requirements for IPv4 allocations
Part B: Additional periodical IPv4 allocations for existing LIRs
This would, for instance, make it easy for me to say "yes" to part A, and "no" to part B, instead of "no" to the entire package. -- Jan
On 10 May 2016, at 14:27, Michael Oghia wrote:
Hi all,
I have been following the discussion and I strongly support Jan's suggestion, especially since the bulk of the contention seems to be with what Jan describes as Part B. Does anyone know if it is possible to split the proposal into two parts?
Yes. If it were my proposal, here's how I would go about it. Withdraw the current proposal. The proposer can always do this during the process. Introduce two new proposals (2016-somenumber and 2016-someothernumber) respectively containing the "Part A" and "Part B" material from the current proposal. There may be other ways of doing it, but this seems simple and effective. Best regards, Niall O'Reilly
Hi all, Thank you for clarifying Niall. I suggest then that the original proposer weigh into this process with his/her suggestions on going forward and potentially incorporating this recommendation to split the proposal into two parts. Best, -Michael __________________ Michael J. Oghia Istanbul, Turkey Journalist & editor 2015 ISOC IGF Ambassador Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia> On Tue, May 10, 2016 at 5:39 PM, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
On 10 May 2016, at 14:27, Michael Oghia wrote:
Hi all,
I have been following the discussion and I strongly support Jan's suggestion, especially since the bulk of the contention seems to be with what Jan describes as Part B. Does anyone know if it is possible to split the proposal into two parts?
Yes.
If it were my proposal, here's how I would go about it.
Withdraw the current proposal. The proposer can always do this during the process.
Introduce two new proposals (2016-somenumber and 2016-someothernumber) respectively containing the "Part A" and "Part B" material from the current proposal.
There may be other ways of doing it, but this seems simple and effective.
Best regards,
Niall O'Reilly
On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
If it were my proposal, here's how I would go about it.
Withdraw the current proposal. The proposer can always do this during the process.
Introduce two new proposals (2016-somenumber and 2016-someothernumber) respectively containing the "Part A" and "Part B" material from the current proposal.
Hello, As the proposal was written, the "part B" (allocation condition including v6 deployment) would have no sense on its own, since it only applies to the results of "part A" (further allocations). In order to have a "part B" that makes any sens, it would mean that current rules for allocation of the "first /22 from last /8" would have to change: - for a "real" first allocation (LIR that never received a v4 allocation before) either conditions would not apply, or a new system would have to be created where the allocation is time-limited, and at the end of time limit the allocated block is either returned (condition not met) or made "regular allocation" (condition met). - for LIRs that had previously allocated IPv4 space, condition applied directly.
On Sat, May 14, 2016 at 9:35 AM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
If it were my proposal, here's how I would go about it.
Withdraw the current proposal. The proposer can always do this during the process.
Introduce two new proposals (2016-somenumber and 2016-someothernumber) respectively containing the "Part A" and "Part B" material from the current proposal.
Hello,
As the proposal was written,
Yep, and this is why the suggestion starts with "withdraw the current proposal", also because that will make it easier to proceed.
the "part B" (allocation condition including v6 deployment) would have no sense on its own, since it only applies to the results of "part A" (further allocations).
This is indeed a weakness of the current proposal.
In order to have a "part B" that makes any sens, it would mean that current rules for allocation of the "first /22 from last /8" would have to change: - for a "real" first allocation (LIR that never received a v4 allocation before) either conditions would not apply, or a new system would have to be created where the allocation is time-limited, and at the end of time limit the allocated block is either returned (condition not met) or made "regular allocation" (condition met). - for LIRs that had previously allocated IPv4 space, condition applied directly.
This seems like putting the cart before the horse. Allocation conditions should be introduced _first_, as a "part A". Then a separate proposal for additional allocations should be introduced _second_, as a "part B". This corresponds well to your own claim that your proposal intends to preserve the pool, and should not deplete it rapidly, and will perhaps even make it possible to proceed. To me, this is the test of whether you actually stand by that claim. -- Jan
On Sat, May 14, 2016, at 10:16, Jan Ingvoldstad wrote:
This seems like putting the cart before the horse.
Allocation conditions should be introduced _first_, as a "part A".
Ok, got it, I messed the order. Sill, the question remains on what is the scope of "Part A" (condition for allocation) ? For old LIRs (that got an allocation before 14/09/2012), that shouldn't be a problem unless community decides otherwise The question is for new LIRs : how can you ask them to fulfill the conditions when they never had anything (nada, zero, LIR just opened) in the first place ? - ask them to start deployment using somebody else's space (ASSIGNED PA from transit, leased space) ? - lease them the block for X months/years (trial period) than take it back if at the end of trial period the condition is not met ? - keep the current status for them, which pretty much voids the purpose of the condition ? -- Radu-Adrian FEURDEAN fr.ccs
* Radu-Adrian FEURDEAN
- Second, right now the NCC is just handing out /22 to whoever can pay for them (with only a small extra administrative restriction during the last 6 months). For me this is plain "selling IP addresses" (concept that the NCC avoided like hell int the past), and it is also defeating the "keep space for later entrants" purpose. No need check (as in "do you really need that space" *), no requirement to deploy IPv6 of any kind, just a simple "pay to have it".
Time for a history lesson... It has been true for a very long time, certainly for much longer than the last /8 policy has been around, that new members (LIRs) have been pretty much guaranteed to receive an minimum-sized IPv4 allocation. The requester needed to be a member with assignments to make. That's pretty much all there was to it. The logic: If a new LIR is about to make >0 IPv4 assigments (sized >0 in total), then that LIR obviously is in need of an IPv4 allocation sized >0, thus automatically qualifying for a /n. (/n is the minimum allocation size at the time of the request. Prior to the activation of the «last /8» policy it was a /21, while today it is a /22.) If you read ripe-649 closely you'll see that the above holds true today: New LIRs with assignments to make get a minimum-sized IPv4 allocation. So this part of the policy hasn't really changed. It might seem like it, but in reality it is because two avenues that previously allowed end users to obtain IPv4 space in a far easier way than "become an LIR" is or ever was have been closed - thus making the "become an LIR" avenue increase in popularity: 1) Receiving PA assignments from an LIR/ISP. Before IPv4 was running out, there was no incentive for an LIR/ISP to not give an end user all the space he needed; the LIR/ISP could easily cover such "loss" with additional allocations from the NCC. That's no longer the case, so LIR/ISPs that aren't completely out of free IPv4 space have every reason to be very conservative about making PA assigments, e.g., by reserving them for the highest-value customers. 2) Receiving PI assignments via a sponsoring LIR/ISP or directly from the NCC. The «last /8» policy killed off IPv4 PI, except for IXP and temporary use. In summary: if one starts out by equating "accepting new paying members" with "selling IP addresses", then the RIPE NCC has been seeling IP addresses since its inception. It's not a new thing at all. (It's not limited to IPv4 either, by the way: Any new member joining today gets to pick up a "complimentary" IPv6 /29 welcome gift.) What is new, though, is that we're essentially out of IPv4. This has caused the community to sacrifice the previous convenient and cheap avenues of obtaining voluminous IPv4 delegations for the sake of conservation. Even though this obviously cannot stave off full and utter depletion indefinitely, I believe it is the right thing to do for the sake of new entrants joining the community in the years to come. I do not support 2015-05 because to me it represents a reversal of this course. Tore
Hi Peter,
My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market. Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22". What about those holding large space and changed the policy to be
Hi Sander, Hi Peter, Il 09/05/2016 14:50, Sander Steffann ha scritto: triggered when reaced a last /8 and not before? Looks like eating the chocolate top cover of the cake and leave the dry part to the others. Here's your crumbs we are very respective.
Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side. Well, to make a useful discussion possible I think it's important to look at the timescales. A policy that changes expected depletion from e.g. 100 years to 90 years might not be a problem, but other timescales will definitely be a problem.
I think the timescale I have heard that people would find acceptable is *at least* 5 to 10 years. If you look at the minutes of RIPE 70 (https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70) you'll see a statement from RIPE NCC when discussing this policy proposal that "the RIPE NCC’s IPv4 pool was expected to last for around five years.".
I appreciate the effort put into this proposal, but I do not think any solution can be proposed. The stated expected timescale already seems to be around the bare minimum lifetime that is accepted, and much less than what many people would like. I therefore have to agree that any proposal that shortens that lifetime even further will very probably not get consensus.
Someone would need to come up with a radical new idea to get out of the current deadlock. Which is why I urge all new participants in this discussion to read the mailing list archives so they can get the full current picture before they propose a solution.
Cheers, Sander
This policy is a real way to slow down a little bit the allocation rate for the reasons above stated. In total there are about 13700 LIRs about 9.05 millions addresses of 185/8 have been allocated since 2012 Otherwise is possible to change completly the way the unused space is handled. Why don't place a pay per use? I think we would see a lot of transfert take place and allocation rate will magically slow down regards Riccardo -- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
Hi, On Wed, May 11, 2016 at 07:51:21AM +0200, Riccardo Gori wrote:
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22". What about those holding large space and changed the policy to be triggered when reaced a last /8 and not before? Looks like eating the chocolate top cover of the cake and leave the dry part to the others. Here's your crumbs we are very respective.
Would you have preferred the ARIN way? "Oops, we have reached exhaustion, nothing left, good buy to new entrants"? 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
Hi Gert, Il 11/05/2016 08:53, Gert Doering ha scritto:
Hi,
On Wed, May 11, 2016 at 07:51:21AM +0200, Riccardo Gori wrote:
Indeed. It all comes down to "the needs of those in the next few years with no IPv4 addresses" vs "those today who have only one /22". What about those holding large space and changed the policy to be triggered when reaced a last /8 and not before? Looks like eating the chocolate top cover of the cake and leave the dry part to the others. Here's your crumbs we are very respective. Would you have preferred the ARIN way? "Oops, we have reached exhaustion, nothing left, good buy to new entrants"? We can't say ARIN was wrong because actually did a better job in IPv6 growth. I am not saying there's the best way. Ways are thousand and 2015-05 doesn't pretend to be the best policy ever. Current allocation criteria obviously created discontent and was even abused generating quick selling of 185/8 just for profit. Sander noticed there are people here that are confirming that a change is accepted and someone else noticed that 2015-05 can be re-written or re-invented to meet better the tasks You as a chair should accept this and should help the community to understand how to follow up with a reasonable solution
Gert Doering -- NetMaster
regards Riccardo -- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
On 11 May 2016, at 08:53, Riccardo Gori <rgori@wirem.net> wrote:
Sander noticed there are people here that are confirming that a change is accepted and someone else noticed that 2015-05 can be re-written or re-invented to meet better the tasks You as a chair should accept this and should help the community to understand how to follow up with a reasonable solution
The WG’s co-chairs have not expressed an opinion on this proposal. This is to be expected since they have to make the consensus determination if 2015-05 reaches that point. Others have pointed out flaws and raised substantial objections. These issues have not been answered, let alone resolved. Supporters of 2015-05 should accept this and should help the community to understand how to follow up with a reasonable solution. We’re waiting. PS: Apologies for a relevant and meaningful Subject: header.
I try to go beyond the 2015-05: When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6 may require an additional /22 (if you do not already have space equivalent to a /20) stating its reasons for the new allocation with a project and proving to have it completed within one year. This new /22 will in no way be transferred before 3-5 years. I tried to remove the term of 18 months: what do you think about? Regards, Enrico Diacci. it.tsnet -----Messaggio originale----- Da: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Per conto di Jim Reid Inviato: mercoledì 11 maggio 2016 10:05 A: Riccardo Gori Cc: RIPE Address Policy WG Oggetto: [address-policy-wg] making progress with 2015-05
On 11 May 2016, at 08:53, Riccardo Gori <rgori@wirem.net> wrote:
Sander noticed there are people here that are confirming that a change is accepted and someone else noticed that 2015-05 can be re-written or re-invented to meet better the tasks You as a chair should accept this and should help the community to understand how to follow up with a reasonable solution
The WGs co-chairs have not expressed an opinion on this proposal. This is to be expected since they have to make the consensus determination if 2015-05 reaches that point. Others have pointed out flaws and raised substantial objections. These issues have not been answered, let alone resolved. Supporters of 2015-05 should accept this and should help the community to understand how to follow up with a reasonable solution. Were waiting. PS: Apologies for a relevant and meaningful Subject: header.
On 11 May 2016, at 09:29, Enrico Diacci <ed@tsnet.it> wrote:
When an LIR can claim to have reached 4 (or 5) stars of RIPEness for IPv6 may require an additional /22 (if you do not already have space equivalent to a /20) stating its reasons for the new allocation with a project and proving to have it completed within one year.
This new /22 will in no way be transferred before 3-5 years.
I tried to remove the term of 18 months: what do you think about?
Not a lot. But thanks for the suggestions and for trying to move things forward. First off, I am adamantly opposed to any policy proposal which will speed up depletion of the NCC’s IPv4 pool. Though if someone can come up with a convincing case for wiping it out, I would reconsider. Until then, the current policy is the least worst option IMO and we should keep it. Second, coupling any policy to RIPEness metrics is a very bad idea. Those metrics may change or even go away. [Who decides about that BTW.] They can be easily gamed too. Just do whatever needs to be done with IPv6 to get the extra IPv4 space and then take it down. Repeat. Third, I think it’s unwise to have a firm rule on transfers. Though I understand why you’ve suggested this: it’s meant to stop LIRs selling off these extra addresses. For one thing, there can be valid reasons for transferring space that don’t involve selling IPv4 addresses - a business reorganisation for instance. Next, if an LIR wants extra /22s in order to sell the addresses, they’d still do that irrespective of what the transfer restrictions were in place.
Jim Reid wrote:
Third, I think it’s unwise to have a firm rule on transfers. Though I understand why you’ve suggested this: it’s meant to stop LIRs selling off these extra addresses. For one thing, there can be valid reasons for transferring space that don’t involve selling IPv4 addresses - a business reorganisation for instance. Next, if an LIR wants extra /22s in order to sell the addresses, they’d still do that irrespective of what the transfer restrictions were in place.
fourth: this suggestion proposes to revert to a "needs" based allocation policy. This policy was removed a couple of years ago for good reasons which are still valid now and it is not realistic to expect that the clock is going to be turned back on this. Nick
What about those holding large space and changed the policy to be triggered when reaced a last /8 and not before? Looks like eating the chocolate top cover of the cake and leave the dry part to the others. Here's your crumbs we are very respective. Would you have preferred the ARIN way? "Oops, we have reached exhaustion, nothing left, good buy to new entrants"? We can't say ARIN was wrong because actually did a better job in IPv6 growth. Not sure if ARIN and it's (IMHO) failed IPv4 policy was the reason for
Hi, the better IPv6 growth, but any new entrant to the ISP market is paying a hefty fee for it ... because even though the ARIN region may have a higher IPv6 deployment, running and IPv6-only ISP business is out of the question ... so companies have to go out and pay for an IPv4 block in order to be able to do ANY business ... does that seem fair? I reckon the only way to actually create a fair market would be to either take away a percentage of assigned v4 addresses from ALL current owners to redistribute to new entries to the market, or set a date for disabling public v4 routing ... or maybe a third solution: Let all RIRs take on the ARIN policy, do away with all remaining v4 addresses within a couple days due to the incoming flood of requests, that way the price for v4 transfers will skyrocket, making it necessary for existing v4 holders to finally implement v6, hopefully causing the v6 availability to reach a tipping point quickly ... I guess you will agree that neither of those solutions will be implemented in the foreseeable future ... therefore, I agree with sticking to the current v4 policies in an attempt to keep at least a basic set of addresses available for new companies until the time that public v4 has been deemed more or less irrelevant ... (hopefully, I'll live to see the day ...) -garry
On Wed, May 11, 2016, at 08:53, Gert Doering wrote:
Would you have preferred the ARIN way? "Oops, we have reached exhaustion, nothing left, good buy to new entrants"?
My understanding is that ARIN is not yet "dry". There still is some space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed to be pretty restrictive, but I saw networks that prove me otherwise). And they still allow "further allocations" from that block (provided the "restrictive" conditions are met for all blocks). And it's evey 6 months not every 18 months. So it seems that issuing IPv4 space is still possible even after you cry out loud everywhere that you have none left. Don't tell me we (small LIRs) have to do the same with only a /22 in stock :) -- Radu-Adrian FEURDEAN fr.ccs
On 2016 May 11 (Wed) at 14:42:02 +0200 (+0200), Radu-Adrian FEURDEAN wrote: :On Wed, May 11, 2016, at 08:53, Gert Doering wrote: : :> Would you have preferred the ARIN way? "Oops, we have reached :> exhaustion, nothing left, good buy to new entrants"? : :My understanding is that ARIN is not yet "dry". There still is some :space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed :to be pretty restrictive, but I saw networks that prove me otherwise). :And they still allow "further allocations" from that block (provided the :"restrictive" conditions are met for all blocks). And it's evey 6 months :not every 18 months. : :So it seems that issuing IPv4 space is still possible even after you cry :out loud everywhere that you have none left. Don't tell me we (small :LIRs) have to do the same with only a /22 in stock :) : :-- :Radu-Adrian FEURDEAN :fr.ccs : The 23.128/10 block is ONLY for /24-/28 allocations. These are not intended as general purpose IP blocks, and are ONLY allowed to be used for the IPv6 trasition (DNS servers, NAT64 gateways, etc). People violating the ARIN rules shouldn't be used as an excuse for us to change the rules in RIPE. https://www.arin.net/announcements/2014/20140130.html ARIN does not count them as part of the available ranges for allocation, so we should not assume they are part of the normal pool. -- If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late. -- Henny Youngman
On Wed, May 11, 2016, at 14:52, Peter Hessler wrote:
The 23.128/10 block is ONLY for /24-/28 allocations. These are not
A /24 every 6 months (provided that conditions keep being fulfilled). Because less than /24 is pretty much useless.
intended as general purpose IP blocks, and are ONLY allowed to be used for the IPv6 trasition (DNS servers, NAT64 gateways, etc).
Some people tell me that "last /8" in RIPE-land is supposed to serve the same purpose, even if it's not written. Plus, you *CAN* get more than 4 x /24 in ARIN-land (to date 2 x /24, but the allocation rate is really low).
People violating the ARIN rules shouldn't be used as an excuse for us to change the rules in RIPE.
https://www.arin.net/announcements/2014/20140130.html
ARIN does not count them as part of the available ranges for allocation, so we should not assume they are part of the normal pool.
It's not the violation of ARIN rules, it's the fact that ARIN is *NOT* v4-exhausted. They still have available space, even if they call it otherwise. And it's used (or at least supposed) to reward people with real IPv6 deployment.
Hi, This policy may actually reduce the depletion rate for last /8, but without it the last /8 can be used more day by day. In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection? This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions, so no change in depletion rate from my point of view. Regards, Arash Naderpour On Mon, May 9, 2016 at 10:29 PM, Peter Hessler <phessler@theapt.org> wrote:
On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote: :Hi Sander, : :Il 09/05/2016 10:42, Sander Steffann ha scritto: :>Hello Ehsan, :> :>>we are agree about the Last /8 Allocation Criteria Revision proposal . :>>https://www.ripe.net/participate/policies/proposals/2015-05 :>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck. :Can you please summarize us the main objections about this 2015-05 policy so :that people can try to address a solution to those?
My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market.
Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side.
I appreciate the effort put into this proposal, but I do not think any solution can be proposed.
(note: my stance is based on forming a LIR simply to get any amount of announcable addresses.)
-- Quick!! Act as if nothing has happened!
In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?
They can also make their LIR job and make the unused space available to others :)
-allocations of a /22 every 18 months only from IPv4 Addresses Available Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)
I would consider unfair that I could not get more than /20 when some players have /19 or more. Denis
In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?
They can also make their LIR job and make the unused space available to others :)
Yes they can, but if they are really interested to make their LIR job. If the only motivation of new-comers is to get some IPv4 as their internet service provider is not able to provide them with any, there would no do LIR job. (new RIPE NCC members are not necessarily from IT industry and are forced to become LIR)
-allocations of a /22 every 18 months only from IPv4 Addresses Available Outside 185/8 to small LIRs (if LIR own < /20 of total allocations)
I would consider unfair that I could not get more than /20 when some players have /19 or more.
And you consider it fair when you cannot get more than /22 when some players have /19 or more? It may not be fair to everyone, but I cannot imagine a policy that can be totally fair to all of us in the real world, we can put "unfair" label to any policy proposal. Arash Naderpour
On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc@parsun.com> wrote:
In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?
Well I know I did. Setting up an LIR just to get a /22 is a possibility. The NCC’s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies. While it’s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That’s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don’t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive. If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool?
This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions,
While I oppose 2015-5 in principle, I’m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there’s no IPv4 left at the NCC. That doesn’t seem fair. Unless "something which benefits me and/or my customers at someone else’s expense” is the definition of fair. BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It’s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC’s allocations out of that last /8.
so no change in depletion rate from my point of view.
You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit: b. Arguments opposing the proposal Further allocations will speed up the depletion of the free pool.
While it’s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some >overheads for paperwork, legal fees and so on. That’s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don’t come with the same overheads >that come with NCC membership, so they may well be considered more valuable/attractive.
At the moment many new LIRs are just joining the RIPE NCC to get small blocks, that is happening.
While I oppose 2015-5 in principle, I’m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there’s no IPv4 left at the NCC.
That doesn’t seem fair. Unless "something which benefits me and/or my customers at someone else’s expense” is the definition of fair.
BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It’s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC’s allocations out of that last /8.
By looking at the current available IPv4 pool, (not that much change since 2012) considering the conditions of the new policy for handing out additional /22 and keep the 185/8 untouched and leave it for new-comers.
You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit: b. Arguments opposing the proposal Further allocations will speed up the depletion of the free pool.
Those arguments are the ones that the proposers foresaw and used to kick off the discussion. Regards, Arash Naderpour -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Tuesday, 10 May 2016 4:34 AM To: Arash Naderpour <arash_mpc@parsun.com> Cc: RIPE Address Policy WG <address-policy-wg@ripe.net> Subject: Re: [address-policy-wg] agreement
On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc@parsun.com> wrote:
In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection?
Well I know I did. Setting up an LIR just to get a /22 is a possibility. The NCC’s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies. While it’s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That’s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don’t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive. If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool?
This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions,
While I oppose 2015-5 in principle, I’m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there’s no IPv4 left at the NCC. That doesn’t seem fair. Unless "something which benefits me and/or my customers at someone else’s expense” is the definition of fair. BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It’s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC’s allocations out of that last /8.
so no change in depletion rate from my point of view.
You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit: b. Arguments opposing the proposal Further allocations will speed up the depletion of the free pool.
On 2016 May 09 (Mon) at 19:33:58 +0100 (+0100), Jim Reid wrote: : :> On 9 May 2016, at 14:25, Arash Naderpour <arash_mpc@parsun.com> wrote: :> :> In the real world, even when a customer needs for example an /24, they need to become an LIR (and get the /22 from the last /8) as their old LIR cannot provide them with additional blocks. That also speed up the depletion of last /8. have you considered these when you made your objection? : :Well I know I did. : :Setting up an LIR just to get a /22 is a possibility. The NCC???s checks on new LIRs should be robust enough to identify this sort of behaviour. Questions would be asked if there was an unusual increase in the rate of membership applications and related anomalies. : :While it???s possible, it seems unlikely that someone would become an LIR just to get a /24 or even a /22 from the NCC. That would cost them a minimum of EUR3400 in NCC fees: an initial sign-up of EUR2000 and annual membership of EUR1400. Plus some overheads for paperwork, legal fees and so on. That???s roughly $5 per IPv4 address, assuming they got a /22. Which is reasonably close to the price in the secondary market IIUC. The addresses available there generally don???t come with the same overheads that come with NCC membership, so they may well be considered more valuable/attractive. : :If people set up LIRs just to get a /22, increasing the NCC (sign-up?) fees would be a quick and effective way to stop that behaviour. ie Once the cost of IPv4 space on the secondary market is less than the NCC fees, why would someone come to the NCC and deplete its pool? : I did exactly that, we created a LIR primarily to get the allocation. At the time we looked, the prices on the secondary market were approx $10/IP, which is far more than the costs of joining RIPE. :> This policy is not increasing the demand for IPv4, It creates a possibility for small LIRs to receive additional blocks (not from last /8) based on some conditions, : :While I oppose 2015-5 in principle, I???m curious why you think the proposal has to favour small LIRs at the expense of other LIRs. And disadvantage future small LIRs once there???s no IPv4 left at the NCC. : :That doesn???t seem fair. Unless "something which benefits me and/or my customers at someone else???s expense??? is the definition of fair. : :BTW, the current policy applies to ALL IPv4 allocations by the NCC, not just those from 185/8. It???s loosely called the last /8 policy. Which is a bit confusing since it applies to more than the NCC???s allocations out of that last /8. : :> so no change in depletion rate from my point of view. : :You're mistaken. Please read 2015-05 again. I suggest you pay closer attention to this bit: : :b. Arguments opposing the proposal : : Further allocations will speed up the depletion of the free pool. : : -- When more and more people are thrown out of work, unemployment results. -- Calvin Coolidge
On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote: :Hi Sander, : :Il 09/05/2016 10:42, Sander Steffann ha scritto: :>Hello Ehsan, :> :>>we are agree about the Last /8 Allocation Criteria Revision proposal . :>>https://www.ripe.net/participate/policies/proposals/2015-05 :>thank you for expressing your support. However, at this point in the discussion we have seen enough support but not enough work solving the objections that have een raised. That is what is needed currently to work towards consensus. Without addressing those objections this policy proposal gets stuck. :Can you please summarize us the main objections about this 2015-05 policy so :that people can try to address a solution to those?
My main objection to this proposal is simple: It depletes the available pool for _new_ participants faster. I strongly believe any new actor should be able to go from zero to non-zero with the addresses available from RIPE. For an actor with non-zero addresses to get more addresses, there is a secondary market. Thi is yourrespectable opinion but my one is that actual allocation rate is mainly due to new LIR sign up rate and in many cases they are end users or customers. Plase look when 2015-01 took place: nothing changed to the pool allocation rate even if abusing stockpilers and seller are affected by
Hi Peter, Il 09/05/2016 14:29, Peter Hessler ha scritto: the fix. This is beacuse of real needing of space, and as newcomer eveyone is legitimate to reiceve its /22 but most of this cases are wasting a lot of space 'cause of the sign up for small needings. When I started my business late 2014 one of my fiber carrier said "ask me for bandwidth and best prices but don't ask for address space. Sign up and get your one" Consider also that advicing customers to sign up as LIR in most cases for a newcomer is also dealing with the probability to loose the customers that can handle everything by theirsefl. As a newcomer nobody would say to his customer feel free to handle everything 'cause I can't provide you the service. This policy is so good in 2 main things: - address the problem of customers make the customers giving new entrants a little bit more space to handle their grow and customer acquisition - incentive the use IPv6. Again this is the ONLY policy that advice LIRs to use IPv6 actually
Since that is the base of my objection, I do not see any way that a middle ground can be met. Based on my understanding of the other objections, I believe this is held by at least a few others from the objection side.
I appreciate the effort put into this proposal, but I do not think any solution can be proposed.
(note: my stance is based on forming a LIR simply to get any amount of announcable addresses.)
I think the middle ground is paying annual fee per IPs in registries. Don't you think? I am happy that you appreciate the effort -- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
Hi Riccardo, This policy is so good in 2 main things: - address the problem of customers make the customers giving new entrants a little bit more space to handle their grow and customer acquisition - incentive the use IPv6. Again this is the ONLY policy that advice LIRs to use IPv6 actually mainly the second one in my opinion is the important thing: if a LIR wants take advantage of this proposal it MUST demonstrate having deployed IPv6 in its network. We could also make stronger this idea of really using IPv6 requesting 4 (or 5 now) stars of RIPEness. So this may be considered such a prize to really do effort in implementing IPv6 (and in Italy we know how we must facilitate it, with less than 0,5% of adoption). Regards, Enrico Diacci. it.tsnet
Goodmorning Enrico, thank you for your opinion Il 10/05/2016 09:18, Enrico Diacci ha scritto:
Hi Riccardo,
This policy is so good in 2 main things: - address the problem of customers make the customers giving new entrants a little bit more space to handle their grow and customer acquisition - incentive the use IPv6. Again this is the ONLY policy that advice LIRs to use IPv6 actually
mainly the second one in my opinion is the important thing: if a LIR wants take advantage of this proposal it MUST demonstrate having deployed IPv6 in its network.
We could also make stronger this idea of really using IPv6 requesting 4 (or 5 now) stars of RIPEness.
So this may be considered such a prize to really do effort in implementing IPv6 (and in Italy we know how we must facilitate it, with less than 0,5% of adoption).
I think higher the prerequisites wouldn't be a problem The problem is that he is against the proposal is very interested in saving IPv4 space instead of start thinking that incentiving IPv6 could be a solution to slow down the allocation rate. I think for most people is a matter of money: no more IPv4 no value in it. With IPv6 deployed and available no problem with IPv4 exhaustion.
Regards,
Enrico Diacci.
it.tsnet
kind regards Riccardo Gori -- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
(note: my stance is based on forming a LIR simply to get any amount of announcable addresses.)
Hi, With a few drawbacks - more de-aggregation, (much) more complex policy - that could be achieved (without speeding up depletion). However, a lot of people let me understand that complexity is a no-go. That could even have been achieved with 2012-04 (rejected back in 2013). -- Radu-Adrian FEURDEAN fr.ccs
participants (17)
-
Arash Naderpour
-
Daniel Stolpe
-
Denis Fondras
-
Ehsan Behbahani
-
Enrico Diacci
-
Garry Glendown
-
Gert Doering
-
Jan Ingvoldstad
-
Jim Reid
-
Michael Oghia
-
Niall O'Reilly
-
Nick Hilliard
-
Peter Hessler
-
Radu-Adrian FEURDEAN
-
Riccardo Gori
-
Sander Steffann
-
Tore Anderson