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 (David Farmer)
2. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Scott Leibrand)
3. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Alexander, Daniel)
4. Re: ASN Transfer Completed (John Curran)
5. Re: ASN Transfer Completed (Mike Burns)
6. Re: Draft Policy ARIN-2012-6: Revising Section 4.4 C/I
Reserved Pool Size (Christopher Morrow)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Oct 2012 18:37:37 -0500
From: David Farmer <[email protected]>
To: Christopher Morrow <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2012-6: Revising Section
4.4 C/I Reserved Pool Size
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
------------------------------
Message: 2
Date: Thu, 18 Oct 2012 19:13:05 -0500
From: Scott Leibrand <[email protected]>
To: David Farmer <[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: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 3
Date: Fri, 19 Oct 2012 01:14:02 +0000
From: "Alexander, Daniel" <[email protected]>
To: Scott Leibrand <[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:
<b64177493f39ba4a81233aa84b50049e814bd...@pacdcexmb12.cable.comcast.com>
Content-Type: text/plain; charset="us-ascii"
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" <[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.
------------------------------
Message: 4
Date: Fri, 19 Oct 2012 01:44:11 +0000
From: John Curran <[email protected]>
To: David Farmer <[email protected]>
Cc: ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] ASN Transfer Completed
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Oct 4, 2012, at 11:59 AM, David Farmer <[email protected]> wrote:
> I noticed from the following that an ASN transfer has been completed,
> specifically AS3943;
>
> https://www.arin.net/knowledge/statistics/transfers_8_3.html
>
> This is a significant milestone. However, looking at the associated Whois
> record, I'm confused by a couple issues and have a some questions;
>
> http://whois.arin.net/rest/asn/AS3943/pft
>
> A. The registration date is listed as 2001-05-18; If the ASN were recently
> transferred wouldn't it have a new registration date of when the transfer was
> completed? This seems to be the case when an IPv4 prefix is transferred.
This has been resolved; specified transfers per NRPM 8.3 do
result in a new registration date, whether IPv4 block or ASN.
> B. One of the POCs for what I presume is the receiving organization seems to
> not have been validated; I thought organizations with invalid POCs were
> prevented from completing various transaction with ARIN without validating
> all their POCs? Why isn't receiving a transfer one of these transaction?
This was an oversight and is in the process of being corrected.
> I want to apologize to the organization involved, my intent is not to call
> public attention to them specifically. However, it is difficult to ask these
> questions with specific examples without such side-effects. I an truly
> sorry, but I think these are important questions for the community. Also, I
> request that as we discuss this, that we not directly refer to the
> organization involved, as I do not believe that the organization involved is
> particularly relevant to the discussion.
>
> Also, it occurs to me that the page in question is specific to Section 8.3
> transfers, will Section 8.4 transfers be included on this page or a separate
> similar page created when they start occurring? In the case of 8.4 transfers
> it might be useful to include the other RIR that is either the source or
> recipient of the inter-RIR transfer as well as the prefix involved in the
> transfer.
Yes, we intend to publish similar statistics regarding 8.4 inter-RIR
transfers.
Thanks!
/John
John Curran
President and CEO
ARIN
------------------------------
Message: 5
Date: Thu, 18 Oct 2012 22:35:40 -0400
From: "Mike Burns" <[email protected]>
To: "John Curran" <[email protected]>, "David Farmer" <[email protected]>
Cc: ARIN PPML <[email protected]>
Subject: Re: [arin-ppml] ASN Transfer Completed
Message-ID: <1DA675B10DB24212A9143A8164249050@video>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
>> Also, it occurs to me that the page in question is specific to Section
>> 8.3 transfers, will Section 8.4 transfers be included on this page or a
>> separate similar page created when they start occurring? In the case of
>> 8.4 transfers it might be useful to include the other RIR that is either
>> the source or recipient of the inter-RIR transfer as well as the prefix
>> involved in the transfer.
They've started.
http://www.apnic.net/publications/news/2012/apnic-processes-first-inter-rir-ipv4-transfer-from-arin
Regards,
Mike Burns
------------------------------
Message: 6
Date: Thu, 18 Oct 2012 22:56:51 -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:
<cal9jlayek9-htaft7zwed0doypkrto+5tsfwv7jotqi69fs...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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
> -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.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 88, Issue 16
*****************************************
