"last /8" allocation size - community feedback request before engaging PDP
Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs
On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote:
Hello everybody,
Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf )
Interesting presentation. There are some points there I was no aware of. I would be interested in getting an educated guess what would happen if we went with the following policy: You get /20 to /24 depending on need/want instead of /22 for everybody. This would apply until we have last-/10 where we then go to /22-/24 depending on need/want. We would treat recovered pool the same as last /8, it's just treated as "addresses" so /10 is "/10 worth of adresses". My goal is still to have IPv4 addresses according to this policy by 2020. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Mon, Sep 14, 2015, at 09:33, Mikael Abrahamsson wrote:
I would be interested in getting an educated guess what would happen if we went with the following policy:
You get /20 to /24 depending on need/want instead of /22 for everybody.
This would apply until we have last-/10 where we then go to /22-/24 depending on need/want. We would treat recovered pool the same as last /8, it's just treated as "addresses" so /10 is "/10 worth of adresses".
Point taken and thanks for the feedback. Good to see some people looking at more than /22 in one shot.
My goal is still to have IPv4 addresses according to this policy by 2020.
:) -- Radu-Adrian FEURDEAN fr.ccs
Hi to all. 2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an author). And you suggest to allocate additional blocks now. As told some stuffs from the IPRA, here is the conflict, isn't it? This case community has to cancel 2015-01. 14 сент. 2015 г. 10:17 пользователь "Radu-Adrian FEURDEAN" < ripe-wgs@radu-adrian.feurdean.net> написал:
Hello everybody,
Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf )
Before submitting the proposal we would like to have some community feedback on several aspects :
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail)
3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ???
We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month.
The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :)
Regards, -- Radu-Adrian FEURDEAN fr.ccs
Hi, On Mon, Sep 14, 2015 at 10:36:22AM +0300, Aleksey Bulgakov wrote:
2015-01 has been approved to prevent IPv4 exhaustion
Mostly to prevent policy abuse. IPv4 exhaustion is inevitable. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Mon, 2015-09-14 at 09:51 +0200, Gert Doering wrote:
IPv4 exhaustion is inevitable.
s/is inevitable/has already occured/g IPv4 is by any practical standard; bankrupt. /M - almost out of popcorns
On Mon, Sep 14, 2015, at 09:36, Aleksey Bulgakov wrote:
Hi to all.
2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an
Hello, More to prevent abuse. Today we "celebrate" 3 years into exhaustion and the only thing that can be done is make sure things are less painful until we get rid of the "need for IPv4" by having a fully workable IPv6 Internet (for the moment we don't).
author). And you suggest to allocate additional blocks now. As told some stuffs from the IPRA, here is the conflict, isn't it?
I'm not a broker and not in the transfer business (not at all for now, and if I ever will, it's highly unlikely for me to be on anything other than the receiving side). So I don't see any conflict. Regards, -- Radu-Adrian FEURDEAN fr.ccs
* "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net>
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
B. KISS.
2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail)
Maintain the status quo.
3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ???
None of the above. My preference is to maintain the status quo - no additional allocations. I do not quite see why we should change the «last /8» policy which in my view has been quite successful (except for the abuse that 2015-01 hopefully helps shut down). If it ain't broke, don't fix it? Unless we interpret «broke» to mean «exhausted». If so, c'est la vie. Tore
On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote:
b. treat all addressing space available for allocation as a single pool B. KISS.
2. Conditions for allocation the first /22. Maintain the status quo.
Point taken.
3. Further allocation(s) (after the first /22) None of the above. My preference is to maintain the status quo - no additional allocations. I do not quite see why we should change the «last /8» policy which in my view has been quite successful (except for the abuse that 2015-01 hopefully helps shut down).
If it ain't broke, don't fix it?
Unless we interpret «broke» to mean «exhausted». If so, c'est la vie.
I take "broken" as "painful and far enough from exhaustion", so in need of a fix. Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
On 2015 Sep 14 (Mon) at 10:41:44 +0200 (+0200), Radu-Adrian FEURDEAN wrote: :On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote: :> > 3. Further allocation(s) (after the first /22) :> None of the above. My preference is to maintain the status quo - no :> additional allocations. I do not quite see why we should change the :> ??last /8?? policy which in my view has been quite successful (except for :> the abuse that 2015-01 hopefully helps shut down). :> :> If it ain't broke, don't fix it? :> :> Unless we interpret ??broke?? to mean ??exhausted??. If so, c'est la vie. : :I take "broken" as "painful and far enough from exhaustion", so in need :of a fix. :Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and :RIPE still has more than 0.98 of a /8 available (more likely 0.99). : At my previous company, we joined RIPE as a LIR specifically because there was no other way to get our own IPv4 address space. As a smaller orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ to provide serivces to our users. I support the existing policy, and are very concerned with any proposal that would encourage faster exhaustion of the IPv4 space. I respectfully disagree with the assertion that the existing last /8 policy is painful for everyone.e
On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote:
At my previous company, we joined RIPE as a LIR specifically because there was no other way to get our own IPv4 address space. As a smaller orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ to provide serivces to our users.
This is pretty much the situation at my present company.
I support the existing policy, and are very concerned with any proposal that would encourage faster exhaustion of the IPv4 space.
I respectfully disagree with the assertion that the existing last /8 policy is painful for everyone.e
It depends : if you need more than a /22 it is (very) painful, if you don't - it's not. And don't forget that some people are still arguing that the last /8 policy is to be used as a workaround until IPv6 becomes a useful option. Unfortunately, with the current stocks of available addresses, for a lot of people it doesn't work this way. -- Radu-Adrian FEURDEAN fr.ccs
On 2015 Sep 14 (Mon) at 12:38:14 +0200 (+0200), Radu-Adrian FEURDEAN wrote: :On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote: : :> At my previous company, we joined RIPE as a LIR specifically because :> there was no other way to get our own IPv4 address space. As a smaller :> orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ :> to provide serivces to our users. : :This is pretty much the situation at my present company. : We had zero IPs. And needed ANY, to provide services. Even eight would have been (barely) enough in an emergency. Obviously, RIPE doesn't want to be giving out /29s to everyone that needs to have their own space. Does your service require substantially more than 1024 IPv4 addresses? This adjustment would punish those that only need one, to handle cases where people want more. :> I support the existing policy, and are very concerned with any proposal :> that would encourage faster exhaustion of the IPv4 space. :> :> I respectfully disagree with the assertion that the existing last /8 :> policy is painful for everyone.e : :It depends : if you need more than a /22 it is (very) painful, if you :don't - it's not. Since I was in that situation before, I am very concerned about the smaller players. For each /20 handed out, that is 4 small players that are denied. This, imho, would be a serious disservice to the community at large. :And don't forget that some people are still arguing that the last /8 :policy is to be used as a workaround until IPv6 becomes a useful option. :Unfortunately, with the current stocks of available addresses, for a lot :of people it doesn't work this way. : :-- :Radu-Adrian FEURDEAN :fr.ccs
<Replying in reverse order> On Mon, Sep 14, 2015 at 10:41 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
Is this a problem?
I take "broken" as "painful and far enough from exhaustion", so in need of a fix.
So you will need two policy changes: One to increase run-out speed and one to decrease it again. Or would you introduce another run-out mechanism for "last /8+n" within that proposal? Very much unconvinced, Richard
* "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net>
3. Further allocation(s) (after the first /22) None of the above. My preference is to maintain the status quo - no additional allocations. I do not quite see why we should change the «last /8» policy which in my view has been quite successful (except for the abuse that 2015-01 hopefully helps shut down).
If it ain't broke, don't fix it?
Unless we interpret «broke» to mean «exhausted». If so, c'est la vie.
I take "broken" as "painful and far enough from exhaustion", so in need of a fix.
Is there any urgency in getting closer to full exhaustion (i.e., no remaining austerity pool)? Is full exhaustion somehow less painful than the current status quo? I guess we can look at the ARIN region, as they'll reach that point in the coming weeks. If that situation turns out to benefit their community somehow (like increasing the IPv6 deployment rate), I'm willing to be persuaded that we should open the floodgates and get rid of our austerity pool ASAP. I'm sceptical this will be the case, though.
Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
And those three years we've delegated just shy of a /9: http://www.potaroo.net/tools/ipv4/plotend.png Also, keep in mind that the IANA IPv4 Recovered Address Space pool, which so far has provided the majority (~4M) of the "new" IPv4 addresses added to the austerity pool since the "last /8" policy was implemented, has pretty much dried up. There are currently only 163,481 addresses remaining in that pool earmarked to be delegated to the NCC. In summary I don't think that we can open the faucet any more than it currently is if we want to be able to give IPv4 for new entrants in 2020. Tore
On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote:
* "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net>
I take "broken" as "painful and far enough from exhaustion", so in need of a fix.
Is there any urgency in getting closer to full exhaustion (i.e., no remaining austerity pool)? Is full exhaustion somehow less painful than the current status quo?
I guess we can look at the ARIN region, as they'll reach that point in the coming weeks. If that situation turns out to benefit their community somehow (like increasing the IPv6 deployment rate), I'm willing to be persuaded that we should open the floodgates and get rid of our austerity pool ASAP. I'm sceptical this will be the case, though.
I do think that it will push towards more serious IPv6 deployment (beyond "get the /29 or /32, announce it into the GRT, deployment successful").
Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
And those three years we've delegated just shy of a /9:
Which makes the "austerity pool" (I would rather call it "waste pool") available for about 5-6 more years.
implemented, has pretty much dried up. There are currently only 163,481 addresses remaining in that pool earmarked to be delegated to the NCC.
I am fully aware of that.
In summary I don't think that we can open the faucet any more than it currently is if we want to be able to give IPv4 for new entrants in 2020.
If needed, we can revise things in another 3 years. -- Radu-Adrian FEURDEAN fr.ccs
* "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net>
On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote:
Is there any urgency in getting closer to full exhaustion (i.e., no remaining austerity pool)? Is full exhaustion somehow less painful than the current status quo?
I guess we can look at the ARIN region, as they'll reach that point in the coming weeks. If that situation turns out to benefit their community somehow (like increasing the IPv6 deployment rate), I'm willing to be persuaded that we should open the floodgates and get rid of our austerity pool ASAP. I'm sceptical this will be the case, though.
I do think that it will push towards more serious IPv6 deployment (beyond "get the /29 or /32, announce it into the GRT, deployment successful").
If your goal is to get rid of the IPv4 austerity pool as quickly as possible, that could be accomplished much more quickly and efficiently than creating a "side pool" with associated rules for allocation. Some possibilities: * Re-instate additional allocations with "needs basis" and it'll be gone in a few weeks * Return everything to IANA and decline further allocations from the Recovery pool * Divide it up equally between all members and allocate everything at once * Divide it up between all members based on the current amount of IPv4 addresses held and allocate everything at once * Divide it up equally between all members holding a five-star RIPENess rating and allocate it all at once * Auction it all off to the highest bidder(s), use proceeds to reduce membership fees, give a cash return to members, or donate it to charity IFF it could be demonstrated clearly that it would help further IPv6 deployment, I'd be willing to be persuaded into supporting a policy proposal which leads to the rapid depletion of the austerity pool, thus bringing us in line with ARIN. Regarding the side pool idea specifically, an interesting post appeared today on APNIC's policy list, which had the following to say about their side pool: «2. Status of IANA Recovered pool (non-103) - Will run out in next 7 months+ - IANA may allocate additional space in every 6 months - This pool will repeatedly ‘run-out’ as IANA delegates more space and it is distributed by APNIC» http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/09/msg00025.h... I don't think duplicating this in our region would be helpful at all.
Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99).
And those three years we've delegated just shy of a /9:
Which makes the "austerity pool" (I would rather call it "waste pool") available for about 5-6 more years.
In my opinion that would the optimal outcome, and precisely the reason why I do not support creating a side austerity pool or changing the allocation criteria for the main austerity pool at this point in time. Tore
On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
The only reason I can see is to keep the unused, continuous blocks in 185.0.0.0/8 if we ever need them for something else and thus try to get rid of the recovered pool first.
2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail)
"First"? This already implies a change afaict.
3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ???
Why change it? This means that everyone will optimize for the maximum size in whatever way they can. And that's without the "I only got /n+1, while foo got /n, that's unfair" and the much-beloved "/n is not enough; let's increase to /n-1 as we already did once" (once==the proposal in this thread). If people want to get something longer than a /22, that might be a valid use case, but I am not convinced there will be enough to merit a pdp for this. Point in case: I helped an entity to become a LIR as they needed one /24. Within two months, they had an actual, valid use case for a second /24. If I had gotten them a /24 instead of a /22, we would then have had to jump through the hoops again. That's why a flat "no need, just /22" policy makes it simpler; even if it's wasteful in some cases. Richard
Richard, all - On 14.09.2015 10:14, Richard Hartmann wrote:
On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
The only reason I can see is to keep the unused, continuous blocks in 185.0.0.0/8 if we ever need them for something else and thus try to get rid of the recovered pool first.
how about combining this by treating all addresses equal in a single pool, but advising the NCC to hand out recovered addresses first unless there are specific, yet-to-be-defined reasons that they rather need to come from the 185/8 heap? Cheers, -C.
On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote:
Hello everybody,
Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf )
Before submitting the proposal we would like to have some community feedback on several aspects :
1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool
This is the only part I find - and always found - a bit strange. I guess it does probably not make a lot of differense in practice, anyone knows the actual size of the "recovered pool"? As the policy was written, once we hit the "last /8" stage there was no going back. Even if we for some reason would recover a lot more or start delegating E class or whaterver. I think it would be more logical to define the "last /8" as the actual last /8 (185/8). People sometimes ask us whether to return unused address space to the RIPE NCC and we always tell them not to because the free pool has become a black hole. But as/if the recovered pool is probably comparatively small, it is not a big issue. 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, 1. separate pool and APNIC-like distribution of additional blocks from recoved space pool 2. no conditions for first /22 allocation, the goal is distribution of resources and I can't see any benefit by adding this restriction 3.3.1 I don't think this one is a fair one: "LIR did not perform an outbound transfer" I'm also thinking to prepare a proposal to remove current 24month transfer wait period (or adjust it), IPs should be transferred easily for a better utilization and really like to see the community feedback on your proposal. Regards, Arash Naderpour -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Radu-Adrian FEURDEAN Sent: Monday, September 14, 2015 5:17 PM To: address-policy-wg@ripe.net Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs
Hi,
3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ?
While I like this idea, please do realise that a /8 has 16384 /22s in it. RIPE NCC has more than 12000 LIRs at the moment. Many of those would already qualify for an additional allocation based on this. That could drain the pool in a very short time...
3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ?
Re-introducing different allocation sizes would also mean going back to a needs-based system. I'm not sure we want to add that overhead/bureaucracy again. A lot of people were quite happy with 2013-03. Changing the size to a /24 for further allocations would extend the lifetime of the pool, but on the other hand I'm not sure if handing them a /24 every x months will really help many LIRs, and the routing overhead will be a lot more interesting... So while I am happy to see work being done on this, I am still a bit cautious. But I'd love to be shown wrong :) Cheers, Sander
On Mon, Sep 14, 2015 at 09:17:04AM +0200, Radu-Adrian FEURDEAN wrote:
Before submitting the proposal we would like to have some community feedback on several aspects :
My thoughts: 1) anything that increases the bureaucracy required to deal with the NCC for a first allocation is a non-goer. 2) I could live with giving a LIR which has only received an "austerity /22" another shot after a certain time, but I'd couple it with some proof of ipv6 deployment (beyond just advertising a /32) 3) The edge case of a LIR not needing the full /22 can be handled by the transfer market. If you still think you don't need the other three /24s after 24 months, sell them. rgds, Sascha Luck
On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote:
1) anything that increases the bureaucracy required to deal with the NCC for a first allocation is a non-goer.
2) I could live with giving a LIR which has only received an "austerity /22" another shot after a certain time, but I'd couple it with some proof of ipv6 deployment (beyond just advertising a /32)
If you have some ideas of how to reliably determine "real ipv6 deployment" *AND* write down that criteria in a policy-friendly way, you're welcome (want to be part of the proposal ? - ok). -- Radu-Adrian FEURDEAN fr.ccs
On Mon, Sep 14, 2015 at 03:49:24PM +0200, Radu-Adrian FEURDEAN wrote:
On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote:
If you have some ideas of how to reliably determine "real ipv6 deployment" *AND* write down that criteria in a policy-friendly way, you're welcome (want to be part of the proposal ? - ok).
I know that it's not likely we could come up with something that is 100% reliable. I was thinking along the lines of a statement in the allocation request like: "We have deployed IPv6 to our customers and we are using $technology to do it." combined with a mini-audit focusing on ipv6 assignments. I know this could be gamed but it may serve as a gentle nudge in the direction of at least making *some* effort towards ipv6 deployment. rgds, Sascha Luck
participants (13)
-
Aleksey Bulgakov -
Arash Naderpour -
Carsten Schiefner -
Daniel Stolpe -
Gert Doering -
Martin Millnert -
Mikael Abrahamsson -
Peter Hessler -
Radu-Adrian FEURDEAN -
Richard Hartmann -
Sander Steffann -
Sascha Luck [ml] -
Tore Anderson