Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Alexander, Daniel)
2. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Christopher Morrow)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Oct 2012 16:12:08 +0000
From: "Alexander, Daniel" <[email protected]>
To: Christopher Morrow <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID:
<b64177493f39ba4a81233aa84b50049e814c0...@pacdcexmb12.cable.comcast.com>
Content-Type: text/plain; charset="us-ascii"
On 10/18/12 10:56 PM, "Christopher Morrow" <[email protected]>
wrote:
>On Thu, Oct 18, 2012 at 9:14 PM, Alexander, Daniel
><[email protected]> 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
>another.
>
>> 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.
>
>-chris
[DA] The point I was trying to make was not about pushing anyone to the
transfer market. I am trying to understand what kind of allocation
justifies holding address blocks in reserve because their importance is
above everyone else's need?
The reasons a CI classification was created ten years ago, do not exist
today. What is being considered CI today is very different from CI ten
years ago. Whatever might be considered CI ten years from now will be
nothing like it is today. What is it (CI) that needs special consideration
above everyone else in todays Internet?
If we cannot explain why something requires special consideration, how are
we going to quantify it?
-Dan
>
>> -Dan
>>
>> On 10/18/12 8:13 PM, "Scott Leibrand" <[email protected]> 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 <[email protected]> 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 ([email protected]).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact [email protected] if you experience any issues.
>>>_______________________________________________
>>>PPML
>>>You are receiving this message because you are subscribed to
>>>the ARIN Public Policy Mailing List ([email protected]).
>>>Unsubscribe or manage your mailing list subscription at:
>>>http://lists.arin.net/mailman/listinfo/arin-ppml
>>>Please contact [email protected] if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
------------------------------
Message: 2
Date: Fri, 19 Oct 2012 12:48:13 -0400
From: Christopher Morrow <[email protected]>
To: "Alexander, Daniel" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID:
<cal9jlayr6mwva2m12zfloco4pohzrxdhf8ly9cbale7lh6c...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 19, 2012 at 12:12 PM, Alexander, Daniel
<[email protected]> wrote:
>
> If we cannot explain why something requires special consideration, how are
> we going to quantify it?
I had been thinking of CI things as items which all of the rest of the
network depends upon. Examples from this thread are: tld nameservers,
routing-infrastructure.
I think today we can see that 'root/tld nameservers' are things that a
large portion of the network depends on being able to reach/use.
John's point about lisp/rpki bits also needing reachability may also
be true, though to be fair those services are still a bit off (well,
for wide-spread/dependent deployment) in the future.
Stepping back though, do we believe that there's a need for long term
use of stable v4 addresses for services that a large portion of the
network would be dependent upon?
-chris
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 88, Issue 19
*****************************************
