[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 ]
Wilhelm Boeddinghaus
wilhelm at boeddinghaus.de
Sun May 22 12:27:29 CEST 2016
Hi, Am 22.05.2016 um 12:01 schrieb Tore Anderson: > * 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. > > Tore > in a membership organisation we have to treat all members equal when it comes to distributing the final IPv4 networks. You cannot take the right to request the final /22 away just because a member had no need so far to ask for it. This should have been put in the policy a few years ago (like "you have 4 years to request your /22") , but you cannot change this today working backward. Wilhelm
- 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 ]