[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
    > returned.

    > 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 mailing list