[arin-ppml] Statistics request regarding new entrants (was: Re: Stats request)
mcr at sandelman.ca
mcr at sandelman.ca
Wed Nov 27 19:56:14 EST 2013
Owen DeLong <owen at delong.com> wrote:
>> For ISPs, that is very likely the case (due to policy.) Note this
>> highlights the potential issue for new ISP requesters, in that it is
>> going to become (or is becoming) increasingly difficult to qualify if
>> upstreams do not provide sufficient PA IPv4 space to smaller ISPs such
>> that they can qualify for a direct ARIN allocation later.
> The word you are looking for there, John, is "has become". We've
> already seen multiple reports from members of the community that they
> are deadlocked on this issue because their upstream will not give them
> more space and they don't have enough space from their upstream to
> qualify through ARIN.
Yes, but I do wonder whether having these ISPs *plan* to deploy XLAT464 to
existing customers might provide:
a) enough breathing room to demonstrate need.
b) we could then count the IPv6 networks.
>> That's not readily apparent, but the number of IPv6 allocations to
>> ISPs in total so far this year is 237
>> <https://www.arin.net/knowledge/statistics/index.html> so it cannot be
>> more than about 60% of new requesters along requesting IPv6.
> If they are new entrants, wouldn't it be fairly easy to look at whether
> or not their ORG-ID has received IPv6? Since "have IPv4 from ARIN" is
> pretty much automatic qualification for some amount of IPv6, I would
> say anyone who requested IPv6 and is an IPv4 new entrant likely
> received it to the point that any error from that assumption could be
> considered statistical outliers.
received it does not mean deployed/advertised it and used it.
>> ARIN has no visibility into any of the above, and note that per NRPM
>> 4.2.2, standard ISP allocations are not required to return their
>> blocks from their upstream ISP (those receiving under multihomed
>> policy are required to return)
> The return requirement is primarily enforced by the fact that ARIN will
> not issue additional resources unless/until the block(s) is/are
> What the upstream ISP does with the returned blocks, OTOH, would be
> almost impossible to scrutinize and I suspect there are likely as many
> different answers as there are ISPs receiving returned space.
Why can't ARIN *ASK* in the situations where the block is returned?
We ask to see it returned before the subsequent allocation. Upstream doesn't
need to answer.
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
More information about the ARIN-PPML