Hello working group, The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-02.html So: please comment on this proposal. Thank you, Sander Steffann APWG co-chair
* Sander Steffann
The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses.
«He who remains silent, agrees», as we say here in Norway... Anyway. I feel version 3 solves the objections I had against version 2, so I support the proposal. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
I don't have an opinion as to whether rationing the last /8 is a good idea, but I do have a comment/question: It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent? Scott On Oct 21, 2010, at 8:35 AM, Sander Steffann <sander@steffann.nl> wrote:
Hello working group,
The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses.
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-02.html
So: please comment on this proposal.
Thank you, Sander Steffann APWG co-chair
Hi Scott,
It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent?
It makes sure that there is one clearly defined /16 block reserved. Otherwise we might end up with unused fragments all over the whole /8. I don't know if that was the intent of the authors, but it might be useful and it doesn't seem to have any negative side effects. - Sander
On Oct 21, 2010, at 9:58 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi Scott,
It seems that section 2 is a no-op, because the space is not really reserved if it's just returned to the pool when the /8 runs out... Is that the intent?
It makes sure that there is one clearly defined /16 block reserved. Otherwise we might end up with unused fragments all over the whole /8. I don't know if that was the intent of the authors, but it might be useful and it doesn't seem to have any negative side effects.
Ok. That seems more like implementation detail than policy, but I agree it doesn't hurt. Thanks, Scott
On 21/10/2010 13:35, Sander Steffann wrote:
The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward.
I suspect people aren't commenting because - like me - they don't really understand the consequences of implementing a proposal like this. The obvious impact is that post-depletion, there will be the ability for up to 16384 LIRs to receive a /22 before the /8 runs out. There are currently ~7540 open LIRs, as far as I can make out. This means that potentially up to 8800 new LIRs will be able to open, post depletion. This is good from the following points of view: 1. it removes a barrier to new entry to business. Apart from the direct reasons why this is important, it will also sooth regulators who view barriers to market entry as matters worth investigating. 2. it will create a de-facto stabilising influence on any IPv4 address market which may spring up. I.e. 4 x /24 will cost €1300 + (€2000/4), assuming a 4 year write-down. Therefore there will be a tendency to fix the lower bound of the price of a /24 to €1800/4 = €450 per annum. While relatively high, there is value is market stabilisation. However, the proposal will also turn small quantities of address space into marketable assets, and shelf LIRs are likely to pop up all over the place with the sole intention of garnering ipv4 address space for resale or rental. This is bad for the following reasons: 1. rapid new LIR creation will cause strain on RIPE NCC resources, leading to medium term organisational strain. 2. the RIPE NCC is very likely to put in much more stringent checks to ensure that new LIRs are genuinely in the business of service provisioning. This will be a pain and will cause more paperwork / mouth-frothing / bureaucracy. I am sure that retrospect would point out many other advantages and disadvantages. My own opinion is that the advantages are quite significant. The disadvantages certainly exist, but are less significant. Therefore I support the proposal. There is no right answer for a proposal like this. Contention for scarce resources is fundamentally contentious. We just have to live with that. If it turns out that significant implementation problems arise, the proposal can be changed. Nothing is set in stone. Nick
On 27 Oct 2010, at 01:39, Nick Hilliard wrote:
My own opinion is that the advantages are quite significant. The disadvantages certainly exist, but are less significant. Therefore I support the proposal.
+1
There is no right answer for a proposal like this. Contention for scarce resources is fundamentally contentious. We just have to live with that.
I agree. There is no perfect solution and I hope we can give up on that quest. So let's settle for something that's good enough -- ie 2010-02 -- and get on with it. There will always be some way for a consensus policy to be gamed. So it's better to have ways of detecting that and acting on it instead of looking for a policy that is immune to manipulation. And have that in place before v4 runs out.
If it turns out that significant implementation problems arise, the proposal can be changed. Nothing is set in stone.
True. Though I doubt this matters. If there are implementation difficulties, these should act as a natural brake on depletion. And anyway the chances are v4 will be gone by the time a revised policy could be adopted. I'm also unsure if strict checks on access the near-empty v4 shelves in the corner shop will matter much when there's a hypermarket next door that's over-filled with v6.
On Wed, Oct 27, 2010 at 02:39, Nick Hilliard <nick@inex.ie> wrote:
[...]
I agree with everything Nick said. If possible, RIPE NCC should weed out people trying to game the system but it's simply impossible to be 100% sure. Richard
Thanks for this. Simple and straight forward enough, but I'm not in support of this proposal. Section two is redundant and linkage to v6 is perfunctory at best so why bother codifying at all? I think we get the message with respect to exhaustion and v6 and further marketing is not necessary. Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead. I don't have a better proposal or more interesting suggestion other than we're probably better off doing nothing than this. Best Regards, -M< On 10/21/10 8:35 AM, "Sander Steffann" <sander@steffann.nl> wrote:
Hello working group,
The review phase of proposal 2010-02 has ended. During this review phase no comments were received. Without any feedback this proposal can't move forward. I think that it is important that we, as a working group, decide about what we are going to do with the last IPv4 addresses.
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-02.html
So: please comment on this proposal.
Thank you, Sander Steffann APWG co-chair
Hi, * Hannigan, Martin
Section two is redundant and linkage to v6 is perfunctory at best so why bother codifying at all? I think we get the message with respect to exhaustion and v6 and further marketing is not necessary.
I do agree with you on both of these points, but I don't feel that getting rid of them are reason enough alone to start over again. There's not that much time left, and the two points in question are mostly no-ops and have no real harmful effects.
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
I don't have a better proposal or more interesting suggestion other than we're probably better off doing nothing than this.
The problem with continuing as before is of course that a single or a small number of LIRs could potentially allocate the entire last /8 over just a few days. In my opinion this situation would be decidedly more unfair than the one proposed here. It would also create a barrier of entry to the market. A startup ISP that can not get _any_ IPv4 addresses to number their LSN, AFT, MX-es, and other critical infrastructure that needs to communicate with the legacy IPv4 internet, would be dead in the water. With not enough addresses to go around achieving complete fairness is impossible. I support 2010-10 as it is the least unfair proposal I've seen so far. It's worth noting that similar policies are adopted in other regions: http://nro.net/documents/comp-pol.html#2-6 Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
On 10/28/10 2:15 AM, "Tore Anderson" <tore.anderson@redpill-linpro.com> wrote:
Hi,
* Hannigan, Martin
Hi Tore,
Section two is redundant and linkage to v6 is perfunctory at best so why bother codifying at all? I think we get the message with respect to exhaustion and v6 and further marketing is not necessary.
I do agree with you on both of these points, but I don't feel that getting rid of them are reason enough alone to start over again. There's not that much time left, and the two points in question are mostly no-ops and have no real harmful effects.
Point taken. Removing these entirely works in the interest of simplicity and conciseness.
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
I don't have a better proposal or more interesting suggestion other than we're probably better off doing nothing than this.
The problem with continuing as before is of course that a single or a small number of LIRs could potentially allocate the entire last /8 over just a few days. In my opinion this situation would be decidedly more unfair than the one proposed here.
I don't disagree, but I am concerned that such modifications to the need approach without some measure of fairness swings the pendulum too far to the opposite condition, where it enables those that do not have need or reduced need to gain an unfair advantage. Granted, we are talking about a small amount of addresses, but considering the likely exorbitant cost of acquiring even a single address outside of the RIR system I would argue that it matters.
It would also create a barrier of entry to the market. A startup ISP that can not get _any_ IPv4 addresses to number their LSN, AFT, MX-es, and other critical infrastructure that needs to communicate with the legacy IPv4 internet, would be dead in the water.
Couldn't we argue the opposite saying that the barrier is neutralized with V6? It won't be perfect for the short term, but it does allow entry.
With not enough addresses to go around achieving complete fairness is impossible. I support 2010-10 as it is the least unfair proposal I've seen so far.
It's worth noting that similar policies are adopted in other regions:
Noted with the caveat that no two regions are alike and no single policy fits all with respect to the uniqueness of each RIR. Whether a single ISP takes the entire last /8 or we utilize the Robin Hood approach in the end the consumers are going to pay regardless so it's almost irrelevant. With regards to the NRO comparison of proposals in each RIR region, in the ARIN region austerity measures are implemented with the last /8. Need goes from 1 year to 3 mos. The ARIN measure is also under considerable pressure with respect to conversion from it's existing form to something that is directly tied to transition and more even-handed. It remains to be seen if something will be able to be done to address it prior to full implementation. Best Regards, -M<
On 28 Oct 2010, at 00:37, Hannigan, Martin wrote:
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
As I read the proposal, the allocation of a single prefix of the same size to each LIR is not at all regardless of need, but prioritizes a different need -- that of access to the post-depletion market -- over the pre-depletion need to obtain address allocations for assignment to customers. IIUC, the idea here is that the growing Internet will be IPv6-only; that 6to4 gateways or other continuity measures will be required; that the opportunity for new market entrants to run their own continuity infrastructure should be protected; and that a single, small allocation per LIR will afford this protection. That seems pretty _fair_ to me, in the circumstances. ATB Niall
On 28 Oct 2010, at 11:53, "Niall O'Reilly" <Niall.oReilly@ucd.ie> wrote:
That seems pretty _fair_ to me, in the circumstances.
Post depletion, there will be no such thing as "fair", just varying degrees of "unfair". Nick
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
you're absolutely right. we'll have the ncc go out and manufacture more integers immeduately. why had we never thought of that? embarrassing. randy
On 10/28/10 1:10 PM, "Randy Bush" <randy@psg.com> wrote:
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
you're absolutely right. we'll have the ncc go out and manufacture more integers immeduately. why had we never thought of that? embarrassing.
We agree except for the negative cost shifting implications. Need Cost (euro) After Proposal (euro) /32 54.83 0 /31 109.65 0 /30 219.31 0 /29 438.61 0 /28 877.23 0 /27 1,754.46 0 /26 3,508.92 0 /25 7,017.83 0 /24 14,035.66 0 /23 28,071.32 0 /22 56,142.64 0 /21 112,285.29 56,142.64 /20 224,570.57 168,427.93 /19 449,141.15 392,998.50 /18 898,282.29 842,139.65 /17 1,796,564.58 1,740,421.94 /16 3,593,129.16 3,536,986.52 /15 7,186,258.33 7,130,115.69 /14 14,372,516.66 14,316,374.02 /13 28,745,033.32 28,688,890.68 /12 57,490,066.64 57,433,923.99 /11 114,980,133.27 114,923,990.63 /10 229,960,266.55 229,904,123.90 /9 459,920,533.09 459,864,390.45 /8 919,841,066.19 919,784,923.55 Table represents a post depletion cost of $40[1] (FX to euro) subtracting the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with respect to need. The economics of this proposal and their implications are not clear hence my thinking around doing nothing instead. What are the most common 6 prefix sizes allocated in the RIPE region? For example, if it were these: /22 56,142.64 0 /21 112,285.29 56,142.64 /20 224,570.57 168,427.93 /19 449,141.15 392,998.50 /18 898,282.29 842,139.65 /17 1,796,564.58 1,740,421.94 I'd argue that this would be the focused unfairness of this proposal. I'm not even trying to make a big network argument since the damage is noise in the grand scheme of things for most of them. Best, -M< 1. Recently, there was an auction of a swamp /24 on eBay that had been bid up to $40 prior to the closing 60s of the auction where most of the pricing action occurs. I have no evidence to support $40 other than the observation and the widely held belief that this is reasonable. Factors of 10 for your comfort since we do have a reference over 2 years old for addresses @ $4.00.
Marty, On Oct 28, 2010, at 8:37 AM, Hannigan, Martin wrote:
Table represents a post depletion cost of $40[1] (FX to euro) subtracting the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with respect to need.
Sorry, I'm confused. How can you estimate the "post depletion cost" prior to depletion occurring? I would find it surprising if the fact that a /24 was bid up to $40 on eBay while folks can still get address space from registries had any relationship with what the price would be when the registries are no longer 'distorting the market'. Regards, -drc
On 10/28/10 4:35 PM, "David Conrad" <drc@virtualized.org> wrote:
Marty,
On Oct 28, 2010, at 8:37 AM, Hannigan, Martin wrote:
Table represents a post depletion cost of $40[1] (FX to euro) subtracting the "value" of a /22 ($56,142.64 FX to euro) as we go down the line with respect to need.
Sorry, I'm confused. How can you estimate the "post depletion cost" prior to depletion occurring? I would find it surprising if the fact that a /24 was bid up to $40 on eBay while folks can still get address space from registries had any relationship with what the price would be when the registries are no longer 'distorting the market'.
I was clear in the footnote that I only have a reference[1] for the lower number. To answer your question as to why, the table that I provided speaks for itself even if reduced by multiple factors of ten; profit and/or revenue protection. Buy low, sell high, so to speak and I think that the main point is that the cost of an address post depletion is an unknown. While my number looks high, it could go either way. It could be higher which would mean that the damage would be greater or it could be lower which means that it's "not so bad" where YMMV. Best, -M< 1. http://www.ripe.net/ripe/meetings/ripe-57/presentations/van_Mook-2007-08_v3. pdf
On Thu, Oct 28, 2010 at 22:54, Hannigan, Martin <marty@akamai.com> wrote:
While my number looks high, it could go either way. It could be higher which would mean that the damage would be greater or it could be lower which means that it's "not so bad" where YMMV.
Which basically boils down to "no one can possibly know". Also, I doubt that the cost for prefixes will be strictly linear. It's in the nature of depletion that not everyone can get what they need/want. The proposal clearly states that its main focus is to prevent prefix hogging if possible and thus limit the impact of a probably frantic migration period and lower the barrier of entry for new LIRs. And while I sincerely hope that IPv6 migration will happen fast, there will definitely be a time when IPv4 will be a hard requirement for any LIR that wants to compete. As you admit yourself, other than doing nothing you don't know of any alternative. Richard
Hello, On 10/28/2010 01:37 AM, Hannigan, Martin wrote:
Allocating each LIR exactly the same sized prefix regardless of _need_ is pretty unfair sll considered. The addresses could be utilized more efficiently addressing qualified need instead.
Allocations from _last_ /8 in my oppinion are special and we don't need fulfill LIRs needs like "additional /16" here. Allowing larger allocations from last /8 simply stalls implementation of IPv6 in networks around and will exhaust existing space more quickly. And it's typical argument from many network operators even in these days - until they'll have enough IPv4 resources, they'll not care about IPv6 at all. By this proposal, everyone knows in advance, that from some term they'll receive only /22 allocation and nothing more. This proposal simply shifts time of real depletion more closely, BUT there's some special reserve to serve additional requests in accordance to defined rules. This is quite fair, as it's announced in advance. On 10/28/2010 01:37 AM, Hannigan, Martin wrote:
I don't have a better proposal or more interesting suggestion other than we're probably better off doing nothing than this.
Doing nothing is not a option, at least not for me. This sounds like you want to simply depredate land (available addresses) as much as possible a you don't care about the future. I'm seeing proposal 2010-02 as compromise - in my oppinion, some remaining IPv4 address space should be reserved ONLY for _new_ LIRs to give them some IPv4 address space and this proposal efectivelly does this (and in addition, existing LIRs can be served, too). And even there're some economical implications, the proposal itself isn't primary about money and cost of IPv4 address, this is technical proposal. It's about address distribution to new and existing LIRs. And we have to care about new LIRs, we need to reserve some address space for them - as lots of internet resources will be accessible only over IPv4 for long period after depletion. It's about survivance of free allocatable IPv4 address space as long as possible. So, I'm personally SUPPORTING this proposal - as doing something is better than doing nothing and just wait for depletion. And I'm not seeing any major reason, why not support 2010-02 proposal - it's simple and clear. With regards, Daniel
participants (11)
-
Daniel Suchy -
David Conrad -
Hannigan, Martin -
Jim Reid -
Niall O'Reilly -
Nick Hilliard -
Randy Bush -
Richard Hartmann -
Sander Steffann -
Scott Leibrand -
Tore Anderson