This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
- Previous message (by thread): [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
- Next message (by thread): [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue May 24 07:57:45 CEST 2016
* Riccardo Gori > Hi again Tore, > > Il 22/05/2016 12:01, Tore Anderson ha scritto: > > * Riccardo Gori > > > >> and we turn minimum request to a /24 > >> we can address this kind of problem while slowing down LIRs sign up rate > >> to obtain a /23 or /24 to address this kind of requests > > This, in isolation, I think is idea worth exploring further. > > > > The minimum allocation size started out as a /19 (cf. ripe-136). Over > > time it's been adjusted down to the current /22. I think it might be > > prudent to continue this trend at some point. > > > > For example: change it to a /23 at the point when the NCC pool reaches > > the equivalent of a /9, and then to a /24 when the pool reaches the > > equivalent of a /24. > > > > This would ensure the last /9-equivalent could accomodate three times > > as many new entrants (24576) than if we continue with /22s (8192). > > > > One would hope that even though the future new entrants will continue > > to need some IPv4 to start their business, the amount will decrease as > > IPv6 deployment increases. That is, a new entrant receiving a final /23 > > in 2017 might find it about as useful the final /22 was to a new > > entrant in 2013. > > > > Depending on how the membership fees and the pricing in the second-hand > > IPv4 market develops, this could also help discourage abuse: if > > everything else remains the same, the cost per address would > > essentially double at each adjustment. > > > > > > Another thing worth considering (separately) is to stop issuing > > additional allocations. An "old LIR" (one that held IPv4 allocations on > > the 14th of September 2012 that hasn't needed to request its final /22 > > in the four years since, is likely not growing anyway and that space is > > better spent for new entrants. Four years is in any case a much longer > > period than the LIRs last allocation was supposed to last. > > > > Basically we'd need to change bullet #2 in ripe-649 section 5.1 to just > > say «an LIR that currently hold or have previously held an IPv4 > > allocation is not eligible» or something like that. As an added bonus, > > we'd then get rid of the quirky unexplained 14-09-2012 date referenced > > in the current text. > > > > This would prevent "old LIRs" that are already holding lots of address > > space, perhaps mostly unused, from being able to pick up a final /22 > > anyway. I can easily see that a "new LIR" making very efficient use of > > its final /22 while being unable to request another would find this very > > unfair, as would the new entrants that inevitably would be denied any > > final IPv4 allocations down the line (due to full depletion happening > > earlier). > > > > Unfortunately I won't be in Copenhagen so just consider this me > > thinking out loud here on the list instead of at the Open Policy Hour. > > I'm not going to submit any proposals myself though so anyone should > > feel free to take the above ideas and run with them. > > > > those above statements are the most constructives. > So we agree toghether that last /8 had its good effects but can be tuned > to adapt itself to the current times coming? I believe the «last /8» policy so has been, and continue to, work very well. If not for that policy, the new members joining since 2013 or so would not have been able to request any IPv4 at all. Of course, it is certainly possible to tune it further - after all, the RIPE community has done precisely that on several occasions already. I don't see it as a *necessity* though; that is, the policy isn't broken (it's working as intended and quite well too) so it doesn't really need fixing. I'd be happy enough if we leave it as-is too. Tore
- Previous message (by thread): [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
- Next message (by thread): [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]