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/address-policy-wg@ripe.net/
[address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations)
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Radu-Adrian FEURDEAN
ripe-wgs at radu-adrian.feurdean.net
Fri Apr 24 16:29:38 CEST 2015
On Thu, Apr 23, 2015, at 20:20, Gert Doering wrote: > Hi, > > this thread has drifted quite far, but a few comments need to be made: Hence the subject change.... > It definitely is way outside the scope of this proposal. Bringing back > needs based allocation, removing the last-/8 policy, or changing the > size of the last-/8 allocation would have to be a separate policy > proposal. I agree with this. The real question is : do we need any of these changes or not ? If yes, which of them and in which form. I preffer some discussion before trying to propose anything. > proposal, it has been abolished because there is nothing left to allocate > based on "need" - if I need a /8, and you need a /20, we both get a /22, Some don't even "need" a /22. But they can get it (and then sell it). Before, you had to provide some explanation on why do you need your last /22. Now you don't - you just promise to make allocations out of it. > so where's the benefit in having a complex system that will lead to the > same result anyway, no matter how big your need is? The "same result" is the part I don't fully agree with. > In which way has the situation changed, except that we're now very close > to *3* RIRs having run out of IPv4 addresses (and/or are in the "last /8" > phase)? Today's state of fact: - APNIC : last /8 policy since 2011. LIRs can get one /22 from the "103-pool" and one /22 fron the "non-103" pool, which only exists sicne 2014. "needs-based". - LACNIC : phase 2 (of 3) of the run-out plan since 06/2014, companies can get a /22 every 6 months, until the reserves fall to a /11 (phase 3, where strictly one /22 will be available). Gradual enforcement of the needs-checking. - ARIN : last /8, phase 4 since 04/2014 - members("LIRs") can get as much as whey "need", with the chacking of actual needs being reinforced. - AfriNIC : "peace and love", 2.6 /8s available. About 2 years ahead before entering in any form of "last /8". - RIPE NCC: "last /8" since 09/2012. As of 04/2015 (more than 30 months later) the free pool is *bigger* than a /8, due to recovered and re-allocated space from IANA). No needs policy. Exactly one /22 per LIR, but with a backdoor (several LIRs). Short : the situation changed by the fact that now RIPE has a bigger pool than at the time of actication of the "last /8" policy. Yes, after 2.5 years, RIPE has more free space. Second RIR in terms of "free stock" and the most conservative at the same time. > Has someone discovered a magic store of IPv4 addresses that we > can use to return to the time of large pools and /10 allocations to big > telcos? There is a huge distance between /22 and /10. Some people would be more than happy with a /20, which is probably what some big telcos would be able to recover just by recovering space provisioned for "no longer clients". Some strict needs-based allocation should be able to help some small players to get to a decent situation. We basically have almost 3 years worth of /22 available via "returned space" that could be re-distributed : - based on valid/validated needs - from the IANA recovered space allocated to RIPE NCC - only to players below a certain threshold (like the ones having only received a /22 from the 185-pool, or the ones that never received more than a /20 or /21) - extra allocation possible X months after the "185-pool allocation" , X to be defined (?? 12 ?? 24 ??) - second and possibly third allocation, if still available after another Y months (Y = ?? 12 ?? 24 ?? 30 ?? 36 ??) Those are just ideas, not all of them need to be transposed into policy text (if policy will be). > I'm sure you understand that there's thousands of RIPE LIRs out there > that *all* want IPv4 space - so if you loosen up the policy too far, RIPE NCC No, they don't *ALL* want IPv4 space, and amongst the ones that do want, not all of them want it today. Hell, there's some of then that only wanted a /24 or /23 PI space ! > will dry out in a few months, and nothing will be left. This is what ARIN > (consciously) did, not having a soft-landing / last-/8 policy, and we > decided that we want to have a long tail of "some leftover bits of addresses > to hand to newcomers in the market, 5 or 10 years hence". 5-10 years since when ? since 09/2012 ? At the current rate we will do the 5 years (2017) without any problems, and still have enough space. We will most probably do the 10 years (2022) and still have some space. On the other hand, how do you really expect people to take IPv6 seriously when you plan on having "just enough" free IPv4 space by 2020 ? Did you disqualify any vendor because of lack of IPv6 support ? Becasue of improper IPv6 support ? Because of impossibility to function without IPv4 ? I expect *you* did it at least once, but how many people didn't because, "nah, we can sill have some IPv4, more than enough if we count the RFC1918" ? Provider-wise, you need IPv4 for lots of things, unless you do it "corporate-style" (RFC1918 everywhere, with the risk of "my 10.1.1.2 must send data to your 10.1.1.2"). So no, softening the "last /8 policy" does not necesarily mean giving big allocations to everyone and burning out ressources in 2 months. And shortening the life of the "free pool" by a few years isn't necesarily such a bad thing in the global context. Besides, we just won 2.5 years recently. Also imagine the posibilities of what might happen when ARIN will be totally out of stock (most probably before the end of the year) if US companies start opening subsidiaries in Europe just in order to have some more small chunks of IPv4; because there's no needs checking. Do we want ot handle those situations in a reactive manner (like this open-transfer-close issue) or in a more pro-active one ? > have you enabled IPv6 on something today...? No, had to fix broken IPv6 things. -- Radu-Adrian FEURDEAN fr.ccs
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]