[address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations)

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