[arin-ppml] Draft Policy ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size

[Alexander, Daniel]

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.

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.

-Dan

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.
>
>Scott
>
>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
>>> yrs.
>> 
>> 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!
>>> -chris
>> 
>> Yes, a good conversation.
>> 
>> _______________________________________________
>> PPML
>> 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:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>_______________________________________________
>PPML
>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:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.