[arin-ppml] Draft Policy ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size
christopher.morrow at gmail.com
Thu Oct 18 22:56:51 EDT 2012
On Thu, Oct 18, 2012 at 9:14 PM, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
> Please correct my history if I'm off.
> When CI was originally discussed more than a decade ago, there were two
> main issues. One was a special circumstance was needed to allocate /24's
> since the minimum allocations were much higher at the time. The second
> issue was that a special range was to be identified so the small blocks
> wouldn't get filtered. Ten years ago the minimum routable aggregate on the
> Internet was around a /20.
I think it's also a case that in some (over half it seems) cases the
tld operator has essentially .3% utilization of the /24 in question...
so ideally we (ARIN) would never assign them another /24. Rather,
they'd have to pack more things into the /24 before justifying
> The later issue is long gone. /24 blocks are widely routed. The first
> requirement still remains for the micro allocation and provides for the
> justification needed for a block on the transfer market after the free
> pool is depleted.
> So are we going to reserve a large block of the ARIN free pool so
> for-profit gTLD operators have space waiting, while a non-profit org who
> needs a community network is forced to the transfer market? Of coarse this
> is not the only case to compare, but it is one worth discussing.
right, there are reasons to make the block larger (how large frankly
is hard to say), there are also reasons (good ones) to say:
1) you paid 185k
2) you paid for consultants (round numbers 50k)
3) you paid for network people to help (30k round-numbers)
4) you paid for network links (MRC 6k... maybe)
5) you CAN pay on the xfer-market for the blocks you need.
however... utilization-wise, they'ld never qualify for a /24 in
specified xfer, right? though they could get a /24 from their
provider(s)... but then they are tied to those providers (or a payment
to keep the /24 and exit their link contract).
Some folk say: "push them to the xfer market"
Some folk fall on the: "but this is what the CI space is for..."
Again, if you believe the CI space is for this, a /15 is not enough.
> On 10/18/12 8:13 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
>>What about encouraging TLD operators to acquire /24s on the transfer
>>market? Is there a reason we should be subsidizing them relative to other
>>legitimate uses of IPv4 space?
>>Not necessarily opposed to the proposal, but not sure this aspect has
>>been discussed enough.
>>On Oct 18, 2012, at 6:37 PM, David Farmer <farmer at umn.edu> wrote:
>>> On 10/18/12 13:25 , Christopher Morrow wrote:
>>>> I suspect that the normal operating procedure is to put one NS on each
>>>> /24(or48?), and likely a set of these per TLD.
>>>> You don't want some problem with atld to affect btld just because you
>>>> put them both on the same /24||/48 :(
>>>> Looking at the rootzone (http://www.internic.net/zones/root.zone):
>>>> Zone count: 272
>>>> NSHost count: 1182
>>>> NSAddr count: 1620
>>>> of the addresses there I see some re-use of the actual /32 || /128, 59
>>>> occurances of the same /32 or /128.
>>>> 488 v6 addresses
>>>> 274 unique /48s in that set
>>>> 1132 v4 addresses
>>>> 713 unique /24s
>>> When I looked at this anecdotally, I though I saw way more of them with
>>>multiple servers per /24. So thanks for making the counts, given this
>>>then we should be thinking about a bigger block for sure.
>>>> I think the timeframe is not 2-5 yrs, but 'how long is it that v4 is
>>>> still relevant/required at the TLD level?" and I'd expect that to last
>>>> much further out than 2-5yrs... I was thinking at least 10 if not 20
>>> I'm ok with a goal of 10 to 20 years, but then I think we need to be
>>>talking even a bigger block.
>>> I think Marty is right, that a /14 or more is necessary to deal with
>>>what ICANN is talking about, and that coincides with the 2-5 years I was
>>>talking about. If we want 10 to 20 years worth I think we need to be
>>>talking about something more like /13 then.
>>> Either that, or push CI to make higher density use of the blocks.
>>>> thanks for the conversation so far!
>>> Yes, a good conversation.
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> Please contact info at arin.net if you experience any issues.
>>You are receiving this message because you are subscribed to
>>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>Unsubscribe or manage your mailing list subscription at:
>>Please contact info at arin.net if you experience any issues.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML