From narten at us.ibm.com  Fri Nov  1 07:27:03 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 01 Nov 2013 07:27:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201311011127.rA1BR3Ej027359@rotala.raleigh.ibm.com>

Total of 3 messages in the last 7 days.
 
script run at: Fri Nov  1 07:27:03 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 67.19% |    29329 | gdendy at equinix.com
 33.33% |    1 | 18.07% |     7888 | info at arin.net
 33.33% |    1 | 14.74% |     6433 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    43650 | Total



From narten at us.ibm.com  Fri Nov  8 01:41:38 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 08 Nov 2013 01:41:38 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201311080641.rA86fc5I006116@rotala.raleigh.ibm.com>

Total of 1 messages in the last 7 days.
 
script run at: Fri Nov  8 01:41:37 EST 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     6170 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     6170 | Total



From amekkaoui at mektel.ca  Mon Nov 11 14:52:01 2013
From: amekkaoui at mektel.ca (A Mekkaoui)
Date: Mon, 11 Nov 2013 14:52:01 -0500
Subject: [arin-ppml] Carriers @ 625 RL
Message-ID: <002101cedf17$7e593360$7b0b9a20$@ca>

Hi, anybody knows about carrier company which provides IP transit and has
routers located at 625 Rene Levesque, Montreal, Canada. Thanks for your
help.

 

AM

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131111/5d605a5c/attachment.htm>

From narten at us.ibm.com  Fri Nov 15 07:05:33 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 15 Nov 2013 07:05:33 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201311151205.rAFC5XDm019377@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri Nov 15 07:05:33 EST 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 56.72% |     7910 | amekkaoui at mektel.ca
 50.00% |    1 | 43.28% |     6035 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    13945 | Total



From hannigan at gmail.com  Fri Nov 15 08:44:44 2013
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 15 Nov 2013 08:44:44 -0500
Subject: [arin-ppml] Carriers @ 625 RL
In-Reply-To: <002101cedf17$7e593360$7b0b9a20$@ca>
References: <002101cedf17$7e593360$7b0b9a20$@ca>
Message-ID: <CAMDXq5Mk1WtjSc-9Jh_vneuwhuDMscXG8GmmADx3Zizge=WdeA@mail.gmail.com>

That's a Cologix facility. You should check peeringdb.com for a view of who
might be at 625, who might be peering there or what facilities may be in
the region. Probably not a good question for this list.


Best,

-M<




On Mon, Nov 11, 2013 at 2:52 PM, A Mekkaoui <amekkaoui at mektel.ca> wrote:

> Hi, anybody knows about carrier company which provides IP transit and has
> routers located at 625 Rene Levesque, Montreal, Canada. Thanks for your
> help.
>
>
>
> AM
>
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131115/1b5d83a1/attachment.htm>

From scottleibrand at gmail.com  Thu Nov 21 18:03:32 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 21 Nov 2013 15:03:32 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
Message-ID: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>

During the discussion in Phoenix of Draft Policy 2013-7 (which I've since
updated and will be sending back out to PPML shortly), and in other
discussions before and since, it has become apparent that small networks
may not qualify for transfers and be unable to get space from their
upstreams after RIR and ISP IPv4 free pools run out.

In order to address this issue, a few different ideas have come up, so I
wanted to bring some of them up to the community for discussion and see
which possible solutions might have community support.

Here are a couple of the ideas that've come up so far:


1) For smaller allocations than ARIN?s minimum, orgs ?should request space
from their upstream provider _*or another LIR*_? (add underlined text to NRPM
4.2.1.5 <https://www.arin.net/policy/nrpm.html#four215>).

This would clarify that it's fine for organizations to get space reassigned
to them by any other LIR if their upstream ISPs are no longer able to
provide them the space they need.


2) Lower the minimum allocation sizes to /22 single-homed and /24
multihomed for both ISPs and end-users.  This would mean updating NRPM
4.2.2<https://www.arin.net/policy/nrpm.html#four22> and
4.3.2 <https://www.arin.net/policy/nrpm.html#four32> (and would allow
removal of NRPM 4.9 <https://www.arin.net/policy/nrpm.html#four9> as
redundant.)

Before the implementation of CIDR, many /24 allocations were made to
organizations that are no longer using them.  Current ARIN transfer policy
<https://www.arin.net/policy/nrpm.html#eight3>states that the minimum
transfer size is a /24, but it's not clear in policy whether an
single-homed organization that needs a small block (/24 to /21) would
actually qualify to receive such a block via transfer.  (Perhaps staff
input here would be useful.)  In any event, reducing the minimum allocation
sizes would allow organizations of all types to receive the size of address
block they actually need, either via transfer or from ARIN's inventory of
returned space.

Thoughts?  Do you support either or both of these ideas?  Would one or both
of them be worth submitting as a policy proposal?

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131121/9375a1c3/attachment.htm>

From csquat at ccsd.net  Thu Nov 21 18:06:29 2013
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Thu, 21 Nov 2013 15:06:29 -0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 101, Issue 1
Message-ID: <fc.004c4e0749cd9ab33b9aca005d305311.49cd9abe@interact.ccsd.net>

I am out of the office today.  Please contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131121/d0e531e4/attachment.htm>

From owen at delong.com  Thu Nov 21 19:48:09 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 21 Nov 2013 16:48:09 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
Message-ID: <77D5D3CD-D6FF-4826-A79B-D0BCD42164BD@delong.com>

I like option 2 a WHOLE LOT more than option 1.

I dislike intensely the idea of suggesting that people get space from people that are not providing network access services to them.

For such events, I believe a transfer should be used instead of reassignments/reallocations of PA space to non subscribers.

I would also support allowing ARIN to issue down to /24 to single-homed organizations that can document their inability to get space from their upstream provider. In such a case, I would support ARIN issuing down to a /24 even if the size of the network does not justify a /24.

In other words, if you need a /28 and your provider is unable to issue a /28 to you, you could go to ARIN and get a /24 with documentation of those facts.

Owen

On Nov 21, 2013, at 3:03 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.
> 
> In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.
> 
> Here are a couple of the ideas that've come up so far:
> 
> 
> 1) For smaller allocations than ARIN?s minimum, orgs ?should request space from their upstream provider _or another LIR_? (add underlined text to NRPM 4.2.1.5).
> 
> This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.
> 
> 
> 2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users.  This would mean updating NRPM 4.2.2 and 4.3.2 (and would allow removal of NRPM 4.9 as redundant.)
> 
> Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them.  Current ARIN transfer policy states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer.  (Perhaps staff input here would be useful.)  In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.
> 
> Thoughts?  Do you support either or both of these ideas?  Would one or both of them be worth submitting as a policy proposal?
> 
> Thanks,
> Scott
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131121/207a431f/attachment.htm>

From jrhett at netconsonance.com  Fri Nov 22 02:15:13 2013
From: jrhett at netconsonance.com (Jo Rhett)
Date: Thu, 21 Nov 2013 23:15:13 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
Message-ID: <C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>

I'd like to see some actual documented issues with this. Almost everyone I know is sitting on large amounts of smaller blocks they can easily allocate to people. It's the larger (/21 or greater) blocks which are becoming scarce.

On Nov 21, 2013, at 3:03 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.
> 
> In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.
> 
> Here are a couple of the ideas that've come up so far:
> 
> 
> 1) For smaller allocations than ARIN?s minimum, orgs ?should request space from their upstream provider _or another LIR_? (add underlined text to NRPM 4.2.1.5).
> 
> This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.
> 
> 
> 2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users.  This would mean updating NRPM 4.2.2 and 4.3.2 (and would allow removal of NRPM 4.9 as redundant.)
> 
> Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them.  Current ARIN transfer policy states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer.  (Perhaps staff input here would be useful.)  In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.
> 
> Thoughts?  Do you support either or both of these ideas?  Would one or both of them be worth submitting as a policy proposal?
> 
> Thanks,
> Scott
> _______________________________________________
> 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.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131121/a085526d/attachment.htm>

From narten at us.ibm.com  Fri Nov 22 07:03:39 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 22 Nov 2013 07:03:39 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201311221203.rAMC3doT007763@rotala.raleigh.ibm.com>

Total of 5 messages in the last 7 days.
 
script run at: Fri Nov 22 07:03:39 EST 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    1 | 30.50% |    13480 | owen at delong.com
 20.00% |    1 | 23.13% |    10226 | scottleibrand at gmail.com
 20.00% |    1 | 18.71% |     8269 | hannigan at gmail.com
 20.00% |    1 | 13.91% |     6147 | narten at us.ibm.com
 20.00% |    1 | 13.76% |     6080 | csquat at ccsd.net
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    44202 | Total



From bross at pobox.com  Fri Nov 22 09:50:48 2013
From: bross at pobox.com (Brandon Ross)
Date: Fri, 22 Nov 2013 09:50:48 -0500 (EST)
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
Message-ID: <alpine.OSX.2.02.1311220949020.1809@brugal.local>

On Thu, 21 Nov 2013, Jo Rhett wrote:

> I'd like to see some actual documented issues with this. Almost everyone 
> I know is sitting on large amounts of smaller blocks they can easily 
> allocate to people. It's the larger (/21 or greater) blocks which are 
> becoming scarce.

What kind of documentation are you looking for?

As I've mentioned in previous debates about small providers in the past, I 
have several of them as customers that very likely will have this problem 
when the free pool is exhausted.  Their upstream providers tend to also be 
small service providers without any reserve address space.  Many of them 
struggle to justify a /24 or /23.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross


From csquat at ccsd.net  Fri Nov 22 10:49:44 2013
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Fri, 22 Nov 2013 07:49:44 -0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 101, Issue 2
Message-ID: <fc.004c4e0749d256f73b9aca0013d54d88.49d256f9@interact.ccsd.net>

I am out of the office today.  Please contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/9dc35f17/attachment.htm>

From farmer at umn.edu  Fri Nov 22 14:25:51 2013
From: farmer at umn.edu (David Farmer)
Date: Fri, 22 Nov 2013 13:25:51 -0600
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <alpine.OSX.2.02.1311220949020.1809@brugal.local>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
Message-ID: <528FAFBF.606@umn.edu>

On 11/22/13, 08:50 , Brandon Ross wrote:
> On Thu, 21 Nov 2013, Jo Rhett wrote:
>
>> I'd like to see some actual documented issues with this. Almost
>> everyone I know is sitting on large amounts of smaller blocks they can
>> easily allocate to people. It's the larger (/21 or greater) blocks
>> which are becoming scarce.
>
> What kind of documentation are you looking for?

I would think an a copy of an email or a letter from the upstream which 
confirms the upstream can't/won't provide them address space, for some 
reason other than they don't think the customer justifies additional 
address space.

It is unfair for ARIN to withhold address space because the upstream has 
address space but won't provide it to the requester for what ever 
reason.  I think it is reasonable to require some confirming 
documentation that the upstream is not providing address space.  You 
can't just "say" your ISP is not providing it.

However, if an ISP is saying you don't justify additional address space, 
then you shouldn't qualify for address space from ARIN under an 
exception like this.

Also, ARIN should be able to refuse if they feel there is collusion 
between an ISP and a requester.

Thanks.
-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From owen at delong.com  Fri Nov 22 15:06:23 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 22 Nov 2013 12:06:23 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <528FAFBF.606@umn.edu>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
Message-ID: <B285911B-AFFB-4613-A41E-196E1406944C@delong.com>


On Nov 22, 2013, at 11:25 AM, David Farmer <farmer at umn.edu> wrote:

> On 11/22/13, 08:50 , Brandon Ross wrote:
>> On Thu, 21 Nov 2013, Jo Rhett wrote:
>> 
>>> I'd like to see some actual documented issues with this. Almost
>>> everyone I know is sitting on large amounts of smaller blocks they can
>>> easily allocate to people. It's the larger (/21 or greater) blocks
>>> which are becoming scarce.
>> 
>> What kind of documentation are you looking for?
> 
> I would think an a copy of an email or a letter from the upstream which confirms the upstream can't/won?t provide them address space, for some reason other than they don't think the customer justifies additional address space.
> 

David, I think that would be fine documentation to submit to ARIN under my proposal, but I don?t think it addresses what Jo was asking for.

I believe Jo is asking to see documentation that this is an actual problem that needs solving.

> It is unfair for ARIN to withhold address space because the upstream has address space but won't provide it to the requester for what ever reason.  I think it is reasonable to require some confirming documentation that the upstream is not providing address space.  You can't just "say" your ISP is not providing it.
> 
> However, if an ISP is saying you don?t justify additional address space, then you shouldn?t qualify for address space from ARIN under an exception like this.
> 

Agreed?

> Also, ARIN should be able to refuse if they feel there is collusion between an ISP and a requester.

This is trickier. incorporating how ARIN feels into policy is an interesting concept. Not one I am particularly comfortable with, and, in my experience, neither is ARIN staff.

I will, however, say that the collusion I think you are talking about would basically qualify as fraud and that I believe there is already sufficient policy to deal with situations where ARIN staff suspects that a request is fraudulent.

Owen



From kevinb at thewire.ca  Fri Nov 22 17:25:55 2013
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Fri, 22 Nov 2013 22:25:55 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <528FAFBF.606@umn.edu>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
Message-ID: <7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>

David,

There are going to be lots of reasons why an ISP can't provide space to a downstream post run out, even when on paper they have space.

1) Space dedicated to another region
2) Cost Prohibitive for downstream due to cost recovery.
3) Forward looking project that fits within the 24 month window.

I can see the conversation now. 

Downstream: I need a /24 of IP space
Upstream: NO
Downstream: Ok, I'm telling on you.
Upstream: We didn't sign the contract, find someone else to provide service.

In a primary market there are going to be "others". In a secondary market you will be out of luck.

We can't wrap this policy in a complicated beat stick. If a company has a need for an initial allocation
They are going to have to go to the transfer market. We should be able to give them the initial allocation without adding complexity.

Thanks,

Kevin
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
Sent: Friday, November 22, 2013 2:26 PM
To: Brandon Ross; Jo Rhett
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

On 11/22/13, 08:50 , Brandon Ross wrote:
> On Thu, 21 Nov 2013, Jo Rhett wrote:
>
>> I'd like to see some actual documented issues with this. Almost 
>> everyone I know is sitting on large amounts of smaller blocks they 
>> can easily allocate to people. It's the larger (/21 or greater) 
>> blocks which are becoming scarce.
>
> What kind of documentation are you looking for?

I would think an a copy of an email or a letter from the upstream which confirms the upstream can't/won't provide them address space, for some reason other than they don't think the customer justifies additional address space.

It is unfair for ARIN to withhold address space because the upstream has address space but won't provide it to the requester for what ever reason.  I think it is reasonable to require some confirming documentation that the upstream is not providing address space.  You can't just "say" your ISP is not providing it.

However, if an ISP is saying you don't justify additional address space, then you shouldn't qualify for address space from ARIN under an exception like this.

Also, ARIN should be able to refuse if they feel there is collusion between an ISP and a requester.

Thanks.
--
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================
_______________________________________________
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.


From cja at daydream.com  Fri Nov 22 17:32:11 2013
From: cja at daydream.com (CJ Aronson)
Date: Fri, 22 Nov 2013 15:32:11 -0700
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
Message-ID: <CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>

This is why RIPE and APNIC both have their last /8 policy.  Anyone can get
a /22 once out of the last /8 (til there are no more).  Both are now
signing up tons of new customers.   Both are generating a large amount of
revenue.   The small guys can all get their /22.  Just sayin'

-----Cathy


On Fri, Nov 22, 2013 at 3:25 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> David,
>
> There are going to be lots of reasons why an ISP can't provide space to a
> downstream post run out, even when on paper they have space.
>
> 1) Space dedicated to another region
> 2) Cost Prohibitive for downstream due to cost recovery.
> 3) Forward looking project that fits within the 24 month window.
>
> I can see the conversation now.
>
> Downstream: I need a /24 of IP space
> Upstream: NO
> Downstream: Ok, I'm telling on you.
> Upstream: We didn't sign the contract, find someone else to provide
> service.
>
> In a primary market there are going to be "others". In a secondary market
> you will be out of luck.
>
> We can't wrap this policy in a complicated beat stick. If a company has a
> need for an initial allocation
> They are going to have to go to the transfer market. We should be able to
> give them the initial allocation without adding complexity.
>
> Thanks,
>
> Kevin
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Friday, November 22, 2013 2:26 PM
> To: Brandon Ross; Jo Rhett
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> On 11/22/13, 08:50 , Brandon Ross wrote:
> > On Thu, 21 Nov 2013, Jo Rhett wrote:
> >
> >> I'd like to see some actual documented issues with this. Almost
> >> everyone I know is sitting on large amounts of smaller blocks they
> >> can easily allocate to people. It's the larger (/21 or greater)
> >> blocks which are becoming scarce.
> >
> > What kind of documentation are you looking for?
>
> I would think an a copy of an email or a letter from the upstream which
> confirms the upstream can't/won't provide them address space, for some
> reason other than they don't think the customer justifies additional
> address space.
>
> It is unfair for ARIN to withhold address space because the upstream has
> address space but won't provide it to the requester for what ever reason.
>  I think it is reasonable to require some confirming documentation that the
> upstream is not providing address space.  You can't just "say" your ISP is
> not providing it.
>
> However, if an ISP is saying you don't justify additional address space,
> then you shouldn't qualify for address space from ARIN under an exception
> like this.
>
> Also, ARIN should be able to refuse if they feel there is collusion
> between an ISP and a requester.
>
> Thanks.
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952================================================
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/6d162923/attachment.htm>

From rcarpen at network1.net  Fri Nov 22 17:40:36 2013
From: rcarpen at network1.net (Randy Carpenter)
Date: Fri, 22 Nov 2013 17:40:36 -0500 (EST)
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
Message-ID: <674736349.148507.1385160036022.JavaMail.zimbra@network1.net>


I have several single-homed clients who are in the position of having a /23 or /22 from an upstream, and needing additional space. They are refused.

They have a justified need, and are established networks, but ARIN policy prevents them from getting their own space because they don't already have a /20. At this point in the game the requirement of having space before you can get space seems a little ridiculous, particularly at the current minimums. If they were able to get their own space, they could hand back most or all of the upstream space, thus providing a benefit to them as well.

I am very in favor of moving the minimums to /22 for single-homed at least. I would also be in favor of only requiring an upstream allocation of a /24, so long as the ISP can show justified need for a full /22.

For multi-homed, I would be fine with either /23 or /24.


thanks,
-Randy

----- Original Message -----
> David,
> 
> There are going to be lots of reasons why an ISP can't provide space to a
> downstream post run out, even when on paper they have space.
> 
> 1) Space dedicated to another region
> 2) Cost Prohibitive for downstream due to cost recovery.
> 3) Forward looking project that fits within the 24 month window.
> 
> I can see the conversation now.
> 
> Downstream: I need a /24 of IP space
> Upstream: NO
> Downstream: Ok, I'm telling on you.
> Upstream: We didn't sign the contract, find someone else to provide service.
> 
> In a primary market there are going to be "others". In a secondary market you
> will be out of luck.
> 
> We can't wrap this policy in a complicated beat stick. If a company has a
> need for an initial allocation
> They are going to have to go to the transfer market. We should be able to
> give them the initial allocation without adding complexity.
> 
> Thanks,
> 
> Kevin
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Friday, November 22, 2013 2:26 PM
> To: Brandon Ross; Jo Rhett
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
> 
> On 11/22/13, 08:50 , Brandon Ross wrote:
> > On Thu, 21 Nov 2013, Jo Rhett wrote:
> >
> >> I'd like to see some actual documented issues with this. Almost
> >> everyone I know is sitting on large amounts of smaller blocks they
> >> can easily allocate to people. It's the larger (/21 or greater)
> >> blocks which are becoming scarce.
> >
> > What kind of documentation are you looking for?
> 
> I would think an a copy of an email or a letter from the upstream which
> confirms the upstream can't/won't provide them address space, for some
> reason other than they don't think the customer justifies additional address
> space.
> 
> It is unfair for ARIN to withhold address space because the upstream has
> address space but won't provide it to the requester for what ever reason.  I
> think it is reasonable to require some confirming documentation that the
> upstream is not providing address space.  You can't just "say" your ISP is
> not providing it.
> 
> However, if an ISP is saying you don't justify additional address space, then
> you shouldn't qualify for address space from ARIN under an exception like
> this.
> 
> Also, ARIN should be able to refuse if they feel there is collusion between
> an ISP and a requester.
> 
> Thanks.
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> 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.
> 
> 


From farmer at umn.edu  Fri Nov 22 19:11:24 2013
From: farmer at umn.edu (David Farmer)
Date: Fri, 22 Nov 2013 18:11:24 -0600
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <B285911B-AFFB-4613-A41E-196E1406944C@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<B285911B-AFFB-4613-A41E-196E1406944C@delong.com>
Message-ID: <528FF2AC.7030802@umn.edu>

On 11/22/13, 14:06 , Owen DeLong wrote:
>
> On Nov 22, 2013, at 11:25 AM, David Farmer <farmer at umn.edu> wrote:
>
>> On 11/22/13, 08:50 , Brandon Ross wrote:
>>> On Thu, 21 Nov 2013, Jo Rhett wrote:
>>>
>>>> I'd like to see some actual documented issues with this. Almost
>>>> everyone I know is sitting on large amounts of smaller blocks they can
>>>> easily allocate to people. It's the larger (/21 or greater) blocks
>>>> which are becoming scarce.
>>>
>>> What kind of documentation are you looking for?
>>
>> I would think an a copy of an email or a letter from the upstream which confirms the upstream can't/won?t provide them address space, for some reason other than they don't think the customer justifies additional address space.
>>
>
> David, I think that would be fine documentation to submit to ARIN under my proposal, but I don?t think it addresses what Jo was asking for.
>
> I believe Jo is asking to see documentation that this is an actual problem that needs solving.

Ok, rereading that a couple more times, I see what you are saying.

So, this isn't a problem, just yet, therefore there really aren't any 
documented cases.  However, it will be a problem when the free pool runs 
out, and telling people to wait a full policy cycle after the free pool 
is gone, will be unacceptable.  Looking at Geoff Huston's cumulative 
probability graph I'd say we have at most two policy cycles to deal with 
this before the issue is on top of us, and two isn't a very safe bet.

http://www.potaroo.net/tools/ipv4/plotvarcum.png

>> It is unfair for ARIN to withhold address space because the upstream has address space but won't provide it to the requester for what ever reason.  I think it is reasonable to require some confirming documentation that the upstream is not providing address space.  You can't just "say" your ISP is not providing it.
>>
>> However, if an ISP is saying you don?t justify additional address space, then you shouldn?t qualify for address space from ARIN under an exception like this.
>>
>
> Agreed?
>
>> Also, ARIN should be able to refuse if they feel there is collusion between an ISP and a requester.
>
> This is trickier. incorporating how ARIN feels into policy is an interesting concept. Not one I am particularly comfortable with, and, in my experience, neither is ARIN staff.
>
> I will, however, say that the collusion I think you are talking about would basically qualify as fraud and that I believe there is already sufficient policy to deal with situations where ARIN staff suspects that a request is fraudulent.

I wasn't suggesting that as policy language.  But, I think you are 
probably right it is fraud, and ARIN has tools for that.  I think we 
just need to make sure ARIN has the right tools for that kind of fraud.

Thanks
-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From scottleibrand at gmail.com  Fri Nov 22 19:44:43 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 22 Nov 2013 16:44:43 -0800
Subject: [arin-ppml] Fwd: Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
Message-ID: <CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>

Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback
y'all have provided so far (thanks!).  I've also attached the original
text, new text, and diff if you want to see exactly what I I'm suggesting
we change.

Thoughts?

Thanks,
Scott

*4.2.2. Initial allocation to ISPs*
4.2.2.1. General requirements

In order to receive an initial allocation from ARIN, organizations must:
4.2.2.1.1. Demonstrate use of existing space

Demonstrate the efficient utilization of existing IPv4 block(s) from an
upstream ISP that total at least half the size of the block being
requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4
space from an upstream ISP, it can instead receive a /24 or larger via 8.3
transfer to the extent it can demonstrate an immediate need for the space.
4.2.2.1.2. Demonstrate efficient utilization

Demonstrate efficient use of IPv4 address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWhois server for /29 or larger
blocks. For blocks smaller than /29 and for internal space, ISPs should
provide utilization data either via SWIP or RWhois server or by providing
detailed utilization information.
4.2.2.1.3. Utilize requested space within three months

Provide detailed information showing specifically how the requested IPv4
space will be utilized within three months.
4.2.2.1.4. Renumber and return

ISPs receiving IP space from ARIN should renumber out of their previously
allocated space if possible. If able to do so, an ISP should use the new
IPv4 block to renumber out of that previously allocated block of address
space and must return the space to its upstream provider.
4.2.2.2. Initial allocation sizes 4.2.2.2.1 Single-homed

Single-homed organizations meeting the requirements listed above may
request an initial allocation from ARIN between /20 and /22 in size.
4.2.2.2.2 Multi-homed

Multi-homed organizations meeting the requirements listed above and
demonstrating an intent to announce the requested space in a multihomed
fashion may request an initial allocation from ARIN between /20 and /24 in
size.





*4.3.1. End-users*

ARIN assigns blocks of IP addresses to end-users who request address space
for their internal use in running their own networks, but not for
sub-delegation of those addresses outside their organization. End-users
must meet the requirements described in these guidelines for justifying the
assignment of an address block.

*4.3.2. Minimum assignment*
4.3.2.1 Single Connection

The minimum block of IP address space assigned by ARIN to end-users is a
/22. If assignments smaller than /22 are needed, end-users should contact
their upstream provider.  If the end-user demonstrates that it cannot
obtain sufficient IPv4 space from an upstream ISP, it can instead receive a
/24 or larger via 8.3 transfer to the extent it can demonstrate an
immediate need for the space.
4.3.2.2 Multihomed Connection

For multihomed end-users who demonstrate an intent to announce the
requested space in a multihomed fashion to two or more distinct ASNs not
owned or controlled by the end-user, the minimum block of IP address space
assigned is a /24. If assignments smaller than a /24 are needed, multihomed
end-users should contact their upstream providers. When prefixes are
assigned which are smaller than /22, they will be from a block reserved for
that purpose so long as that is feasible.
4.3.3. Utilization rate

Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how previous
address assignments have been utilized and must provide appropriate details
to verify their one-year growth projection. The basic criteria that must be
met are:

   - A 25% immediate utilization rate, and
   - A 50% utilization rate within one year.

A greater utilization rate may be required based on individual network
requirements.



---------- Forwarded message ----------
From: Scott Leibrand <scottleibrand at gmail.com>
Date: Thu, Nov 21, 2013 at 3:03 PM
Subject: Bootstrapping new entrants after IPv4 exhaustion
To: ARIN-PPML List <arin-ppml at arin.net>


During the discussion in Phoenix of Draft Policy 2013-7 (which I've since
updated and will be sending back out to PPML shortly), and in other
discussions before and since, it has become apparent that small networks
may not qualify for transfers and be unable to get space from their
upstreams after RIR and ISP IPv4 free pools run out.

In order to address this issue, a few different ideas have come up, so I
wanted to bring some of them up to the community for discussion and see
which possible solutions might have community support.

Here are a couple of the ideas that've come up so far:


1) For smaller allocations than ARIN?s minimum, orgs ?should request space
from their upstream provider _*or another LIR*_? (add underlined text to NRPM
4.2.1.5 <https://www.arin.net/policy/nrpm.html#four215>).

This would clarify that it's fine for organizations to get space reassigned
to them by any other LIR if their upstream ISPs are no longer able to
provide them the space they need.


2) Lower the minimum allocation sizes to /22 single-homed and /24
multihomed for both ISPs and end-users.  This would mean updating NRPM
4.2.2<https://www.arin.net/policy/nrpm.html#four22> and
4.3.2 <https://www.arin.net/policy/nrpm.html#four32> (and would allow
removal of NRPM 4.9 <https://www.arin.net/policy/nrpm.html#four9> as
redundant.)

Before the implementation of CIDR, many /24 allocations were made to
organizations that are no longer using them.  Current ARIN transfer policy
<https://www.arin.net/policy/nrpm.html#eight3>states that the minimum
transfer size is a /24, but it's not clear in policy whether an
single-homed organization that needs a small block (/24 to /21) would
actually qualify to receive such a block via transfer.  (Perhaps staff
input here would be useful.)  In any event, reducing the minimum allocation
sizes would allow organizations of all types to receive the size of address
block they actually need, either via transfer or from ARIN's inventory of
returned space.

Thoughts?  Do you support either or both of these ideas?  Would one or both
of them be worth submitting as a policy proposal?

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/9279a5fc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bootstrapping new entrants redline diff.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 24342 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/9279a5fc/attachment.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bootstrapping new entrants original NRPM text for diff.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17928 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/9279a5fc/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bootstrapping new entrants.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 18088 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/9279a5fc/attachment-0002.docx>

From scottleibrand at gmail.com  Fri Nov 22 20:05:25 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 22 Nov 2013 17:05:25 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
Message-ID: <CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>

I suppose I should provide some explanation for my various changes, too:

To address Randy's point that "the requirement of having space before you
can get space seems a little ridiculous", I updated the requirement for
single-homed ISPs to efficiently utilize space from upstream(s) that "total
at least half the size of the block being requested", which is in line what
we already require from multihomed ISPs.

Per the original suggestion that most people seem to like, I changed the
minimum allocation sizes to /22 for single-homed and /24 for multihomed
orgs (both ISPs and end-users).

To address Owen's point about "allowing ARIN to issue down to /24 to
single-homed organizations that can document their inability to get space
from their upstream provider", I also included language that "If the [org]
demonstrates that it cannot obtain sufficient IPv4 space from an upstream
ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent
it can demonstrate an immediate need for the space."  I didn't go quite as
far as Owen suggested in allowing orgs that only need a /28 to get a /24 if
they can't get the /28 from their upstream.

I consolidated the single-homed and multi-homed ISP requirements into a
single set (differing only in minimum allocation size), and threaded the
needle on the multihomed "Renumber and return" requirement by making it a
"should" in both cases.

I struck the reference to the now-deprecated RFC 2050.  IMO if there are
any requirements from it we still want enforced, we should put them in
policy.

Feedback appreciated: thanks in advance!

-Scott


On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback
> y'all have provided so far (thanks!).  I've also attached the original
> text, new text, and diff if you want to see exactly what I I'm suggesting
> we change.
>
> Thoughts?
>
> Thanks,
> Scott
>
> *4.2.2. Initial allocation to ISPs*
> 4.2.2.1. General requirements
>
> In order to receive an initial allocation from ARIN, organizations must:
> 4.2.2.1.1. Demonstrate use of existing space
>
> Demonstrate the efficient utilization of existing IPv4 block(s) from an
> upstream ISP that total at least half the size of the block being
> requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4
> space from an upstream ISP, it can instead receive a /24 or larger via 8.3
> transfer to the extent it can demonstrate an immediate need for the space.
> 4.2.2.1.2. Demonstrate efficient utilization
>
> Demonstrate efficient use of IPv4 address space allocations by providing
> appropriate documentation, including assignment histories, showing their
> efficient use. ISPs must provide reassignment information on the entire
> previously allocated block(s) via SWIP or RWhois server for /29 or larger
> blocks. For blocks smaller than /29 and for internal space, ISPs should
> provide utilization data either via SWIP or RWhois server or by providing
> detailed utilization information.
> 4.2.2.1.3. Utilize requested space within three months
>
> Provide detailed information showing specifically how the requested IPv4
> space will be utilized within three months.
> 4.2.2.1.4. Renumber and return
>
> ISPs receiving IP space from ARIN should renumber out of their previously
> allocated space if possible. If able to do so, an ISP should use the new
> IPv4 block to renumber out of that previously allocated block of address
> space and must return the space to its upstream provider.
> 4.2.2.2. Initial allocation sizes 4.2.2.2.1 Single-homed
>
> Single-homed organizations meeting the requirements listed above may
> request an initial allocation from ARIN between /20 and /22 in size.
> 4.2.2.2.2 Multi-homed
>
> Multi-homed organizations meeting the requirements listed above and
> demonstrating an intent to announce the requested space in a multihomed
> fashion may request an initial allocation from ARIN between /20 and /24 in
> size.
>
>
>
>
>
>  *4.3.1. End-users*
>
> ARIN assigns blocks of IP addresses to end-users who request address space
> for their internal use in running their own networks, but not for
> sub-delegation of those addresses outside their organization. End-users
> must meet the requirements described in these guidelines for justifying the
> assignment of an address block.
>
> *4.3.2. Minimum assignment*
> 4.3.2.1 Single Connection
>
> The minimum block of IP address space assigned by ARIN to end-users is a
> /22. If assignments smaller than /22 are needed, end-users should contact
> their upstream provider.  If the end-user demonstrates that it cannot
> obtain sufficient IPv4 space from an upstream ISP, it can instead receive a
> /24 or larger via 8.3 transfer to the extent it can demonstrate an
> immediate need for the space.
> 4.3.2.2 Multihomed Connection
>
> For multihomed end-users who demonstrate an intent to announce the
> requested space in a multihomed fashion to two or more distinct ASNs not
> owned or controlled by the end-user, the minimum block of IP address space
> assigned is a /24. If assignments smaller than a /24 are needed, multihomed
> end-users should contact their upstream providers. When prefixes are
> assigned which are smaller than /22, they will be from a block reserved for
> that purpose so long as that is feasible.
> 4.3.3. Utilization rate
>
> Utilization rate of address space is a key factor in justifying a new
> assignment of IP address space. Requesters must show exactly how previous
> address assignments have been utilized and must provide appropriate details
> to verify their one-year growth projection. The basic criteria that must be
> met are:
>
>    - A 25% immediate utilization rate, and
>    - A 50% utilization rate within one year.
>
> A greater utilization rate may be required based on individual network
> requirements.
>
>
>
> ---------- Forwarded message ----------
> From: Scott Leibrand <scottleibrand at gmail.com>
> Date: Thu, Nov 21, 2013 at 3:03 PM
> Subject: Bootstrapping new entrants after IPv4 exhaustion
> To: ARIN-PPML List <arin-ppml at arin.net>
>
>
> During the discussion in Phoenix of Draft Policy 2013-7 (which I've since
> updated and will be sending back out to PPML shortly), and in other
> discussions before and since, it has become apparent that small networks
> may not qualify for transfers and be unable to get space from their
> upstreams after RIR and ISP IPv4 free pools run out.
>
> In order to address this issue, a few different ideas have come up, so I
> wanted to bring some of them up to the community for discussion and see
> which possible solutions might have community support.
>
> Here are a couple of the ideas that've come up so far:
>
>
> 1) For smaller allocations than ARIN?s minimum, orgs ?should request space
> from their upstream provider _*or another LIR*_? (add underlined text to NRPM
> 4.2.1.5 <https://www.arin.net/policy/nrpm.html#four215>).
>
> This would clarify that it's fine for organizations to get space
> reassigned to them by any other LIR if their upstream ISPs are no longer
> able to provide them the space they need.
>
>
> 2) Lower the minimum allocation sizes to /22 single-homed and /24
> multihomed for both ISPs and end-users.  This would mean updating NRPM
> 4.2.2 <https://www.arin.net/policy/nrpm.html#four22> and 4.3.2<https://www.arin.net/policy/nrpm.html#four32> (and
> would allow removal of NRPM 4.9<https://www.arin.net/policy/nrpm.html#four9> as
> redundant.)
>
> Before the implementation of CIDR, many /24 allocations were made to
> organizations that are no longer using them.  Current ARIN transfer
> policy <https://www.arin.net/policy/nrpm.html#eight3>states that the
> minimum transfer size is a /24, but it's not clear in policy whether an
> single-homed organization that needs a small block (/24 to /21) would
> actually qualify to receive such a block via transfer.  (Perhaps staff
> input here would be useful.)  In any event, reducing the minimum allocation
> sizes would allow organizations of all types to receive the size of address
> block they actually need, either via transfer or from ARIN's inventory of
> returned space.
>
> Thoughts?  Do you support either or both of these ideas?  Would one or
> both of them be worth submitting as a policy proposal?
>
> Thanks,
> Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/5235fb7d/attachment.htm>

From owen at delong.com  Fri Nov 22 21:06:53 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 22 Nov 2013 18:06:53 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
Message-ID: <4B809C48-AFB6-41C0-923A-7A342ED90EE3@delong.com>


On Nov 22, 2013, at 5:05 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> I suppose I should provide some explanation for my various changes, too:
> 
> To address Randy's point that "the requirement of having space before you can get space seems a little ridiculous", I updated the requirement for single-homed ISPs to efficiently utilize space from upstream(s) that "total at least half the size of the block being requested", which is in line what we already require from multihomed ISPs.
> 
> Per the original suggestion that most people seem to like, I changed the minimum allocation sizes to /22 for single-homed and /24 for multihomed orgs (both ISPs and end-users).
> 
> To address Owen's point about "allowing ARIN to issue down to /24 to single-homed organizations that can document their inability to get space from their upstream provider", I also included language that "If the [org] demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space."  I didn't go quite as far as Owen suggested in allowing orgs that only need a /28 to get a /24 if they can't get the /28 from their upstream.
> 

Given that the minimum you can transfer is a /24, I really think that allowing anyone to get a minimum assignment through the transfer process is necessary.

> I consolidated the single-homed and multi-homed ISP requirements into a single set (differing only in minimum allocation size), and threaded the needle on the multihomed "Renumber and return" requirement by making it a "should" in both cases.
> 
> I struck the reference to the now-deprecated RFC 2050.  IMO if there are any requirements from it we still want enforced, we should put them in policy.

I believe that effort is underway in policy that was on the agenda for yesterdays AC call. I will refrain from prematurely publishing the outcome of that discussion here.

Owen

> 
> Feedback appreciated: thanks in advance!
> 
> -Scott
> 
> 
> On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback y'all have provided so far (thanks!).  I've also attached the original text, new text, and diff if you want to see exactly what I I'm suggesting we change.
> 
> Thoughts?
> 
> Thanks,
> Scott
> 
> 4.2.2. Initial allocation to ISPs
> 
> 4.2.2.1. General requirements
> 
> In order to receive an initial allocation from ARIN, organizations must:
> 
> 4.2.2.1.1. Demonstrate use of existing space
> 
> Demonstrate the efficient utilization of existing IPv4 block(s) from an upstream ISP that total at least half the size of the block being requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.
> 
> 4.2.2.1.2. Demonstrate efficient utilization
> 
> Demonstrate efficient use of IPv4 address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois server or by providing detailed utilization information.
> 
> 4.2.2.1.3. Utilize requested space within three months
> 
> Provide detailed information showing specifically how the requested IPv4 space will be utilized within three months.
> 
> 4.2.2.1.4. Renumber and return
> 
> ISPs receiving IP space from ARIN should renumber out of their previously allocated space if possible. If able to do so, an ISP should use the new IPv4 block to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
> 
> 4.2.2.2. Initial allocation sizes
> 
> 4.2.2.2.1 Single-homed
> 
> Single-homed organizations meeting the requirements listed above may request an initial allocation from ARIN between /20 and /22 in size. 
> 
> 4.2.2.2.2 Multi-homed
> 
> Multi-homed organizations meeting the requirements listed above and demonstrating an intent to announce the requested space in a multihomed fashion may request an initial allocation from ARIN between /20 and /24 in size.  
> 
> 
> 
> 
> 
> 
> 
> 
> 4.3.1. End-users
> 
> ARIN assigns blocks of IP addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation of those addresses outside their organization. End-users must meet the requirements described in these guidelines for justifying the assignment of an address block.
> 
> 4.3.2. Minimum assignment
> 
> 4.3.2.1 Single Connection
> 
> The minimum block of IP address space assigned by ARIN to end-users is a /22. If assignments smaller than /22 are needed, end-users should contact their upstream provider.  If the end-user demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.
> 
> 4.3.2.2 Multihomed Connection
> 
> For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are smaller than /22, they will be from a block reserved for that purpose so long as that is feasible.
> 
> 4.3.3. Utilization rate
> 
> Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are:
> 
> A 25% immediate utilization rate, and
> A 50% utilization rate within one year.
> A greater utilization rate may be required based on individual network requirements.
> 
>  
> 
> ---------- Forwarded message ----------
> From: Scott Leibrand <scottleibrand at gmail.com>
> Date: Thu, Nov 21, 2013 at 3:03 PM
> Subject: Bootstrapping new entrants after IPv4 exhaustion
> To: ARIN-PPML List <arin-ppml at arin.net>
> 
> 
> During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.
> 
> In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.
> 
> Here are a couple of the ideas that've come up so far:
> 
> 
> 1) For smaller allocations than ARIN?s minimum, orgs ?should request space from their upstream provider _or another LIR_? (add underlined text to NRPM 4.2.1.5).
> 
> This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.
> 
> 
> 2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users.  This would mean updating NRPM 4.2.2 and 4.3.2 (and would allow removal of NRPM 4.9 as redundant.)
> 
> Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them.  Current ARIN transfer policy states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer.  (Perhaps staff input here would be useful.)  In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.
> 
> Thoughts?  Do you support either or both of these ideas?  Would one or both of them be worth submitting as a policy proposal?
> 
> Thanks,
> Scott
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/67b376aa/attachment.htm>

From bjones at vt.edu  Fri Nov 22 15:41:11 2013
From: bjones at vt.edu (Brian Jones)
Date: Fri, 22 Nov 2013 15:41:11 -0500
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <B285911B-AFFB-4613-A41E-196E1406944C@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<B285911B-AFFB-4613-A41E-196E1406944C@delong.com>
Message-ID: <CANyqO+GD_CB5uEDrJib_=ytB5XuCAp3CD0ZUvtSuSd8yrdOCKw@mail.gmail.com>

See below:

--
Brian


On Fri, Nov 22, 2013 at 3:06 PM, Owen DeLong <owen at delong.com> wrote:

>
> On Nov 22, 2013, at 11:25 AM, David Farmer <farmer at umn.edu> wrote:
>
> > On 11/22/13, 08:50 , Brandon Ross wrote:
> >> On Thu, 21 Nov 2013, Jo Rhett wrote:
> >>
> >>> I'd like to see some actual documented issues with this. Almost
> >>> everyone I know is sitting on large amounts of smaller blocks they can
> >>> easily allocate to people. It's the larger (/21 or greater) blocks
> >>> which are becoming scarce.
> >>
> >> What kind of documentation are you looking for?
> >
> > I would think an a copy of an email or a letter from the upstream which
> confirms the upstream can't/won?t provide them address space, for some
> reason other than they don't think the customer justifies additional
> address space.
> >
>
> David, I think that would be fine documentation to submit to ARIN under my
> proposal, but I don?t think it addresses what Jo was asking for.
>
> I believe Jo is asking to see documentation that this is an actual problem
> that needs solving.
>
> > It is unfair for ARIN to withhold address space because the upstream has
> address space but won't provide it to the requester for what ever reason.
>  I think it is reasonable to require some confirming documentation that the
> upstream is not providing address space.  You can't just "say" your ISP is
> not providing it.
> >
> > However, if an ISP is saying you don?t justify additional address space,
> then you shouldn?t qualify for address space from ARIN under an exception
> like this.
> >
>
> Agreed?
>
> > Also, ARIN should be able to refuse if they feel there is collusion
> between an ISP and a requester.
>
> This is trickier. incorporating how ARIN feels into policy is an
> interesting concept. Not one I am particularly comfortable with, and, in my
> experience, neither is ARIN staff.
>
> I will, however, say that the collusion I think you are talking about
> would basically qualify as fraud and that I believe there is already
> sufficient policy to deal with situations where ARIN staff suspects that a
> request is fraudulent.
>

?I agree with Dave's points, but maybe "feel" is the wrong word. Could
possibly replace with "determine" but then you have to define what
determines collusion... I see what you mean. This is trickier.

--
Brian


>
> Owen
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131122/a6b05716/attachment.htm>

From joelja at bogus.com  Sat Nov 23 23:37:38 2013
From: joelja at bogus.com (joel jaeggli)
Date: Sat, 23 Nov 2013 20:37:38 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>	<alpine.OSX.2.02.1311220949020.1809@brugal.local>	<528FAFBF.606@umn.edu>	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>
Message-ID: <52918292.50808@bogus.com>

On 11/22/13, 2:32 PM, CJ Aronson wrote:
> This is why RIPE and APNIC both have their last /8 policy.  Anyone can
> get a /22 once out of the last /8 (til there are no more).  Both are now
> signing up tons of new customers.   Both are generating a large amount
> of revenue.   The small guys can all get their /22.  Just sayin'

Revenue generation is wierdly, not goal of RIR operation.

> -----Cathy
> 
> 
> On Fri, Nov 22, 2013 at 3:25 PM, Kevin Blumberg <kevinb at thewire.ca
> <mailto:kevinb at thewire.ca>> wrote:
> 
>     David,
> 
>     There are going to be lots of reasons why an ISP can't provide space
>     to a downstream post run out, even when on paper they have space.
> 
>     1) Space dedicated to another region
>     2) Cost Prohibitive for downstream due to cost recovery.
>     3) Forward looking project that fits within the 24 month window.
> 
>     I can see the conversation now.
> 
>     Downstream: I need a /24 of IP space
>     Upstream: NO
>     Downstream: Ok, I'm telling on you.
>     Upstream: We didn't sign the contract, find someone else to provide
>     service.
> 
>     In a primary market there are going to be "others". In a secondary
>     market you will be out of luck.
> 
>     We can't wrap this policy in a complicated beat stick. If a company
>     has a need for an initial allocation
>     They are going to have to go to the transfer market. We should be
>     able to give them the initial allocation without adding complexity.
> 
>     Thanks,
> 
>     Kevin
>     -----Original Message-----
>     From: arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>
>     [mailto:arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>] On Behalf Of David Farmer
>     Sent: Friday, November 22, 2013 2:26 PM
>     To: Brandon Ross; Jo Rhett
>     Cc: ARIN-PPML List
>     Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4
>     exhaustion
> 
>     On 11/22/13, 08:50 , Brandon Ross wrote:
>     > On Thu, 21 Nov 2013, Jo Rhett wrote:
>     >
>     >> I'd like to see some actual documented issues with this. Almost
>     >> everyone I know is sitting on large amounts of smaller blocks they
>     >> can easily allocate to people. It's the larger (/21 or greater)
>     >> blocks which are becoming scarce.
>     >
>     > What kind of documentation are you looking for?
> 
>     I would think an a copy of an email or a letter from the upstream
>     which confirms the upstream can't/won't provide them address space,
>     for some reason other than they don't think the customer justifies
>     additional address space.
> 
>     It is unfair for ARIN to withhold address space because the upstream
>     has address space but won't provide it to the requester for what
>     ever reason.  I think it is reasonable to require some confirming
>     documentation that the upstream is not providing address space.  You
>     can't just "say" your ISP is not providing it.
> 
>     However, if an ISP is saying you don't justify additional address
>     space, then you shouldn't qualify for address space from ARIN under
>     an exception like this.
> 
>     Also, ARIN should be able to refuse if they feel there is collusion
>     between an ISP and a requester.
> 
>     Thanks.
>     --
>     ================================================
>     David Farmer               Email: farmer at umn.edu <mailto:farmer at umn.edu>
>     Office of Information Technology
>     University of Minnesota
>     2218 University Ave SE     Phone: 1-612-626-0815 <tel:1-612-626-0815>
>     Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>     <tel:1-612-812-9952> ================================================
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to the
>     ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto: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 <mailto: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
>     <mailto: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 <mailto: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.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131123/d8d3cf68/attachment.sig>

From jcurran at arin.net  Sun Nov 24 05:51:25 2013
From: jcurran at arin.net (John Curran)
Date: Sun, 24 Nov 2013 10:51:25 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <52918292.50808@bogus.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>
	<52918292.50808@bogus.com>
Message-ID: <681B7192-5E98-43AF-A02D-6EA690BDEB3F@arin.net>

On Nov 23, 2013, at 11:37 PM, joel jaeggli <joelja at bogus.com> wrote:

> On 11/22/13, 2:32 PM, CJ Aronson wrote:
>> This is why RIPE and APNIC both have their last /8 policy.  Anyone can
>> get a /22 once out of the last /8 (til there are no more).  Both are now
>> signing up tons of new customers.   Both are generating a large amount
>> of revenue.   The small guys can all get their /22.  Just sayin'
> 
> Revenue generation is wierdly, not goal of RIR operation.

Agreed - ARIN's goal is cost-recovery and should not be policy driver.

Setting that aside, the last /8 policies in other regions do seem to reasonably 
address aspects of the "new entrant" problem as we hit runout.  It is up to the 
community in the ARIN region to determine whether this will be a problem at IPv4
runout in this region, and if so, how to best address the situation.

Thanks!
/John

John Curran
President and CEO
ARIN



From cja at daydream.com  Sun Nov 24 08:54:23 2013
From: cja at daydream.com (Cathy Aronson)
Date: Sun, 24 Nov 2013 06:54:23 -0700
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <52918292.50808@bogus.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>
	<52918292.50808@bogus.com>
Message-ID: <6F2DA037-2F90-449B-9E60-CEB52602C8B5@daydream.com>

Yup that's true about revenue generation but the other RIRs seem thrilled to have the new members and the "little guys" can still get that one final /22.

Cathy

Sent from a handheld device.

On Nov 23, 2013, at 9:37 PM, joel jaeggli <joelja at bogus.com> wrote:

> On 11/22/13, 2:32 PM, CJ Aronson wrote:
>> This is why RIPE and APNIC both have their last /8 policy.  Anyone can
>> get a /22 once out of the last /8 (til there are no more).  Both are now
>> signing up tons of new customers.   Both are generating a large amount
>> of revenue.   The small guys can all get their /22.  Just sayin'
> 
> Revenue generation is wierdly, not goal of RIR operation.
> 
>> -----Cathy
>> 
>> 
>> On Fri, Nov 22, 2013 at 3:25 PM, Kevin Blumberg <kevinb at thewire.ca
>> <mailto:kevinb at thewire.ca>> wrote:
>> 
>>    David,
>> 
>>    There are going to be lots of reasons why an ISP can't provide space
>>    to a downstream post run out, even when on paper they have space.
>> 
>>    1) Space dedicated to another region
>>    2) Cost Prohibitive for downstream due to cost recovery.
>>    3) Forward looking project that fits within the 24 month window.
>> 
>>    I can see the conversation now.
>> 
>>    Downstream: I need a /24 of IP space
>>    Upstream: NO
>>    Downstream: Ok, I'm telling on you.
>>    Upstream: We didn't sign the contract, find someone else to provide
>>    service.
>> 
>>    In a primary market there are going to be "others". In a secondary
>>    market you will be out of luck.
>> 
>>    We can't wrap this policy in a complicated beat stick. If a company
>>    has a need for an initial allocation
>>    They are going to have to go to the transfer market. We should be
>>    able to give them the initial allocation without adding complexity.
>> 
>>    Thanks,
>> 
>>    Kevin
>>    -----Original Message-----
>>    From: arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>
>>    [mailto:arin-ppml-bounces at arin.net
>>    <mailto:arin-ppml-bounces at arin.net>] On Behalf Of David Farmer
>>    Sent: Friday, November 22, 2013 2:26 PM
>>    To: Brandon Ross; Jo Rhett
>>    Cc: ARIN-PPML List
>>    Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4
>>    exhaustion
>> 
>>    On 11/22/13, 08:50 , Brandon Ross wrote:
>>> On Thu, 21 Nov 2013, Jo Rhett wrote:
>>> 
>>>> I'd like to see some actual documented issues with this. Almost
>>>> everyone I know is sitting on large amounts of smaller blocks they
>>>> can easily allocate to people. It's the larger (/21 or greater)
>>>> blocks which are becoming scarce.
>>> 
>>> What kind of documentation are you looking for?
>> 
>>    I would think an a copy of an email or a letter from the upstream
>>    which confirms the upstream can't/won't provide them address space,
>>    for some reason other than they don't think the customer justifies
>>    additional address space.
>> 
>>    It is unfair for ARIN to withhold address space because the upstream
>>    has address space but won't provide it to the requester for what
>>    ever reason.  I think it is reasonable to require some confirming
>>    documentation that the upstream is not providing address space.  You
>>    can't just "say" your ISP is not providing it.
>> 
>>    However, if an ISP is saying you don't justify additional address
>>    space, then you shouldn't qualify for address space from ARIN under
>>    an exception like this.
>> 
>>    Also, ARIN should be able to refuse if they feel there is collusion
>>    between an ISP and a requester.
>> 
>>    Thanks.
>>    --
>>    ================================================
>>    David Farmer               Email: farmer at umn.edu <mailto:farmer at umn.edu>
>>    Office of Information Technology
>>    University of Minnesota
>>    2218 University Ave SE     Phone: 1-612-626-0815 <tel:1-612-626-0815>
>>    Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>>    <tel:1-612-812-9952> ================================================
>>    _______________________________________________
>>    PPML
>>    You are receiving this message because you are subscribed to the
>>    ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>    <mailto: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 <mailto: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
>>    <mailto: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 <mailto: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.
> 
> 


From csquat at ccsd.net  Sun Nov 24 08:55:52 2013
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Sun, 24 Nov 2013 05:55:52 -0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 101, Issue 6
Message-ID: <fc.004c4e0749dc70d23b9aca0042056058.49dc70d3@interact.ccsd.net>

I am out of the office today.  Please contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/918598a6/attachment.htm>

From andrew.dul at quark.net  Sun Nov 24 16:52:58 2013
From: andrew.dul at quark.net (Andrew Dul)
Date: Sun, 24 Nov 2013 13:52:58 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
Message-ID: <5292753A.1060904@quark.net>

I believe we need to be thinking about a much simpler IPv4 policy after
run-out occurs.  Initial allocation/assignment criteria could be as
simple as, "Do you have 64 IP devices?" (e.g. 25% of a /24).  If answer
is yes, you are approved for a /24.  I'm suggesting the removal of
section 4.2.2.1.1 and loosening the language of 4.2.2.1.2. 

I'm also in favor of moving to a /24 minimum for ISPs and end-users.

Also, I'd also like to point out that the ARIN community set aside a /10
worth of small blocks (/24-/28) to be used for new entrants after
run-out occurs.  This block was intended to be used by new entrants
after run-out. 

https://www.arin.net/policy/nrpm.html#four10

The attached redline is Scott's version just formatted with revisions
inline, which was helpful to me in considering what Scott was proposing.

Andrew

On 11/22/2013 5:05 PM, Scott Leibrand wrote:
> I suppose I should provide some explanation for my various changes, too:
>
> To address Randy's point that "the requirement of having space before
> you can get space seems a little ridiculous", I updated the
> requirement for single-homed ISPs to efficiently utilize space from
> upstream(s) that "total at least half the size of the block being
> requested", which is in line what we already require from multihomed ISPs.
>
> Per the original suggestion that most people seem to like, I changed
> the minimum allocation sizes to /22 for single-homed and /24 for
> multihomed orgs (both ISPs and end-users).
>
> To address Owen's point about "allowing ARIN to issue down to /24 to
> single-homed organizations that can document their inability to get
> space from their upstream provider", I also included language that "If
> the [org] demonstrates that it cannot obtain sufficient IPv4 space
> from an upstream ISP, it can instead receive a /24 or larger via 8.3
> transfer to the extent it can demonstrate an immediate need for the
> space."  I didn't go quite as far as Owen suggested in allowing orgs
> that only need a /28 to get a /24 if they can't get the /28 from their
> upstream.
>
> I consolidated the single-homed and multi-homed ISP requirements into
> a single set (differing only in minimum allocation size), and threaded
> the needle on the multihomed "Renumber and return" requirement by
> making it a "should" in both cases.
>
> I struck the reference to the now-deprecated RFC 2050.  IMO if there
> are any requirements from it we still want enforced, we should put
> them in policy.
>
> Feedback appreciated: thanks in advance!
>
> -Scott
>
>
> On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand
> <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>> wrote:
>
>     Below is a first attempt at updating 4.2.2 and 4.3 based on the
>     feedback y'all have provided so far (thanks!).  I've also attached
>     the original text, new text, and diff if you want to see exactly
>     what I I'm suggesting we change.
>
>     Thoughts?
>
>     Thanks,
>     Scott
>
>     *4.2.2. Initial allocation to ISPs*
>
>
>                 4.2.2.1. General requirements
>
>     In order to receive an initial allocation from ARIN, organizations
>     must:
>
>
>                 4.2.2.1.1. Demonstrate use of existing space
>
>     Demonstrate the efficient utilization of existing IPv4 block(s)
>     from an upstream ISP that total at least half the size of the
>     block being requested.  If the ISP demonstrates that it cannot
>     obtain sufficient IPv4 space from an upstream ISP, it can instead
>     receive a /24 or larger via 8.3 transfer to the extent it can
>     demonstrate an immediate need for the space.
>
>
>                 4.2.2.1.2. Demonstrate efficient utilization
>
>     Demonstrate efficient use of IPv4 address space allocations by
>     providing appropriate documentation, including assignment
>     histories, showing their efficient use. ISPs must provide
>     reassignment information on the entire previously allocated
>     block(s) via SWIP or RWhois server for /29 or larger blocks. For
>     blocks smaller than /29 and for internal space, ISPs should
>     provide utilization data either via SWIP or RWhois server or by
>     providing detailed utilization information.
>
>
>                 4.2.2.1.3. Utilize requested space within three months
>
>     Provide detailed information showing specifically how the
>     requested IPv4 space will be utilized within three months.
>
>
>                 4.2.2.1.4. Renumber and return
>
>     ISPs receiving IP space from ARIN should renumber out of their
>     previously allocated space if possible. If able to do so, an ISP
>     should use the new IPv4 block to renumber out of that previously
>     allocated block of address space and must return the space to its
>     upstream provider.
>
>
>                 4.2.2.2. Initial allocation sizes
>
>
>                 4.2.2.2.1 Single-homed
>
>     Single-homed organizations meeting the requirements listed above
>     may request an initial allocation from ARIN between /20 and /22 in
>     size. 
>
>
>                 4.2.2.2.2 Multi-homed
>
>     Multi-homed organizations meeting the requirements listed above
>     and demonstrating an intent to announce the requested space in a
>     multihomed fashion may request an initial allocation from ARIN
>     between /20 and /24 in size. 
>
>     *
>     *
>
>     *
>     *
>
>     *
>     *
>
>     *
>     *
>
>     *4.3.1. End-users*
>
>     ARIN assigns blocks of IP addresses to end-users who request
>     address space for their internal use in running their own
>     networks, but not for sub-delegation of those addresses outside
>     their organization. End-users must meet the requirements described
>     in these guidelines for justifying the assignment of an address block.
>
>     *4.3.2. Minimum assignment*
>
>
>                 4.3.2.1 Single Connection
>
>     The minimum block of IP address space assigned by ARIN to
>     end-users is a /22. If assignments smaller than /22 are needed,
>     end-users should contact their upstream provider.  If the end-user
>     demonstrates that it cannot obtain sufficient IPv4 space from an
>     upstream ISP, it can instead receive a /24 or larger via 8.3
>     transfer to the extent it can demonstrate an immediate need for
>     the space.
>
>
>                 4.3.2.2 Multihomed Connection
>
>     For multihomed end-users who demonstrate an intent to announce the
>     requested space in a multihomed fashion to two or more distinct
>     ASNs not owned or controlled by the end-user, the minimum block of
>     IP address space assigned is a /24. If assignments smaller than a
>     /24 are needed, multihomed end-users should contact their upstream
>     providers. When prefixes are assigned which are smaller than /22,
>     they will be from a block reserved for that purpose so long as
>     that is feasible.
>
>
>                 4.3.3. Utilization rate
>
>     Utilization rate of address space is a key factor in justifying a
>     new assignment of IP address space. Requesters must show exactly
>     how previous address assignments have been utilized and must
>     provide appropriate details to verify their one-year growth
>     projection. The basic criteria that must be met are:
>
>       * A 25% immediate utilization rate, and
>       * A 50% utilization rate within one year.
>
>     A greater utilization rate may be required based on individual
>     network requirements.
>
>      
>
>
>     ---------- Forwarded message ----------
>     From: *Scott Leibrand* <scottleibrand at gmail.com
>     <mailto:scottleibrand at gmail.com>>
>     Date: Thu, Nov 21, 2013 at 3:03 PM
>     Subject: Bootstrapping new entrants after IPv4 exhaustion
>     To: ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
>
>
>     During the discussion in Phoenix of Draft Policy 2013-7 (which
>     I've since updated and will be sending back out to PPML shortly),
>     and in other discussions before and since, it has become apparent
>     that small networks may not qualify for transfers and be unable to
>     get space from their upstreams after RIR and ISP IPv4 free pools
>     run out.
>
>     In order to address this issue, a few different ideas have come
>     up, so I wanted to bring some of them up to the community for
>     discussion and see which possible solutions might have community
>     support.
>
>     Here are a couple of the ideas that've come up so far:
>
>
>     1) For smaller allocations than ARIN's minimum, orgs "should
>     request space from their upstream provider __or another LIR__"
>     (add underlined text to NRPM 4.2.1.5
>     <https://www.arin.net/policy/nrpm.html#four215>).
>
>     This would clarify that it's fine for organizations to get space
>     reassigned to them by any other LIR if their upstream ISPs are no
>     longer able to provide them the space they need.
>
>
>     2) Lower the minimum allocation sizes to /22 single-homed and /24
>     multihomed for both ISPs and end-users.  This would mean
>     updating NRPM 4.2.2
>     <https://www.arin.net/policy/nrpm.html#four22> and 4.3.2
>     <https://www.arin.net/policy/nrpm.html#four32> (and would allow
>     removal of NRPM 4.9
>     <https://www.arin.net/policy/nrpm.html#four9> as redundant.)
>
>     Before the implementation of CIDR, many /24 allocations were made
>     to organizations that are no longer using them.  Current ARIN
>     transfer policy
>     <https://www.arin.net/policy/nrpm.html#eight3>states that the
>     minimum transfer size is a /24, but it's not clear in policy
>     whether an single-homed organization that needs a small block (/24
>     to /21) would actually qualify to receive such a block via
>     transfer.  (Perhaps staff input here would be useful.)  In any
>     event, reducing the minimum allocation sizes would allow
>     organizations of all types to receive the size of address block
>     they actually need, either via transfer or from ARIN's inventory
>     of returned space.
>
>     Thoughts?  Do you support either or both of these ideas?  Would
>     one or both of them be worth submitting as a policy proposal?
>
>     Thanks,
>     Scott
>
>
>
>
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/dd2c8d75/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bootstrapping_new_entrants_redline_diff.pdf
Type: application/pdf
Size: 93289 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/dd2c8d75/attachment.pdf>

From owen at delong.com  Sun Nov 24 17:08:17 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 24 Nov 2013 14:08:17 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <5292753A.1060904@quark.net>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
Message-ID: <B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>


On Nov 24, 2013, at 1:52 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> I believe we need to be thinking about a much simpler IPv4 policy after run-out occurs.  Initial allocation/assignment criteria could be as simple as, "Do you have 64 IP devices?" (e.g. 25% of a /24).  If answer is yes, you are approved for a /24.  I'm suggesting the removal of section 4.2.2.1.1 and loosening the language of 4.2.2.1.2.  
> 
> I'm also in favor of moving to a /24 minimum for ISPs and end-users.
> 
> Also, I'd also like to point out that the ARIN community set aside a /10 worth of small blocks (/24-/28) to be used for new entrants after run-out occurs.  This block was intended to be used by new entrants after run-out.  
> 
> https://www.arin.net/policy/nrpm.html#four10
> 

Yes, but it limits that use to strictly transitional technology deployment, not general IPv4 utilization.

> The attached redline is Scott's version just formatted with revisions inline, which was helpful to me in considering what Scott was proposing.
> 

Thanks for the redline? These are very useful.

Owen

> Andrew
> 
> On 11/22/2013 5:05 PM, Scott Leibrand wrote:
>> I suppose I should provide some explanation for my various changes, too:
>> 
>> To address Randy's point that "the requirement of having space before you can get space seems a little ridiculous", I updated the requirement for single-homed ISPs to efficiently utilize space from upstream(s) that "total at least half the size of the block being requested", which is in line what we already require from multihomed ISPs.
>> 
>> Per the original suggestion that most people seem to like, I changed the minimum allocation sizes to /22 for single-homed and /24 for multihomed orgs (both ISPs and end-users).
>> 
>> To address Owen's point about "allowing ARIN to issue down to /24 to single-homed organizations that can document their inability to get space from their upstream provider", I also included language that "If the [org] demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space."  I didn't go quite as far as Owen suggested in allowing orgs that only need a /28 to get a /24 if they can't get the /28 from their upstream.
>> 
>> I consolidated the single-homed and multi-homed ISP requirements into a single set (differing only in minimum allocation size), and threaded the needle on the multihomed "Renumber and return" requirement by making it a "should" in both cases.
>> 
>> I struck the reference to the now-deprecated RFC 2050.  IMO if there are any requirements from it we still want enforced, we should put them in policy.
>> 
>> Feedback appreciated: thanks in advance!
>> 
>> -Scott
>> 
>> 
>> On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback y'all have provided so far (thanks!).  I've also attached the original text, new text, and diff if you want to see exactly what I I'm suggesting we change.
>> 
>> Thoughts?
>> 
>> Thanks,
>> Scott
>> 
>> 4.2.2. Initial allocation to ISPs
>> 
>> 4.2.2.1. General requirements
>> 
>> In order to receive an initial allocation from ARIN, organizations must:
>> 
>> 4.2.2.1.1. Demonstrate use of existing space
>> 
>> Demonstrate the efficient utilization of existing IPv4 block(s) from an upstream ISP that total at least half the size of the block being requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.
>> 
>> 4.2.2.1.2. Demonstrate efficient utilization
>> 
>> Demonstrate efficient use of IPv4 address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois server or by providing detailed utilization information.
>> 
>> 4.2.2.1.3. Utilize requested space within three months
>> 
>> Provide detailed information showing specifically how the requested IPv4 space will be utilized within three months.
>> 
>> 4.2.2.1.4. Renumber and return
>> 
>> ISPs receiving IP space from ARIN should renumber out of their previously allocated space if possible. If able to do so, an ISP should use the new IPv4 block to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
>> 
>> 4.2.2.2. Initial allocation sizes
>> 
>> 4.2.2.2.1 Single-homed
>> 
>> Single-homed organizations meeting the requirements listed above may request an initial allocation from ARIN between /20 and /22 in size. 
>> 
>> 4.2.2.2.2 Multi-homed
>> 
>> Multi-homed organizations meeting the requirements listed above and demonstrating an intent to announce the requested space in a multihomed fashion may request an initial allocation from ARIN between /20 and /24 in size.  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 4.3.1. End-users
>> 
>> ARIN assigns blocks of IP addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation of those addresses outside their organization. End-users must meet the requirements described in these guidelines for justifying the assignment of an address block.
>> 
>> 4.3.2. Minimum assignment
>> 
>> 4.3.2.1 Single Connection
>> 
>> The minimum block of IP address space assigned by ARIN to end-users is a /22. If assignments smaller than /22 are needed, end-users should contact their upstream provider.  If the end-user demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.
>> 
>> 4.3.2.2 Multihomed Connection
>> 
>> For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are smaller than /22, they will be from a block reserved for that purpose so long as that is feasible.
>> 
>> 4.3.3. Utilization rate
>> 
>> Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are:
>> 
>> A 25% immediate utilization rate, and
>> A 50% utilization rate within one year.
>> A greater utilization rate may be required based on individual network requirements.
>> 
>>  
>> 
>> ---------- Forwarded message ----------
>> From: Scott Leibrand <scottleibrand at gmail.com>
>> Date: Thu, Nov 21, 2013 at 3:03 PM
>> Subject: Bootstrapping new entrants after IPv4 exhaustion
>> To: ARIN-PPML List <arin-ppml at arin.net>
>> 
>> 
>> During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.
>> 
>> In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.
>> 
>> Here are a couple of the ideas that've come up so far:
>> 
>> 
>> 1) For smaller allocations than ARIN?s minimum, orgs ?should request space from their upstream provider _or another LIR_? (add underlined text to NRPM 4.2.1.5).
>> 
>> This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.
>> 
>> 
>> 2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users.  This would mean updating NRPM 4.2.2 and 4.3.2 (and would allow removal of NRPM 4.9 as redundant.)
>> 
>> Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them.  Current ARIN transfer policy states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer.  (Perhaps staff input here would be useful.)  In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.
>> 
>> Thoughts?  Do you support either or both of these ideas?  Would one or both of them be worth submitting as a policy proposal?
>> 
>> Thanks,
>> Scott
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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.
> 
> <Bootstrapping_new_entrants_redline_diff.pdf>_______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/86bd7c1c/attachment.htm>

From cja at daydream.com  Sun Nov 24 17:58:09 2013
From: cja at daydream.com (CJ Aronson)
Date: Sun, 24 Nov 2013 15:58:09 -0700
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
Message-ID: <CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>

On Sun, Nov 24, 2013 at 3:08 PM, Owen DeLong <owen at delong.com> wrote:

>
>
> Yes, but it limits that use to strictly transitional technology
> deployment, not general IPv4 utilization.
>
>
I think this is something we should be discussing.  Right now the only post
run out policy ARIN has is for the last /10.  You  can get a block (very
small) out of this for transition technologies only.  There is no provision
for new entrants except the transfer market in the ARIN region.

So some of us, and Scott started the discussion going, want to clean up the
policy manual so that it makes sense for ARIN post run out.  We could also
make a policy like in the other regions that gives a specific size block to
everyone (or maybe just new entrants?) out of some of the last space.  If
we are going to add the second option then time is really short.

we made the final /10 policy a very long time ago and maybe not everyone
realizes it is just for transition? Do people still think this makes sense?


Thanks!
----Cathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/f7868cdc/attachment.htm>

From billdarte at gmail.com  Sun Nov 24 19:18:09 2013
From: billdarte at gmail.com (Bill Darte)
Date: Sun, 24 Nov 2013 18:18:09 -0600
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
Message-ID: <CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>

New entrants cannot hope to compete in a long term strategy with only
limited amounts of v4.  So they will have to go to the transfer market if
they need more.  Isn't the transfer market about enabling people who
'really want or need' v4 that opportunity.  But, I agree that having some
v4 for start ups is probably still a requirement for now, so I would
consider a single small block.....still, if v6 deployment is delayed longer
than we hope, then the v4 for new entrants may still run out.  What do we
do for those folks.....  We cannot continue to move the deck chairs to
forestall the move to v6 forever....

bd


On Sun, Nov 24, 2013 at 4:58 PM, CJ Aronson <cja at daydream.com> wrote:

>
>
>
> On Sun, Nov 24, 2013 at 3:08 PM, Owen DeLong <owen at delong.com> wrote:
>
>>
>>
>> Yes, but it limits that use to strictly transitional technology
>> deployment, not general IPv4 utilization.
>>
>>
> I think this is something we should be discussing.  Right now the only
> post run out policy ARIN has is for the last /10.  You  can get a block
> (very small) out of this for transition technologies only.  There is no
> provision for new entrants except the transfer market in the ARIN region.
>
> So some of us, and Scott started the discussion going, want to clean up
> the policy manual so that it makes sense for ARIN post run out.  We could
> also make a policy like in the other regions that gives a specific size
> block to everyone (or maybe just new entrants?) out of some of the last
> space.  If we are going to add the second option then time is really short.
>
>
> we made the final /10 policy a very long time ago and maybe not everyone
> realizes it is just for transition? Do people still think this makes sense?
>
>
> Thanks!
> ----Cathy
>
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/f940f505/attachment.htm>

From SRyerse at eclipse-networks.com  Sun Nov 24 20:16:52 2013
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 25 Nov 2013 01:16:52 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <5292753A.1060904@quark.net>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.
	com>	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com><C
	AGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>,
	<5292753A.1060904@quark.net>
Message-ID: <1D1CA64C-5E12-4053-BD19-25D4A1C1767A@eclipse-networks.com>

+1 I strongly agree!

Sent from my iPhone

On Nov 24, 2013, at 5:01 PM, "Andrew Dul" <andrew.dul at quark.net<mailto:andrew.dul at quark.net>> wrote:

I believe we need to be thinking about a much simpler IPv4 policy after run-out occurs.  Initial allocation/assignment criteria could be as simple as, "Do you have 64 IP devices?" (e.g. 25% of a /24).  If answer is yes, you are approved for a /24.  I'm suggesting the removal of section 4.2.2.1.1 and loosening the language of 4.2.2.1.2.

I'm also in favor of moving to a /24 minimum for ISPs and end-users.

Also, I'd also like to point out that the ARIN community set aside a /10 worth of small blocks (/24-/28) to be used for new entrants after run-out occurs.  This block was intended to be used by new entrants after run-out.

https://www.arin.net/policy/nrpm.html#four10

The attached redline is Scott's version just formatted with revisions inline, which was helpful to me in considering what Scott was proposing.

Andrew

On 11/22/2013 5:05 PM, Scott Leibrand wrote:
I suppose I should provide some explanation for my various changes, too:

To address Randy's point that "the requirement of having space before you can get space seems a little ridiculous", I updated the requirement for single-homed ISPs to efficiently utilize space from upstream(s) that "total at least half the size of the block being requested", which is in line what we already require from multihomed ISPs.

Per the original suggestion that most people seem to like, I changed the minimum allocation sizes to /22 for single-homed and /24 for multihomed orgs (both ISPs and end-users).

To address Owen's point about "allowing ARIN to issue down to /24 to single-homed organizations that can document their inability to get space from their upstream provider", I also included language that "If the [org] demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space."  I didn't go quite as far as Owen suggested in allowing orgs that only need a /28 to get a /24 if they can't get the /28 from their upstream.

I consolidated the single-homed and multi-homed ISP requirements into a single set (differing only in minimum allocation size), and threaded the needle on the multihomed "Renumber and return" requirement by making it a "should" in both cases.

I struck the reference to the now-deprecated RFC 2050.  IMO if there are any requirements from it we still want enforced, we should put them in policy.

Feedback appreciated: thanks in advance!

-Scott


On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
Below is a first attempt at updating 4.2.2 and 4.3 based on the feedback y'all have provided so far (thanks!).  I've also attached the original text, new text, and diff if you want to see exactly what I I'm suggesting we change.

Thoughts?

Thanks,
Scott

4.2.2. Initial allocation to ISPs
4.2.2.1. General requirements
In order to receive an initial allocation from ARIN, organizations must:
4.2.2.1.1. Demonstrate use of existing space
Demonstrate the efficient utilization of existing IPv4 block(s) from an upstream ISP that total at least half the size of the block being requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.
4.2.2.1.2. Demonstrate efficient utilization
Demonstrate efficient use of IPv4 address space allocations by providing appropriate documentation, including assignment histories, showing their efficient use. ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWhois server or by providing detailed utilization information.
4.2.2.1.3. Utilize requested space within three months
Provide detailed information showing specifically how the requested IPv4 space will be utilized within three months.
4.2.2.1.4. Renumber and return
ISPs receiving IP space from ARIN should renumber out of their previously allocated space if possible. If able to do so, an ISP should use the new IPv4 block to renumber out of that previously allocated block of address space and must return the space to its upstream provider.
4.2.2.2. Initial allocation sizes
4.2.2.2.1 Single-homed
Single-homed organizations meeting the requirements listed above may request an initial allocation from ARIN between /20 and /22 in size.
4.2.2.2.2 Multi-homed
Multi-homed organizations meeting the requirements listed above and demonstrating an intent to announce the requested space in a multihomed fashion may request an initial allocation from ARIN between /20 and /24 in size.




4.3.1. End-users

ARIN assigns blocks of IP addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation of those addresses outside their organization. End-users must meet the requirements described in these guidelines for justifying the assignment of an address block.
4.3.2. Minimum assignment
4.3.2.1 Single Connection

The minimum block of IP address space assigned by ARIN to end-users is a /22. If assignments smaller than /22 are needed, end-users should contact their upstream provider.  If the end-user demonstrates that it cannot obtain sufficient IPv4 space from an upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to the extent it can demonstrate an immediate need for the space.

4.3.2.2 Multihomed Connection

For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are smaller than /22, they will be from a block reserved for that purpose so long as that is feasible.

4.3.3. Utilization rate
Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are:

  *   A 25% immediate utilization rate, and
  *   A 50% utilization rate within one year.
A greater utilization rate may be required based on individual network requirements.


---------- Forwarded message ----------
From: Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>>
Date: Thu, Nov 21, 2013 at 3:03 PM
Subject: Bootstrapping new entrants after IPv4 exhaustion
To: ARIN-PPML List <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>


During the discussion in Phoenix of Draft Policy 2013-7 (which I've since updated and will be sending back out to PPML shortly), and in other discussions before and since, it has become apparent that small networks may not qualify for transfers and be unable to get space from their upstreams after RIR and ISP IPv4 free pools run out.

In order to address this issue, a few different ideas have come up, so I wanted to bring some of them up to the community for discussion and see which possible solutions might have community support.

Here are a couple of the ideas that've come up so far:


1) For smaller allocations than ARIN?s minimum, orgs ?should request space from their upstream provider _or another LIR_? (add underlined text to NRPM 4.2.1.5<https://www.arin.net/policy/nrpm.html#four215>).

This would clarify that it's fine for organizations to get space reassigned to them by any other LIR if their upstream ISPs are no longer able to provide them the space they need.


2) Lower the minimum allocation sizes to /22 single-homed and /24 multihomed for both ISPs and end-users.  This would mean updating NRPM 4.2.2<https://www.arin.net/policy/nrpm.html#four22> and 4.3.2<https://www.arin.net/policy/nrpm.html#four32> (and would allow removal of NRPM 4.9<https://www.arin.net/policy/nrpm.html#four9> as redundant.)

Before the implementation of CIDR, many /24 allocations were made to organizations that are no longer using them.  Current ARIN transfer policy <https://www.arin.net/policy/nrpm.html#eight3> states that the minimum transfer size is a /24, but it's not clear in policy whether an single-homed organization that needs a small block (/24 to /21) would actually qualify to receive such a block via transfer.  (Perhaps staff input here would be useful.)  In any event, reducing the minimum allocation sizes would allow organizations of all types to receive the size of address block they actually need, either via transfer or from ARIN's inventory of returned space.

Thoughts?  Do you support either or both of these ideas?  Would one or both of them be worth submitting as a policy proposal?

Thanks,
Scott





_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.

<Bootstrapping_new_entrants_redline_diff.pdf>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/3e6efb1e/attachment.htm>

From owen at delong.com  Mon Nov 25 01:02:53 2013
From: owen at delong.com (Owen DeLong)
Date: Sun, 24 Nov 2013 22:02:53 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
Message-ID: <314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>

Frankly, I don?t think blocking off existing players from getting space they need in order to save space for possible future entrants is good policy.

I do think we need to make sure that we avoid deadly embrace in the transfer market where new players can?t even get a transfer simply because they can?t get upstream space or meet some other prior-space requirement before being able to seek out space in the transfer market.

However, I also think it is bad policy to make those policies any more liberal for transfers than they are for what is left of the ARIN free pool.

Hence, I support something like what Scott has posted, but I believe it is necessary to remove the ?transfer only? clause from it.

Owen

On Nov 24, 2013, at 4:18 PM, Bill Darte <billdarte at gmail.com> wrote:

> New entrants cannot hope to compete in a long term strategy with only limited amounts of v4.  So they will have to go to the transfer market if they need more.  Isn't the transfer market about enabling people who 'really want or need' v4 that opportunity.  But, I agree that having some v4 for start ups is probably still a requirement for now, so I would consider a single small block.....still, if v6 deployment is delayed longer than we hope, then the v4 for new entrants may still run out.  What do we do for those folks.....  We cannot continue to move the deck chairs to forestall the move to v6 forever....
> 
> bd
> 
> 
> On Sun, Nov 24, 2013 at 4:58 PM, CJ Aronson <cja at daydream.com> wrote:
> 
> 
> 
> On Sun, Nov 24, 2013 at 3:08 PM, Owen DeLong <owen at delong.com> wrote:
> 
> 
> Yes, but it limits that use to strictly transitional technology deployment, not general IPv4 utilization.
> 
> 
> I think this is something we should be discussing.  Right now the only post run out policy ARIN has is for the last /10.  You  can get a block (very small) out of this for transition technologies only.  There is no provision for new entrants except the transfer market in the ARIN region.  
> 
> So some of us, and Scott started the discussion going, want to clean up the policy manual so that it makes sense for ARIN post run out.  We could also make a policy like in the other regions that gives a specific size block to everyone (or maybe just new entrants?) out of some of the last space.  If we are going to add the second option then time is really short.  
> 
> we made the final /10 policy a very long time ago and maybe not everyone realizes it is just for transition? Do people still think this makes sense?  
> 
> Thanks!
> ----Cathy
> 
> 
> 
> _______________________________________________
> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131124/442fc89e/attachment.htm>

From mcr at sandelman.ca  Mon Nov 25 09:48:40 2013
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 25 Nov 2013 09:48:40 -0500
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
Message-ID: <13904.1385390920@sandelman.ca>


I think that we should stop trying to optimize or mitigate the IPv4 runout.
New entrants are screwed if their have a plan that requires more than an
IPv4/28 from upstream.

New entrants will need to do IPv6 from the first day, and we should make
getting IPv6 (only) so cheap and simple that a new entrant can get PI IPv6
space for their internal infrastructure at a point where they might not
have an AS or any IPv4.

Let's have them think: how can I do *new innovative service* in native v6,
rather than, "how do I doctor the paperwork convincingly enough so that I can
get some of the last bit of IPv4"

--
]               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    [



From serge at skycomp.ca  Mon Nov 25 10:06:10 2013
From: serge at skycomp.ca (Serge  Paquin)
Date: Mon, 25 Nov 2013 15:06:10 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <13904.1385390920@sandelman.ca>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<13904.1385390920@sandelman.ca>
Message-ID: <2ABC191402431F42867832ECFA921CB5153A5C2B@sky-mb1.skycomp.local>

I agree in principal, but that means new entrants can't really conduct business because ipv6 visibility isn't to a level that your connection is actually useful if you were only ipv6.

I haven't been reading the entire thread but maybe for existing orgs who want more ipv4 they must show they are dual stacked and have their ipv6 actually routing and working before they get more ipv4.

Same idea as you, but from the take that the existing users who have space and a profitable business needs to add ipv6 before it can grow more.

Refusing ipv4 to a new entrant makes it basically impossible to start a new ISP/Hosting company business.  Will make existing orgs not want to roll out ipv6 as fast so as to somewhat block new entrants and competition.  At least that's how I see it.

Serge.

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Richardson
Sent: Monday, November 25, 2013 9:49 AM
To: ARIN-PPML List
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion


I think that we should stop trying to optimize or mitigate the IPv4 runout.
New entrants are screwed if their have a plan that requires more than an
IPv4/28 from upstream.

New entrants will need to do IPv6 from the first day, and we should make getting IPv6 (only) so cheap and simple that a new entrant can get PI IPv6 space for their internal infrastructure at a point where they might not have an AS or any IPv4.

Let's have them think: how can I do *new innovative service* in native v6, rather than, "how do I doctor the paperwork convincingly enough so that I can get some of the last bit of IPv4"

--
]               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    [

_______________________________________________
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.


From mcr at sandelman.ca  Mon Nov 25 10:51:33 2013
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 25 Nov 2013 10:51:33 -0500
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <2ABC191402431F42867832ECFA921CB5153A5C2B@sky-mb1.skycomp.local>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<13904.1385390920@sandelman.ca>
	<2ABC191402431F42867832ECFA921CB5153A5C2B@sky-mb1.skycomp.local>
Message-ID: <27008.1385394693@sandelman.ca>


Serge  Paquin <serge at skycomp.ca> wrote:
    > I agree in principal, but that means new entrants can't really conduct
    > business because ipv6 visibility isn't to a level that your connection
    > is actually useful if you were only ipv6.

I disagree strongly.
You'd need to tell me specifically what the business plan of the new entrant
is, but I think that if you think IPv6 first, many things are possible.

    > Refusing ipv4 to a new entrant makes it basically impossible to start a
    > new ISP/Hosting company business.  Will make existing orgs not want to
    > roll out ipv6 as fast so as to somewhat block new entrants and
    > competition.  At least that's how I see it.

They are doing that right now in a large variety of ways (and we live under
the same duopoly, fat with IPv4 and no visible IPv6 deployment to the edges)

Not having IPv4 space is not the only way the screw new entrants.

--
]               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    [






From serge at skycomp.ca  Mon Nov 25 11:03:28 2013
From: serge at skycomp.ca (Serge  Paquin)
Date: Mon, 25 Nov 2013 16:03:28 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <27008.1385394693@sandelman.ca>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<13904.1385390920@sandelman.ca>
	<2ABC191402431F42867832ECFA921CB5153A5C2B@sky-mb1.skycomp.local>
	<27008.1385394693@sandelman.ca>
Message-ID: <2ABC191402431F42867832ECFA921CB5153A6339@sky-mb1.skycomp.local>

Well I've only had my ipv4 space for 2 or 3 years now, but in my case we are an ISP, co-location facility and hosting provider.

If we didn't have ipv4 space and could only be ipv6 I wouldn't have any business,  or we'd have to beg our upsteams to allocate us ipv4 space and we'd at their mercy as far as pricing. 

At the current point of ipv6 uptake I can't see how any business model on ipv6 only could survive if your network is big enough that you need direct allocation.  You just wouldn't have enough visibility only single stacked ipv6 at this point.

-----Original Message-----
From: mcr at sandelman.ca [mailto:mcr at sandelman.ca] 
Sent: Monday, November 25, 2013 10:52 AM
To: Serge Paquin
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion


Serge  Paquin <serge at skycomp.ca> wrote:
    > I agree in principal, but that means new entrants can't really conduct
    > business because ipv6 visibility isn't to a level that your connection
    > is actually useful if you were only ipv6.

I disagree strongly.
You'd need to tell me specifically what the business plan of the new entrant is, but I think that if you think IPv6 first, many things are possible.

    > Refusing ipv4 to a new entrant makes it basically impossible to start a
    > new ISP/Hosting company business.  Will make existing orgs not want to
    > roll out ipv6 as fast so as to somewhat block new entrants and
    > competition.  At least that's how I see it.

They are doing that right now in a large variety of ways (and we live under the same duopoly, fat with IPv4 and no visible IPv6 deployment to the edges)

Not having IPv4 space is not the only way the screw new entrants.

--
]               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    [






From David.Huberman at microsoft.com  Mon Nov 25 11:08:45 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 16:08:45 +0000
Subject: [arin-ppml] Stats request
Message-ID: <e083e4643d664c34a8fc56ed11596071@BN1PR03MB250.namprd03.prod.outlook.com>

All this talk about "new entrants" with no data basis for what's being discussed.

ARIN this question is for you.  In 2013 YTD:

- how many assignments of IPv4 were issued to end-users.
Then:
- how many assignments of IPv4 were issued to end-users who didn't previously have direct space from ARIN? (1)

Repeat for ISPs:
- how many allocations of IPv4 were issued to ISPs.
Then:
- how many allocations of IPv4 were issued to ISPs who didn't previously have direct space from ARIN (1)

Thanks
/david

(1) Ignore the possibility of multiple accounts for the same company; they're statistical outliers and make data collection much more difficult

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)



From csquat at ccsd.net  Mon Nov 25 11:10:12 2013
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Mon, 25 Nov 2013 08:10:12 -0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 101, Issue 10
Message-ID: <fc.004c4e0749e099063b9aca0040213e0a.49e0990c@interact.ccsd.net>

I am out of the office today.  Please contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/14f4407e/attachment.htm>

From David.Huberman at microsoft.com  Mon Nov 25 11:06:35 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 16:06:35 +0000
Subject: [arin-ppml] Stats request
Message-ID: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>

All this talk about "new entrants" with no data basis for what's being discussed.

ARIN this question is for you.  In 2013 YTD:

- how many assignments of IPv4 were issued to end-users.
Then:
- how many assignments of IPv4 were issued to end-users who didn't previously have direct space from ARIN? (1)

Repeat for ISPs:
- how many allocations of IPv4 were issued to ISPs.
Then:
- how many allocations of IPv4 were issued to ISPs who didn't previously have direct space from ARIN (1)

Thanks
/david

(1) Ignore the possibility of multiple accounts for the same company; they're statistical outliers and make data collection much more difficult

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)


From jcurran at arin.net  Mon Nov 25 12:21:14 2013
From: jcurran at arin.net (John Curran)
Date: Mon, 25 Nov 2013 17:21:14 +0000
Subject: [arin-ppml] Stats request
In-Reply-To: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <008F035F-C405-4D90-9304-F16303FAF606@arin.net>


On Nov 25, 2013, at 11:06 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> All this talk about "new entrants" with no data basis for what's being discussed.
> 
> ARIN this question is for you.  In 2013 YTD:
> 
> - how many assignments of IPv4 were issued to end-users.
> Then:
> - how many assignments of IPv4 were issued to end-users who didn't previously have direct space from ARIN? (1)
> 
> Repeat for ISPs:
> - how many allocations of IPv4 were issued to ISPs.
> Then:
> - how many allocations of IPv4 were issued to ISPs who didn't previously have direct space from ARIN (1)

We have the overall requests here: https://www.arin.net/knowledge/statistics/index.html

That doesn't provide new requestors versus existing; I will look into getting
this information posted to the list.

Thanks!
/John

John Curran
President and CEO
ARIN




From scottleibrand at gmail.com  Mon Nov 25 13:57:27 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 10:57:27 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
Message-ID: <CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>

Owen,

I agree with you that we need to avoid the deadly embrace: that is the main
reason for proposing this, so we're in full agreement there.

I'm not sure that it would be a good idea, though, to let any organization,
not matter how small, get an IPv4 /24 from ARIN's free pool without any
real restrictions.  I am much more comfortable allowing an organization to
get such a /24 via transfer, where they have to have at least enough need
for the space to justify spending the money for it.

In any event, I wonder if we should first focus on the less controversial
fix, and make sure that anyone who can justify the need for a /24 or larger
can get it somehow or other, and separately look into the possibility of
portable space for organizations needing less than a /24.

-Scott


On Sun, Nov 24, 2013 at 10:02 PM, Owen DeLong <owen at delong.com> wrote:

> Frankly, I don?t think blocking off existing players from getting space
> they need in order to save space for possible future entrants is good
> policy.
>
> I do think we need to make sure that we avoid deadly embrace in the
> transfer market where new players can?t even get a transfer simply because
> they can?t get upstream space or meet some other prior-space requirement
> before being able to seek out space in the transfer market.
>
> However, I also think it is bad policy to make those policies any more
> liberal for transfers than they are for what is left of the ARIN free pool.
>
> Hence, I support something like what Scott has posted, but I believe it is
> necessary to remove the ?transfer only? clause from it.
>
> Owen
>
> On Nov 24, 2013, at 4:18 PM, Bill Darte <billdarte at gmail.com> wrote:
>
> New entrants cannot hope to compete in a long term strategy with only
> limited amounts of v4.  So they will have to go to the transfer market if
> they need more.  Isn't the transfer market about enabling people who
> 'really want or need' v4 that opportunity.  But, I agree that having some
> v4 for start ups is probably still a requirement for now, so I would
> consider a single small block.....still, if v6 deployment is delayed longer
> than we hope, then the v4 for new entrants may still run out.  What do we
> do for those folks.....  We cannot continue to move the deck chairs to
> forestall the move to v6 forever....
>
> bd
>
>
> On Sun, Nov 24, 2013 at 4:58 PM, CJ Aronson <cja at daydream.com> wrote:
>
>>
>>
>>
>> On Sun, Nov 24, 2013 at 3:08 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>>
>>>
>>> Yes, but it limits that use to strictly transitional technology
>>> deployment, not general IPv4 utilization.
>>>
>>>
>> I think this is something we should be discussing.  Right now the only
>> post run out policy ARIN has is for the last /10.  You  can get a block
>> (very small) out of this for transition technologies only.  There is no
>> provision for new entrants except the transfer market in the ARIN region.
>>
>> So some of us, and Scott started the discussion going, want to clean up
>> the policy manual so that it makes sense for ARIN post run out.  We could
>> also make a policy like in the other regions that gives a specific size
>> block to everyone (or maybe just new entrants?) out of some of the last
>> space.  If we are going to add the second option then time is really short.
>>
>>
>> we made the final /10 policy a very long time ago and maybe not everyone
>> realizes it is just for transition? Do people still think this makes sense?
>>
>>
>> Thanks!
>> ----Cathy
>>
>>
>>
>> _______________________________________________
>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/78fb80f9/attachment.htm>

From David.Huberman at microsoft.com  Mon Nov 25 14:11:46 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 19:11:46 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
Message-ID: <e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>

Scott Leibrand wrote:

> I'm not sure that it would be a good idea, though, to let 
> any organization, not matter how small, get an IPv4 /24
>  from ARIN's free pool without any real restrictions. 

Can you please provide a technical argument for why one organization should receive a /24
from ARIN, but another organization should not?  In your response, please explain
why the internet operates better when an end-user (whatever that means) can get a /24, 
but an ISP cannot.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)






From scottleibrand at gmail.com  Mon Nov 25 14:40:03 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 11:40:03 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>


> On Nov 25, 2013, at 11:11 AM, David Huberman <David.Huberman at microsoft.com> wrote:
> 
> Scott Leibrand wrote:
> 
>> I'm not sure that it would be a good idea, though, to let 
>> any organization, not matter how small, get an IPv4 /24
>> from ARIN's free pool without any real restrictions.
> 
> Can you please provide a technical argument for why one organization should receive a /24
> from ARIN, but another organization should not?  In your response, please explain
> why the internet operates better when an end-user (whatever that means) can get a /24, 
> but an ISP cannot.

That wasn't the distinction I was referring to. I am saying that I'm not sure we want to let an org (regardless of type) who only needs a /28 get a /24 from ARIN. 

In addition to keeping that minimum level of needs justification, the only technical distinction I would retain in my proposed liberalization would be that multihomed orgs should be able to get blocks as small as a /24 from ARIN (as they'll be going into BGP regardless) whereas single-homed orgs should still go to their upstream for up to a /22. Again, no distinction between end-user and ISP orgs. 

I'd also welcome your input on the proposed text. 

-Scott

From David.Huberman at microsoft.com  Mon Nov 25 14:47:09 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 19:47:09 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
Message-ID: <203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>

> I'd also welcome your input on the proposed text. 

The first sentence of the new proposed text:

"Demonstrate the efficient utilization of existing IPv4 block(s) from an
upstream ISP that total at least half the size of the block being
requested. "

What is the technical justification for this?  How does the internet operate
better if new entrants are required to use space from an upstream first
before the policy-making community "allows" them to come to ARIN?

Why can an end-user (whatever that means) obtain a /24 without this
requirement, but an ISP cannot?

How does this policy text (the whole text, not the snippet above) simplify
NRPM and allow ARIN to better meet the needs of the operator community
than it does today?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)




From scottleibrand at gmail.com  Mon Nov 25 15:28:58 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 12:28:58 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>

On Mon, Nov 25, 2013 at 11:47 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

> > I'd also welcome your input on the proposed text.
>
> The first sentence of the new proposed text:
>

Thanks for chiming in.

>
> "Demonstrate the efficient utilization of existing IPv4 block(s) from an
> upstream ISP that total at least half the size of the block being
> requested. "
>
> What is the technical justification for this?  How does the internet
> operate
> better if new entrants are required to use space from an upstream first
> before the policy-making community "allows" them to come to ARIN?
>

I'm not sure it's all that helpful to ask me to re-justify the entire NRPM.
 That requirement, in a more strict form, is what is present in the NRPM
today.

I'm proposing to take one step toward liberalizing policy in the direction
you seem to favor.  If you're proposing that we move further, it would be
helpful if you could provide an argument for doing so.  If we can get
consensus around additional changes, I'd be happy to do so, but I don't
want to risk the perfect becoming the enemy of "better than things are
today", so I'll be most receptive to tweaks that don't completely do away
with needs assessment just yet (as that has proven very controversial to
date).


> Why can an end-user (whatever that means) obtain a /24 without this
> requirement, but an ISP cannot?
>

This is a distinction that long pre-dated my involvement with ARIN.  I
think the original rationale was that, since ISPs are basing their requests
on existing subscriber counts for the most part, they should usually
justify their needs based on existing usage, rather than projections.
 End-user needs tend to be more based on deployment of new equipment, etc.
so such backward-looking needs assessment makes less sense.

What do you think ARIN should be using (other than current IP usage) to
evaluate the needs of new and growing ISPs?


>
> How does this policy text (the whole text, not the snippet above) simplify
> NRPM and allow ARIN to better meet the needs of the operator community
> than it does today?
>

I believe that, by making it easier for operators of all sorts to qualify
to receive space from ARIN, either from the free pool or via transfer, this
proposal allows ARIN to meet the needs of operators it can't serve directly
today, and to continue meeting the needs of new entrants and smaller
operators as IPv4 becomes increasingly scarce.  I'm open to suggestions for
how to better achieve that.

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/077ce6d4/attachment.htm>

From David.Huberman at microsoft.com  Mon Nov 25 15:45:41 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 20:45:41 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>
	<CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
Message-ID: <850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>

Scott wrote:

> I'm not sure it's all that helpful to ask me to re-justify the entire NRPM. ?
> That requirement, in a more strict form, is what is present in the NRPM today.

But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:

4.2.0:

An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1

An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0

4.3.0

An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.3.1

An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0

Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.

Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)


From SRyerse at eclipse-networks.com  Mon Nov 25 16:18:13 2013
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 25 Nov 2013 21:18:13 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.
	com><CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com><CA
	GkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com><5292753A.
	1060904@quark.net><B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com><CAC6JZK
	TB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com><CAMApp37VH+wEW
	62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com><314DB6A0-F495-4445-B9
	2B-2567815D7C95@delong.com><CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqta
	v3+Q@mail.gmail.com><e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03
	.prod.outlook.com><52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com><203d8ba4
	41e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com><CAGkMwz47J
	QWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201434427A8@ENI-MAIL.eclipse-networks.com>

I'm all for eliminating the definition of what constitutes an end user vs. ISP vs. whatever, as it doesn't really matter unless there is a technical issue involved that ARIN needs to manage.  I also agree that it might be easier making smaller steps to fixing these kinds of issues given the dramatic difference of opinion surrounding how blocks should be allocated.

I would point out though that in real life the requirements set out below in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm sure that in past real life requests that  ARIN has received and allocated, some organizations have done so to get a successful allocation request filled.  I don't believe ARIN goes back and checks to see if an organization met their predicated allocations in the timeframe policies require.  The requirements based on future usage require us to be able to predict the future and of course none of us really can do that.  

I am for what Scott is trying to accomplish.  I know it would be a big change in policy but isn't it finally time to jettison the needs tests altogether and just allocate based on rightsizing blocks allocated to the size of the requesting organization and the size of their existing network and existing allocations.  Requiring organizations to predict the future and fudge their numbers just to get a block allocated is not what we want to incent organizations to do.  Regardless of the original intentions this is just a game organizations are forced to play and why would this community want to force anyone to do that?

Just my two cents.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Monday, November 25, 2013 3:46 PM
To: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Scott wrote:

> I'm not sure it's all that helpful to ask me to re-justify the entire 
> NRPM. That requirement, in a more strict form, is what is present in the NRPM today.

But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:

4.2.0:

An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1

An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0

4.3.0

An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.3.1

An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0

Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.

Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
_______________________________________________
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.

From David.Huberman at microsoft.com  Mon Nov 25 16:22:39 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 21:22:39 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201434427A8@ENI-MAIL.eclipse-networks.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.
	com><CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com><CA
	GkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com><5292753A.
	1060904@quark.net><B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com><CAC6JZK
	TB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com><CAMApp37VH+wEW
	62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com><314DB6A0-F495-4445-B9
	2B-2567815D7C95@delong.com><CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqta
	v3+Q@mail.gmail.com><e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03
	.prod.outlook.com><52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com><203d8ba4
	41e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com><CAGkMwz47J
	QWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201434427A8@ENI-MAIL.eclipse-networks.com>
Message-ID: <c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>

Ok, quick question then:

Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1 are the exact rules end-users have been subject to for 16 years? ARIN has reviewed thousands and thousands of requests every year under the policy framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1.

And a quick observation:

Scott's proposed change isn't big at all.  It just lowers the bar from /22 to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller ISPs (yourself included, Steven, as you told this list many times when you first joined) in a long time.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com] 
Sent: Monday, November 25, 2013 1:18 PM
To: David Huberman; 'arin-ppml at arin.net'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

I'm all for eliminating the definition of what constitutes an end user vs. ISP vs. whatever, as it doesn't really matter unless there is a technical issue involved that ARIN needs to manage.  I also agree that it might be easier making smaller steps to fixing these kinds of issues given the dramatic difference of opinion surrounding how blocks should be allocated.

I would point out though that in real life the requirements set out below in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm sure that in past real life requests that  ARIN has received and allocated, some organizations have done so to get a successful allocation request filled.  I don't believe ARIN goes back and checks to see if an organization met their predicated allocations in the timeframe policies require.  The requirements based on future usage require us to be able to predict the future and of course none of us really can do that.  

I am for what Scott is trying to accomplish.  I know it would be a big change in policy but isn't it finally time to jettison the needs tests altogether and just allocate based on rightsizing blocks allocated to the size of the requesting organization and the size of their existing network and existing allocations.  Requiring organizations to predict the future and fudge their numbers just to get a block allocated is not what we want to incent organizations to do.  Regardless of the original intentions this is just a game organizations are forced to play and why would this community want to force anyone to do that?

Just my two cents.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Monday, November 25, 2013 3:46 PM
To: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Scott wrote:

> I'm not sure it's all that helpful to ask me to re-justify the entire 
> NRPM. That requirement, in a more strict form, is what is present in the NRPM today.

But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:

4.2.0:

An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1

An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0

4.3.0

An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.3.1

An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0

Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.

Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
_______________________________________________
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.

From SRyerse at eclipse-networks.com  Mon Nov 25 16:29:03 2013
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 25 Nov 2013 21:29:03 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.
	com><CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com><CA
	GkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com><5292753A.
	1060904@quark.net><B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com><CAC6JZK
	TB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com><CAMApp37VH+wEW
	62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com><314DB6A0-F495-4445-B9
	2B-2567815D7C95@delong.com><CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqta
	v3+Q@mail.gmail.com><e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03
	.prod.outlook.com><52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com><203d8ba4
	41e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com><CAGkMwz47J
	QWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com><850a412669b3482ea
	f36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com><5B9E90747FA2974D91A
	54FCFA1B8AD1201434427A8@ENI-MAIL.eclipse-networks.com>
	<c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120143442889@ENI-MAIL.eclipse-networks.com>

My opinion absolutely does not change just because organizations have been made to jump thru unnecessary hoops for 16 years.  I strongly think that needs to be corrected.  Obviously I'm not alone in that opinion given that other's in other regions have made similar proposals.  

As I said I agree with and support what Scott is trying to accomplish as it is a slight improvement to the status quo.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: David Huberman [mailto:David.Huberman at microsoft.com] 
Sent: Monday, November 25, 2013 4:23 PM
To: Steven Ryerse; 'arin-ppml at arin.net'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Ok, quick question then:

Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1 are the exact rules end-users have been subject to for 16 years? ARIN has reviewed thousands and thousands of requests every year under the policy framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1.

And a quick observation:

Scott's proposed change isn't big at all.  It just lowers the bar from /22 to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller ISPs (yourself included, Steven, as you told this list many times when you first joined) in a long time.


David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com]
Sent: Monday, November 25, 2013 1:18 PM
To: David Huberman; 'arin-ppml at arin.net'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

I'm all for eliminating the definition of what constitutes an end user vs. ISP vs. whatever, as it doesn't really matter unless there is a technical issue involved that ARIN needs to manage.  I also agree that it might be easier making smaller steps to fixing these kinds of issues given the dramatic difference of opinion surrounding how blocks should be allocated.

I would point out though that in real life the requirements set out below in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm sure that in past real life requests that  ARIN has received and allocated, some organizations have done so to get a successful allocation request filled.  I don't believe ARIN goes back and checks to see if an organization met their predicated allocations in the timeframe policies require.  The requirements based on future usage require us to be able to predict the future and of course none of us really can do that.  

I am for what Scott is trying to accomplish.  I know it would be a big change in policy but isn't it finally time to jettison the needs tests altogether and just allocate based on rightsizing blocks allocated to the size of the requesting organization and the size of their existing network and existing allocations.  Requiring organizations to predict the future and fudge their numbers just to get a block allocated is not what we want to incent organizations to do.  Regardless of the original intentions this is just a game organizations are forced to play and why would this community want to force anyone to do that?

Just my two cents.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Monday, November 25, 2013 3:46 PM
To: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Scott wrote:

> I'm not sure it's all that helpful to ask me to re-justify the entire 
> NRPM. That requirement, in a more strict form, is what is present in the NRPM today.

But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:

4.2.0:

An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1

An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0

4.3.0

An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.3.1

An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0

Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.

Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
_______________________________________________
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.

From scottleibrand at gmail.com  Mon Nov 25 16:39:46 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 13:39:46 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD120143442889@ENI-MAIL.eclipse-networks.com>
References: <CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD120143442889@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAGkMwz7HthN39RND7LYcQMdifLxFAzmV9L6Lry7yq7+tBHrcFw@mail.gmail.com>

Steven,

Do you have some specific policy language (or can you point to specific
language from another region) to illustrate how you think new allocations
should be appropriately sized?  I understand that you want something
simpler and more liberal than both the current ISP and end-user
requirements, but I'm not completely clear on what that would look like.

Thanks,
Scott


On Mon, Nov 25, 2013 at 1:29 PM, Steven Ryerse <SRyerse at eclipse-networks.com
> wrote:

> My opinion absolutely does not change just because organizations have been
> made to jump thru unnecessary hoops for 16 years.  I strongly think that
> needs to be corrected.  Obviously I'm not alone in that opinion given that
> other's in other regions have made similar proposals.
>
> As I said I agree with and support what Scott is trying to accomplish as
> it is a slight improvement to the status quo.
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>
>
> -----Original Message-----
> From: David Huberman [mailto:David.Huberman at microsoft.com]
> Sent: Monday, November 25, 2013 4:23 PM
> To: Steven Ryerse; 'arin-ppml at arin.net'
> Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> Ok, quick question then:
>
> Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1
> are the exact rules end-users have been subject to for 16 years? ARIN has
> reviewed thousands and thousands of requests every year under the policy
> framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1.
>
> And a quick observation:
>
> Scott's proposed change isn't big at all.  It just lowers the bar from /22
> to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller
> ISPs (yourself included, Steven, as you told this list many times when you
> first joined) in a long time.
>
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com]
> Sent: Monday, November 25, 2013 1:18 PM
> To: David Huberman; 'arin-ppml at arin.net'
> Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> I'm all for eliminating the definition of what constitutes an end user vs.
> ISP vs. whatever, as it doesn't really matter unless there is a technical
> issue involved that ARIN needs to manage.  I also agree that it might be
> easier making smaller steps to fixing these kinds of issues given the
> dramatic difference of opinion surrounding how blocks should be allocated.
>
> I would point out though that in real life the requirements set out below
> in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm
> sure that in past real life requests that  ARIN has received and allocated,
> some organizations have done so to get a successful allocation request
> filled.  I don't believe ARIN goes back and checks to see if an
> organization met their predicated allocations in the timeframe policies
> require.  The requirements based on future usage require us to be able to
> predict the future and of course none of us really can do that.
>
> I am for what Scott is trying to accomplish.  I know it would be a big
> change in policy but isn't it finally time to jettison the needs tests
> altogether and just allocate based on rightsizing blocks allocated to the
> size of the requesting organization and the size of their existing network
> and existing allocations.  Requiring organizations to predict the future
> and fudge their numbers just to get a block allocated is not what we want
> to incent organizations to do.  Regardless of the original intentions this
> is just a game organizations are forced to play and why would this
> community want to force anyone to do that?
>
> Just my two cents.
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Monday, November 25, 2013 3:46 PM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> Scott wrote:
>
> > I'm not sure it's all that helpful to ask me to re-justify the entire
> > NRPM. That requirement, in a more strict form, is what is present in the
> NRPM today.
>
> But we can't make policy for policy's sake. ARIN exists to, in part,
> provide number resources to the operator community who needs them.  Section
> 4 of the NRPPM serves the needs of the network operator community circa
> 1996, not 2014 and beyond.   So how about:
>
> 4.2.0:
>
> An ISP can obtain an initial allocation of a /24 or larger by
> demonstrating a need to use at least 25% of the space within 90 days, and
> at least 50% of the space within one year.
>
> 4.2.1
>
> An ISP can obtain an additional allocations by demonstrating 80% or better
> utilization of existing address space. The additional allocation block size
> determination uses the criterion in 4.2.0
>
> 4.3.0
>
> An end-user can obtain an initial assignment of a /24 or larger by
> demonstrating a need to use at least 25% of the space within 90 days, and
> at least 50% of the space within one year.
>
> 4.3.1
>
> An end-user can obtain an additional assignment by demonstrating 80% or
> better utilization of existing address space. The additional assignment
> block size determination uses the criterion in 4.3.0
>
> Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done
> with section 4, and you've fixed NRPM 8.3 and you've harmonized the very
> broken ISP v End-user mechanic.
>
> Doesn't this serve the network operator community in 2014 better than
> making small changes to walls and walls of text from 1996?
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/10293ec7/attachment.htm>

From scottleibrand at gmail.com  Mon Nov 25 16:37:54 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 13:37:54 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201434427A8@ENI-MAIL.eclipse-networks.com>
	<c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <CAGkMwz40QNbdN5Hr+QMSBMtryUWESBxo2GyTTVJtcPSs1DNP4A@mail.gmail.com>

Thanks to both of you for you input so far.

What do other folks think?  Are we better off keeping a tweaked version of
the current needs justification mechanics for ISPs?  Or should we move
toward allowing ISPs to get a block whose size is determined by their
forward-looking projections as we do for end-user organizations today?

-Scott


On Mon, Nov 25, 2013 at 1:22 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Ok, quick question then:
>
> Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1
> are the exact rules end-users have been subject to for 16 years? ARIN has
> reviewed thousands and thousands of requests every year under the policy
> framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1.
>
> And a quick observation:
>
> Scott's proposed change isn't big at all.  It just lowers the bar from /22
> to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller
> ISPs (yourself included, Steven, as you told this list many times when you
> first joined) in a long time.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com]
> Sent: Monday, November 25, 2013 1:18 PM
> To: David Huberman; 'arin-ppml at arin.net'
> Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> I'm all for eliminating the definition of what constitutes an end user vs.
> ISP vs. whatever, as it doesn't really matter unless there is a technical
> issue involved that ARIN needs to manage.  I also agree that it might be
> easier making smaller steps to fixing these kinds of issues given the
> dramatic difference of opinion surrounding how blocks should be allocated.
>
> I would point out though that in real life the requirements set out below
> in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm
> sure that in past real life requests that  ARIN has received and allocated,
> some organizations have done so to get a successful allocation request
> filled.  I don't believe ARIN goes back and checks to see if an
> organization met their predicated allocations in the timeframe policies
> require.  The requirements based on future usage require us to be able to
> predict the future and of course none of us really can do that.
>
> I am for what Scott is trying to accomplish.  I know it would be a big
> change in policy but isn't it finally time to jettison the needs tests
> altogether and just allocate based on rightsizing blocks allocated to the
> size of the requesting organization and the size of their existing network
> and existing allocations.  Requiring organizations to predict the future
> and fudge their numbers just to get a block allocated is not what we want
> to incent organizations to do.  Regardless of the original intentions this
> is just a game organizations are forced to play and why would this
> community want to force anyone to do that?
>
> Just my two cents.
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Huberman
> Sent: Monday, November 25, 2013 3:46 PM
> To: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> Scott wrote:
>
> > I'm not sure it's all that helpful to ask me to re-justify the entire
> > NRPM. That requirement, in a more strict form, is what is present in the
> NRPM today.
>
> But we can't make policy for policy's sake. ARIN exists to, in part,
> provide number resources to the operator community who needs them.  Section
> 4 of the NRPPM serves the needs of the network operator community circa
> 1996, not 2014 and beyond.   So how about:
>
> 4.2.0:
>
> An ISP can obtain an initial allocation of a /24 or larger by
> demonstrating a need to use at least 25% of the space within 90 days, and
> at least 50% of the space within one year.
>
> 4.2.1
>
> An ISP can obtain an additional allocations by demonstrating 80% or better
> utilization of existing address space. The additional allocation block size
> determination uses the criterion in 4.2.0
>
> 4.3.0
>
> An end-user can obtain an initial assignment of a /24 or larger by
> demonstrating a need to use at least 25% of the space within 90 days, and
> at least 50% of the space within one year.
>
> 4.3.1
>
> An end-user can obtain an additional assignment by demonstrating 80% or
> better utilization of existing address space. The additional assignment
> block size determination uses the criterion in 4.3.0
>
> Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done
> with section 4, and you've fixed NRPM 8.3 and you've harmonized the very
> broken ISP v End-user mechanic.
>
> Doesn't this serve the network operator community in 2014 better than
> making small changes to walls and walls of text from 1996?
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/c275e69a/attachment.htm>

From scottleibrand at gmail.com  Mon Nov 25 16:48:28 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 25 Nov 2013 13:48:28 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <5292753A.1060904@quark.net>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
Message-ID: <CAGkMwz4kuUTkBQ2+mR02c4LUQQ_mdvxQbBGzSP2O-VvYwG+1vg@mail.gmail.com>

I would support something along these lines, either something that takes
effect after ARIN's IPv4 free pool is exhausted (no more /24s are
available), or something that takes effect sooner but only applies to
transfers.  I don't want to change the rules this late in the game for the
remaining free pool.

Again, a question for everyone else on the list: do you think we should be
making incremental changes to the minimum allocation requirements and
tweaks to make needs qualification a bit simpler and easier?  Or should we
be looking at a *much* simpler and easier policy?

Thanks,
Scott


On Sun, Nov 24, 2013 at 1:52 PM, Andrew Dul <andrew.dul at quark.net> wrote:

>  I believe we need to be thinking about a much simpler IPv4 policy after
> run-out occurs.  Initial allocation/assignment criteria could be as simple
> as, "Do you have 64 IP devices?" (e.g. 25% of a /24).  If answer is yes,
> you are approved for a /24.  I'm suggesting the removal of section
> 4.2.2.1.1 and loosening the language of 4.2.2.1.2.
>
> I'm also in favor of moving to a /24 minimum for ISPs and end-users.
>
> Also, I'd also like to point out that the ARIN community set aside a /10
> worth of small blocks (/24-/28) to be used for new entrants after run-out
> occurs.  This block was intended to be used by new entrants after run-out.
>
> https://www.arin.net/policy/nrpm.html#four10
>
> The attached redline is Scott's version just formatted with revisions
> inline, which was helpful to me in considering what Scott was proposing.
>
> Andrew
>
>
> On 11/22/2013 5:05 PM, Scott Leibrand wrote:
>
> I suppose I should provide some explanation for my various changes, too:
>
>  To address Randy's point that "the requirement of having space before
> you can get space seems a little ridiculous", I updated the requirement for
> single-homed ISPs to efficiently utilize space from upstream(s) that "total
> at least half the size of the block being requested", which is in line what
> we already require from multihomed ISPs.
>
>  Per the original suggestion that most people seem to like, I changed the
> minimum allocation sizes to /22 for single-homed and /24 for multihomed
> orgs (both ISPs and end-users).
>
>  To address Owen's point about "allowing ARIN to issue down to /24 to
> single-homed organizations that can document their inability to get space
> from their upstream provider", I also included language that "If the
> [org] demonstrates that it cannot obtain sufficient IPv4 space from an
> upstream ISP, it can instead receive a /24 or larger via 8.3 transfer to
> the extent it can demonstrate an immediate need for the space."  I didn't
> go quite as far as Owen suggested in allowing orgs that only need a /28 to
> get a /24 if they can't get the /28 from their upstream.
>
>  I consolidated the single-homed and multi-homed ISP requirements into a
> single set (differing only in minimum allocation size), and threaded the
> needle on the multihomed "Renumber and return" requirement by making it a
> "should" in both cases.
>
>  I struck the reference to the now-deprecated RFC 2050.  IMO if there are
> any requirements from it we still want enforced, we should put them in
> policy.
>
>  Feedback appreciated: thanks in advance!
>
>  -Scott
>
>
> On Fri, Nov 22, 2013 at 4:44 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>>  Below is a first attempt at updating 4.2.2 and 4.3 based on the
>> feedback y'all have provided so far (thanks!).  I've also attached the
>> original text, new text, and diff if you want to see exactly what I I'm
>> suggesting we change.
>>
>>  Thoughts?
>>
>>  Thanks,
>> Scott
>>
>>  *4.2.2. Initial allocation to ISPs*
>> 4.2.2.1. General requirements
>>
>> In order to receive an initial allocation from ARIN, organizations must:
>> 4.2.2.1.1. Demonstrate use of existing space
>>
>> Demonstrate the efficient utilization of existing IPv4 block(s) from an
>> upstream ISP that total at least half the size of the block being
>> requested.  If the ISP demonstrates that it cannot obtain sufficient IPv4
>> space from an upstream ISP, it can instead receive a /24 or larger via 8.3
>> transfer to the extent it can demonstrate an immediate need for the space.
>> 4.2.2.1.2. Demonstrate efficient utilization
>>
>> Demonstrate efficient use of IPv4 address space allocations by providing
>> appropriate documentation, including assignment histories, showing their
>> efficient use. ISPs must provide reassignment information on the entire
>> previously allocated block(s) via SWIP or RWhois server for /29 or larger
>> blocks. For blocks smaller than /29 and for internal space, ISPs should
>> provide utilization data either via SWIP or RWhois server or by providing
>> detailed utilization information.
>> 4.2.2.1.3. Utilize requested space within three months
>>
>> Provide detailed information showing specifically how the requested IPv4
>> space will be utilized within three months.
>> 4.2.2.1.4. Renumber and return
>>
>> ISPs receiving IP space from ARIN should renumber out of their previously
>> allocated space if possible. If able to do so, an ISP should use the new
>> IPv4 block to renumber out of that previously allocated block of address
>> space and must return the space to its upstream provider.
>> 4.2.2.2. Initial allocation sizes 4.2.2.2.1 Single-homed
>>
>> Single-homed organizations meeting the requirements listed above may
>> request an initial allocation from ARIN between /20 and /22 in size.
>> 4.2.2.2.2 Multi-homed
>>
>> Multi-homed organizations meeting the requirements listed above and
>> demonstrating an intent to announce the requested space in a multihomed
>> fashion may request an initial allocation from ARIN between /20 and /24 in
>> size.
>>
>>
>>
>>
>>
>>  *4.3.1. End-users*
>>
>> ARIN assigns blocks of IP addresses to end-users who request address
>> space for their internal use in running their own networks, but not for
>> sub-delegation of those addresses outside their organization. End-users
>> must meet the requirements described in these guidelines for justifying the
>> assignment of an address block.
>>
>> *4.3.2. Minimum assignment*
>> 4.3.2.1 Single Connection
>>
>> The minimum block of IP address space assigned by ARIN to end-users is a
>> /22. If assignments smaller than /22 are needed, end-users should contact
>> their upstream provider.  If the end-user demonstrates that it cannot
>> obtain sufficient IPv4 space from an upstream ISP, it can instead receive a
>> /24 or larger via 8.3 transfer to the extent it can demonstrate an
>> immediate need for the space.
>> 4.3.2.2 Multihomed Connection
>>
>> For multihomed end-users who demonstrate an intent to announce the
>> requested space in a multihomed fashion to two or more distinct ASNs not
>> owned or controlled by the end-user, the minimum block of IP address space
>> assigned is a /24. If assignments smaller than a /24 are needed, multihomed
>> end-users should contact their upstream providers. When prefixes are
>> assigned which are smaller than /22, they will be from a block reserved for
>> that purpose so long as that is feasible.
>> 4.3.3. Utilization rate
>>
>> Utilization rate of address space is a key factor in justifying a new
>> assignment of IP address space. Requesters must show exactly how previous
>> address assignments have been utilized and must provide appropriate details
>> to verify their one-year growth projection. The basic criteria that must be
>> met are:
>>
>>    - A 25% immediate utilization rate, and
>>    - A 50% utilization rate within one year.
>>
>> A greater utilization rate may be required based on individual network
>> requirements.
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Scott Leibrand <scottleibrand at gmail.com>
>> Date: Thu, Nov 21, 2013 at 3:03 PM
>> Subject: Bootstrapping new entrants after IPv4 exhaustion
>> To: ARIN-PPML List <arin-ppml at arin.net>
>>
>>
>>  During the discussion in Phoenix of Draft Policy 2013-7 (which I've
>> since updated and will be sending back out to PPML shortly), and in other
>> discussions before and since, it has become apparent that small networks
>> may not qualify for transfers and be unable to get space from their
>> upstreams after RIR and ISP IPv4 free pools run out.
>>
>>  In order to address this issue, a few different ideas have come up, so
>> I wanted to bring some of them up to the community for discussion and see
>> which possible solutions might have community support.
>>
>>  Here are a couple of the ideas that've come up so far:
>>
>>
>>  1) For smaller allocations than ARIN?s minimum, orgs ?should request
>> space from their upstream provider _*or another LIR*_? (add underlined
>> text to NRPM 4.2.1.5 <https://www.arin.net/policy/nrpm.html#four215>).
>>
>>  This would clarify that it's fine for organizations to get space
>> reassigned to them by any other LIR if their upstream ISPs are no longer
>> able to provide them the space they need.
>>
>>
>>  2) Lower the minimum allocation sizes to /22 single-homed and /24
>> multihomed for both ISPs and end-users.  This would mean updating NRPM
>> 4.2.2 <https://www.arin.net/policy/nrpm.html#four22> and 4.3.2<https://www.arin.net/policy/nrpm.html#four32> (and
>> would allow removal of NRPM 4.9<https://www.arin.net/policy/nrpm.html#four9> as
>> redundant.)
>>
>>  Before the implementation of CIDR, many /24 allocations were made to
>> organizations that are no longer using them.  Current ARIN transfer
>> policy <https://www.arin.net/policy/nrpm.html#eight3>states that the
>> minimum transfer size is a /24, but it's not clear in policy whether an
>> single-homed organization that needs a small block (/24 to /21) would
>> actually qualify to receive such a block via transfer.  (Perhaps staff
>> input here would be useful.)  In any event, reducing the minimum allocation
>> sizes would allow organizations of all types to receive the size of address
>> block they actually need, either via transfer or from ARIN's inventory of
>> returned space.
>>
>>  Thoughts?  Do you support either or both of these ideas?  Would one or
>> both of them be worth submitting as a policy proposal?
>>
>>  Thanks,
>> Scott
>>
>>
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/e0839fe2/attachment.htm>

From SRyerse at eclipse-networks.com  Mon Nov 25 17:46:53 2013
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 25 Nov 2013 22:46:53 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz7HthN39RND7LYcQMdifLxFAzmV9L6Lry7yq7+tBHrcFw@mail.gmail.com>
References: <CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.
	com><B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com><52BECAEC-8131-43DD-A6
	AD-D736C982DB61@gmail.com><c0ab2b89291446a9a3c469acc0796f71@BN1PR03MB250.na
	mprd03.prod.outlook.com><5B9E90747FA2974D91A54FCFA1B8AD120143442889@ENI-MAIL.eclipse-networks.com>
	<CAGkMwz7HthN39RND7LYcQMdifLxFAzmV9L6Lry7yq7+tBHrcFw@mail.gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120143442D2D@ENI-MAIL.eclipse-networks.com>

Being that it is an improvement, I could live with David Huberman?s verbiage.  I support what you are trying to accomplish since it is a step in the right direction.

In the big picture as I?ve mentioned before I support an overhaul of current ARIN policies in the same way as this proposal that was submitted over in the RIPE region:

https://www.ripe.net/ripe/policies/proposals/2013-03   and I recognize this would be a significant change to current ARIN policy requiring considerable work by the talented policy makers in this community.  This proposal says it in a much better way than I ever could.  Not sure if you can find language to your liking in it but if you haven?t looked at this then I think it is worth your time.  Cheers!

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Monday, November 25, 2013 4:40 PM
To: Steven Ryerse
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Steven,

Do you have some specific policy language (or can you point to specific language from another region) to illustrate how you think new allocations should be appropriately sized?  I understand that you want something simpler and more liberal than both the current ISP and end-user requirements, but I'm not completely clear on what that would look like.

Thanks,
Scott

On Mon, Nov 25, 2013 at 1:29 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:
My opinion absolutely does not change just because organizations have been made to jump thru unnecessary hoops for 16 years.  I strongly think that needs to be corrected.  Obviously I'm not alone in that opinion given that other's in other regions have made similar proposals.

As I said I agree with and support what Scott is trying to accomplish as it is a slight improvement to the status quo.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460<tel:770.656.1460> - Cell
770.399.9099<tel:770.399.9099>- Office

? Eclipse Networks, Inc.
                     Conquering Complex Networks?


-----Original Message-----
From: David Huberman [mailto:David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>]
Sent: Monday, November 25, 2013 4:23 PM
To: Steven Ryerse; 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Ok, quick question then:

Does your opinion change if I tell you that 4.2.0, 4.2.1, 4.3.0, and 4.3.1 are the exact rules end-users have been subject to for 16 years? ARIN has reviewed thousands and thousands of requests every year under the policy framework described in 4.2.0, 4.2.1, 4.3.0, and 4.3.1.

And a quick observation:

Scott's proposed change isn't big at all.  It just lowers the bar from /22 to /24 (a good thing) using a mechanic that hasn't worked for newer/smaller ISPs (yourself included, Steven, as you told this list many times when you first joined) in a long time.


David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: Steven Ryerse [mailto:SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>]
Sent: Monday, November 25, 2013 1:18 PM
To: David Huberman; 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'
Subject: RE: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

I'm all for eliminating the definition of what constitutes an end user vs. ISP vs. whatever, as it doesn't really matter unless there is a technical issue involved that ARIN needs to manage.  I also agree that it might be easier making smaller steps to fixing these kinds of issues given the dramatic difference of opinion surrounding how blocks should be allocated.

I would point out though that in real life the requirements set out below in Sections 4.2.0, 4.2.1, 4.3.0, and 4.3.1 can all be manipulated and I'm sure that in past real life requests that  ARIN has received and allocated, some organizations have done so to get a successful allocation request filled.  I don't believe ARIN goes back and checks to see if an organization met their predicated allocations in the timeframe policies require.  The requirements based on future usage require us to be able to predict the future and of course none of us really can do that.

I am for what Scott is trying to accomplish.  I know it would be a big change in policy but isn't it finally time to jettison the needs tests altogether and just allocate based on rightsizing blocks allocated to the size of the requesting organization and the size of their existing network and existing allocations.  Requiring organizations to predict the future and fudge their numbers just to get a block allocated is not what we want to incent organizations to do.  Regardless of the original intentions this is just a game organizations are forced to play and why would this community want to force anyone to do that?

Just my two cents.

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
                     Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of David Huberman
Sent: Monday, November 25, 2013 3:46 PM
To: 'arin-ppml at arin.net<mailto:arin-ppml at arin.net>'
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

Scott wrote:

> I'm not sure it's all that helpful to ask me to re-justify the entire
> NRPM. That requirement, in a more strict form, is what is present in the NRPM today.

But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:

4.2.0:

An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1

An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0

4.3.0

An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.3.1

An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0

Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.

Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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<mailto: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<mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/94d3428a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/94d3428a/attachment.jpg>

From owen at delong.com  Mon Nov 25 18:10:38 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 25 Nov 2013 15:10:38 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
Message-ID: <2FD047F9-A153-4EB9-BD8E-2CACDA47F2A3@delong.com>

As I have repeatedly stated. I am opposed to bifurcating the qualifications for space from ARIN vs. space from transfers.

Making transfers more liberal that direct allocations/assignments is already proving harmful and I don?t believe it is good policy 
to expand that dichotomy.

Owen

On Nov 25, 2013, at 10:57 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> Owen,
> 
> I agree with you that we need to avoid the deadly embrace: that is the main reason for proposing this, so we're in full agreement there.
> 
> I'm not sure that it would be a good idea, though, to let any organization, not matter how small, get an IPv4 /24 from ARIN's free pool without any real restrictions.  I am much more comfortable allowing an organization to get such a /24 via transfer, where they have to have at least enough need for the space to justify spending the money for it.
> 
> In any event, I wonder if we should first focus on the less controversial fix, and make sure that anyone who can justify the need for a /24 or larger can get it somehow or other, and separately look into the possibility of portable space for organizations needing less than a /24.
> 
> -Scott
> 
> 
> On Sun, Nov 24, 2013 at 10:02 PM, Owen DeLong <owen at delong.com> wrote:
> Frankly, I don?t think blocking off existing players from getting space they need in order to save space for possible future entrants is good policy.
> 
> I do think we need to make sure that we avoid deadly embrace in the transfer market where new players can?t even get a transfer simply because they can?t get upstream space or meet some other prior-space requirement before being able to seek out space in the transfer market.
> 
> However, I also think it is bad policy to make those policies any more liberal for transfers than they are for what is left of the ARIN free pool.
> 
> Hence, I support something like what Scott has posted, but I believe it is necessary to remove the ?transfer only? clause from it.
> 
> Owen
> 
> On Nov 24, 2013, at 4:18 PM, Bill Darte <billdarte at gmail.com> wrote:
> 
>> New entrants cannot hope to compete in a long term strategy with only limited amounts of v4.  So they will have to go to the transfer market if they need more.  Isn't the transfer market about enabling people who 'really want or need' v4 that opportunity.  But, I agree that having some v4 for start ups is probably still a requirement for now, so I would consider a single small block.....still, if v6 deployment is delayed longer than we hope, then the v4 for new entrants may still run out.  What do we do for those folks.....  We cannot continue to move the deck chairs to forestall the move to v6 forever....
>> 
>> bd
>> 
>> 
>> On Sun, Nov 24, 2013 at 4:58 PM, CJ Aronson <cja at daydream.com> wrote:
>> 
>> 
>> 
>> On Sun, Nov 24, 2013 at 3:08 PM, Owen DeLong <owen at delong.com> wrote:
>> 
>> 
>> Yes, but it limits that use to strictly transitional technology deployment, not general IPv4 utilization.
>> 
>> 
>> I think this is something we should be discussing.  Right now the only post run out policy ARIN has is for the last /10.  You  can get a block (very small) out of this for transition technologies only.  There is no provision for new entrants except the transfer market in the ARIN region.  
>> 
>> So some of us, and Scott started the discussion going, want to clean up the policy manual so that it makes sense for ARIN post run out.  We could also make a policy like in the other regions that gives a specific size block to everyone (or maybe just new entrants?) out of some of the last space.  If we are going to add the second option then time is really short.  
>> 
>> we made the final /10 policy a very long time ago and maybe not everyone realizes it is just for transition? Do people still think this makes sense?  
>> 
>> Thanks!
>> ----Cathy
>> 
>> 
>> 
>> _______________________________________________
>> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131125/58172935/attachment.htm>

From owen at delong.com  Mon Nov 25 18:40:05 2013
From: owen at delong.com (Owen DeLong)
Date: Mon, 25 Nov 2013 15:40:05 -0800
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>
	<CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <21367CC8-441A-48BC-8D94-5CC7885C29C4@delong.com>

I actually like and could support this.

(Though I don?t think it?s a panacea for the ISP vs. end-user debate in its entirety, from a policy perspective, I?m fine with the policy as expressed.)

The one caveat is that I wouldn?t want to see this implemented in such a way that it would potentially interfere with what is currently known as proposal 191 if that achieves consensus (which I think is likely).

Owen

On Nov 25, 2013, at 12:45 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> Scott wrote:
> 
>> I'm not sure it's all that helpful to ask me to re-justify the entire NRPM.  
>> That requirement, in a more strict form, is what is present in the NRPM today.
> 
> But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:
> 
> 4.2.0:
> 
> An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
> 
> 4.2.1
> 
> An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0
> 
> 4.3.0
> 
> An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
> 
> 4.3.1
> 
> An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0
> 
> Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.
> 
> Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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.



From David.Huberman at microsoft.com  Mon Nov 25 18:45:06 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 25 Nov 2013 23:45:06 +0000
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <21367CC8-441A-48BC-8D94-5CC7885C29C4@delong.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<CAGkMwz7PN4j_E3uwthTV2Og53xqj79RpziSpV_E7+9jf2GKuoQ@mail.gmail.com>
	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>
	<5292753A.1060904@quark.net>
	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>
	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>
	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>
	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>
	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>
	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>
	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>
	<203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>
	<CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>
	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>,
	<21367CC8-441A-48BC-8D94-5CC7885C29C4@delong.com>
Message-ID: <c39901e3b3d0488da474270ad50e94aa@BN1PR03MB250.namprd03.prod.outlook.com>

Which one is 191, please?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: Owen DeLong <owen at delong.com>
Sent: Monday, November 25, 2013 3:40:05 PM
To: David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

I actually like and could support this.

(Though I don?t think it?s a panacea for the ISP vs. end-user debate in its entirety, from a policy perspective, I?m fine with the policy as expressed.)

The one caveat is that I wouldn?t want to see this implemented in such a way that it would potentially interfere with what is currently known as proposal 191 if that achieves consensus (which I think is likely).

Owen

On Nov 25, 2013, at 12:45 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> Scott wrote:
>
>> I'm not sure it's all that helpful to ask me to re-justify the entire NRPM.
>> That requirement, in a more strict form, is what is present in the NRPM today.
>
> But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:
>
> 4.2.0:
>
> An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
>
> 4.2.1
>
> An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0
>
> 4.3.0
>
> An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
>
> 4.3.1
>
> An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0
>
> Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.
>
> Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> _______________________________________________
> 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.



From info at arin.net  Tue Nov 26 13:13:10 2013
From: info at arin.net (ARIN)
Date: Tue, 26 Nov 2013 13:13:10 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - November 2013
Message-ID: <5294E4B6.3060406@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 21 November 2013 and made decisions about
draft policies and proposals.

The AC recommended the following to the ARIN Board for adoption:

   Recommended Draft Policy ARIN-2013-4: RIR Principles

The AC accepted the following Proposal as a Draft Policy. It will be
posted separately to the Public Policy Mailing List.

   ARIN-prop-191 Subsequent Allocations for Additional Discrete Network 
Sites

The following remains on the AC's docket:

   Draft Policy ARIN-2013-7: Merge IPv4 ISP and End-User Requirements

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Tue Nov 26 13:13:28 2013
From: info at arin.net (ARIN)
Date: Tue, 26 Nov 2013 13:13:28 -0500
Subject: [arin-ppml] Draft Policy ARIN-2013-8: Subsequent Allocations for
 Additional Discrete Network Sites
Message-ID: <5294E4C8.1060807@arin.net>

On 21 November 2013 the ARIN Advisory Council (AC) accepted 
"ARIN-prop-191 Subsequent Allocations for Additional Discrete Network 
Sites" as a Draft Policy.

Draft Policy ARIN-2013-8 is below and can be found at:
https://www.arin.net/policy/proposals/2013_8.html

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-8 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance 
of this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Draft Policy ARIN-2013-8
Subsequent Allocations for Additional Discrete Network Sites

Date: 26 November 2013

Problem Statement:

During the ARIN 32 PPM, ARIN staff noted in the Policy Implementation
and Experience Report that the current Multiple Discrete Network Policy
(MDN) does not contain criteria for new sites of an existing MDN customer.

Current ARIN practice is to use the Immediate Need policy (NRPM 4.2.1.6).

This policy proposal seeks to add NRPM text to clarify criteria for new
sites of existing MDN customers.

Policy statement:

IPv4:

Add the following statement to section 4.5.4.

Upon verification that the organization has already obtained
connectivity at its new discrete network site, the new networks shall be
allocated the minimum allocation size under section 4.2.1.5 unless the
organization can demonstrate additional need using the immediate need
criteria (4.2.1.6).

IPv6:

Add an additional reference to section 6.11.5.b such that it references
both the initial allocation and subsequent allocation sections of the
IPv6 LIR policy.

"Each network will be judged against the existing utilization criteria
specified in 6.5.2 and 6.5.3 as if it were a separate organization..."

Comments:
a. Timetable for implementation: immediate
b. This policy is being proposed based upon the Policy Implementation
& Experience Report from ARIN 32.

https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
c: Older versions of the MDN policy did contain new network criteria.
This criteria appears to have been dropped during subsequent
rewrites of the MDN policy. "The organization must not allocate a CIDR
block larger than the current minimum assignment
size of the RIR (currently /20 for ARIN) to a new network."
(https://www.arin.net/policy/archive/nrpm_20041015.pdf)


From jschiller at google.com  Tue Nov 26 14:20:15 2013
From: jschiller at google.com (Jason Schiller)
Date: Tue, 26 Nov 2013 14:20:15 -0500
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <674736349.148507.1385160036022.JavaMail.zimbra@network1.net>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<674736349.148507.1385160036022.JavaMail.zimbra@network1.net>
Message-ID: <CAC4yj2WWofS9TNEkabwxJJ7cujp2nBNAc2yO8aqDgSQ4WVr+YA@mail.gmail.com>

I think the easy fix here is remove the requirement to already be using a
/20, and instead have them provide strong justification about how the
addresses will be used in the next 90 days for ISPs, in the next year for
end sites, and in the next two years for transfers.

I'm thinking something like immediate need, where they have some real data
to show how the addresses will be used, but not necessarily in the next 30
days.

Possibly VC commitment to spend on purchasing 3,000 servers (each booking 1
IP) or 3,000 residential customer pre-orders, or 1,500 residential customer
pre-orders, and a business plan to use revenue booked to deploy a second
equally sized market in the time.

Basically if you have the IP justification to get a /20 from your ISP, then
submit that to ARIN and get a /21 slow start.  Use it and come back.

___Jason



On Fri, Nov 22, 2013 at 5:40 PM, Randy Carpenter <rcarpen at network1.net>wrote:

>
> I have several single-homed clients who are in the position of having a
> /23 or /22 from an upstream, and needing additional space. They are refused.
>
> They have a justified need, and are established networks, but ARIN policy
> prevents them from getting their own space because they don't already have
> a /20. At this point in the game the requirement of having space before you
> can get space seems a little ridiculous, particularly at the current
> minimums. If they were able to get their own space, they could hand back
> most or all of the upstream space, thus providing a benefit to them as well.
>
> I am very in favor of moving the minimums to /22 for single-homed at
> least. I would also be in favor of only requiring an upstream allocation of
> a /24, so long as the ISP can show justified need for a full /22.
>
> For multi-homed, I would be fine with either /23 or /24.
>
>
> thanks,
> -Randy
>
> ----- Original Message -----
> > David,
> >
> > There are going to be lots of reasons why an ISP can't provide space to a
> > downstream post run out, even when on paper they have space.
> >
> > 1) Space dedicated to another region
> > 2) Cost Prohibitive for downstream due to cost recovery.
> > 3) Forward looking project that fits within the 24 month window.
> >
> > I can see the conversation now.
> >
> > Downstream: I need a /24 of IP space
> > Upstream: NO
> > Downstream: Ok, I'm telling on you.
> > Upstream: We didn't sign the contract, find someone else to provide
> service.
> >
> > In a primary market there are going to be "others". In a secondary
> market you
> > will be out of luck.
> >
> > We can't wrap this policy in a complicated beat stick. If a company has a
> > need for an initial allocation
> > They are going to have to go to the transfer market. We should be able to
> > give them the initial allocation without adding complexity.
> >
> > Thanks,
> >
> > Kevin
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of David Farmer
> > Sent: Friday, November 22, 2013 2:26 PM
> > To: Brandon Ross; Jo Rhett
> > Cc: ARIN-PPML List
> > Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
> >
> > On 11/22/13, 08:50 , Brandon Ross wrote:
> > > On Thu, 21 Nov 2013, Jo Rhett wrote:
> > >
> > >> I'd like to see some actual documented issues with this. Almost
> > >> everyone I know is sitting on large amounts of smaller blocks they
> > >> can easily allocate to people. It's the larger (/21 or greater)
> > >> blocks which are becoming scarce.
> > >
> > > What kind of documentation are you looking for?
> >
> > I would think an a copy of an email or a letter from the upstream which
> > confirms the upstream can't/won't provide them address space, for some
> > reason other than they don't think the customer justifies additional
> address
> > space.
> >
> > It is unfair for ARIN to withhold address space because the upstream has
> > address space but won't provide it to the requester for what ever
> reason.  I
> > think it is reasonable to require some confirming documentation that the
> > upstream is not providing address space.  You can't just "say" your ISP
> is
> > not providing it.
> >
> > However, if an ISP is saying you don't justify additional address space,
> then
> > you shouldn't qualify for address space from ARIN under an exception like
> > this.
> >
> > Also, ARIN should be able to refuse if they feel there is collusion
> between
> > an ISP and a requester.
> >
> > Thanks.
> > --
> > ================================================
> > David Farmer               Email: farmer at umn.edu
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE     Phone: 1-612-626-0815
> > Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> > ================================================
> > _______________________________________________
> > 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.
> >
> >
> _______________________________________________
> 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.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131126/572d127b/attachment.htm>

From hannigan at gmail.com  Tue Nov 26 17:13:10 2013
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 26 Nov 2013 18:13:10 -0400
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <52918292.50808@bogus.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<CAC6JZKRG0roxv7TukttRB=o4MDqpECT+dLDP-P6To-Re1PcTdw@mail.gmail.com>
	<52918292.50808@bogus.com>
Message-ID: <CAMDXq5MidvyxYCGgURGp+J=zhcVQPeVnfi0vaUTDtvhUyg1owA@mail.gmail.com>

On Sun, Nov 24, 2013 at 12:37 AM, joel jaeggli <joelja at bogus.com> wrote:

> On 11/22/13, 2:32 PM, CJ Aronson wrote:
> > This is why RIPE and APNIC both have their last /8 policy.  Anyone can
> > get a /22 once out of the last /8 (til there are no more).  Both are now
> > signing up tons of new customers.   Both are generating a large amount
> > of revenue.   The small guys can all get their /22.  Just sayin'
>
> Revenue generation is wierdly, not goal of RIR operation.
>
>


That revenue comment speaks volumes.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131126/b56a1d40/attachment.htm>

From jcurran at arin.net  Tue Nov 26 21:02:13 2013
From: jcurran at arin.net (John Curran)
Date: Wed, 27 Nov 2013 02:02:13 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>

On Nov 25, 2013, at 11:06 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> All this talk about "new entrants" with no data basis for what's being discussed.
> 
> ARIN this question is for you.  In 2013 YTD:
> 
> - how many assignments of IPv4 were issued to end-users.
> Then:
> - how many assignments of IPv4 were issued to end-users who didn't previously have direct space from ARIN? (1)
> 
> Repeat for ISPs:
> - how many allocations of IPv4 were issued to ISPs.
> Then:
> - how many allocations of IPv4 were issued to ISPs who didn't previously have direct space from ARIN (1)
> 
> Thanks
> /david
> 
> (1) Ignore the possibility of multiple accounts for the same company; they're statistical outliers and make data collection much more difficult


David - 

As requested - 

End users:

  682 assignments 2013 YTD, 584 (86%) to new entrants
  10,353 /24s issued in assignments 2013 YTD, 6,475 /24s (63%) to new entrants

ISPs:

  1234 allocations 2013 YTD, 387 (31%) to new entrants
  66,637 /24s issued in allocations 2013 YTD, 5,520 /24s (8%) to new entrants

Overall:

  1916 blocks issued 2013 YTD, 971 (51%) to new entrants
  76,990 /24s issued 2013 YTD, 11,995 /24s (16%) to new entrants

("new entrants" defined as organizations which did not have a direct IPv4 
registration from ARIN prior to 2013)

FYI,
/John

John Curran
President and CEO
ARIN





From billdarte at gmail.com  Wed Nov 27 06:02:03 2013
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 27 Nov 2013 05:02:03 -0600
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <CAC4yj2WWofS9TNEkabwxJJ7cujp2nBNAc2yO8aqDgSQ4WVr+YA@mail.gmail.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>
	<C09D9D89-3FEB-45B9-BBA9-18CD36D3A05F@netconsonance.com>
	<alpine.OSX.2.02.1311220949020.1809@brugal.local>
	<528FAFBF.606@umn.edu>
	<7E7773B523E82C478734E793E58F69E78D4D0F88@SBS2011.thewireinc.local>
	<674736349.148507.1385160036022.JavaMail.zimbra@network1.net>
	<CAC4yj2WWofS9TNEkabwxJJ7cujp2nBNAc2yO8aqDgSQ4WVr+YA@mail.gmail.com>
Message-ID: <CAMApp37YcbD4wPjzzeqbneWfASNHpSNna3giPPuEQM0O1y2z7Q@mail.gmail.com>

Jason,
I agree with you....that seems to be my biggest objection.
bd


On Tue, Nov 26, 2013 at 1:20 PM, Jason Schiller <jschiller at google.com>wrote:

> I think the easy fix here is remove the requirement to already be using a
> /20, and instead have them provide strong justification about how the
> addresses will be used in the next 90 days for ISPs, in the next year for
> end sites, and in the next two years for transfers.
>
> I'm thinking something like immediate need, where they have some real data
> to show how the addresses will be used, but not necessarily in the next 30
> days.
>
> Possibly VC commitment to spend on purchasing 3,000 servers (each booking
> 1 IP) or 3,000 residential customer pre-orders, or 1,500 residential
> customer pre-orders, and a business plan to use revenue booked to deploy a
> second equally sized market in the time.
>
> Basically if you have the IP justification to get a /20 from your ISP,
> then submit that to ARIN and get a /21 slow start.  Use it and come back.
>
> ___Jason
>
>
>
> On Fri, Nov 22, 2013 at 5:40 PM, Randy Carpenter <rcarpen at network1.net>wrote:
>
>>
>> I have several single-homed clients who are in the position of having a
>> /23 or /22 from an upstream, and needing additional space. They are refused.
>>
>> They have a justified need, and are established networks, but ARIN policy
>> prevents them from getting their own space because they don't already have
>> a /20. At this point in the game the requirement of having space before you
>> can get space seems a little ridiculous, particularly at the current
>> minimums. If they were able to get their own space, they could hand back
>> most or all of the upstream space, thus providing a benefit to them as well.
>>
>> I am very in favor of moving the minimums to /22 for single-homed at
>> least. I would also be in favor of only requiring an upstream allocation of
>> a /24, so long as the ISP can show justified need for a full /22.
>>
>> For multi-homed, I would be fine with either /23 or /24.
>>
>>
>> thanks,
>> -Randy
>>
>> ----- Original Message -----
>> > David,
>> >
>> > There are going to be lots of reasons why an ISP can't provide space to
>> a
>> > downstream post run out, even when on paper they have space.
>> >
>> > 1) Space dedicated to another region
>> > 2) Cost Prohibitive for downstream due to cost recovery.
>> > 3) Forward looking project that fits within the 24 month window.
>> >
>> > I can see the conversation now.
>> >
>> > Downstream: I need a /24 of IP space
>> > Upstream: NO
>> > Downstream: Ok, I'm telling on you.
>> > Upstream: We didn't sign the contract, find someone else to provide
>> service.
>> >
>> > In a primary market there are going to be "others". In a secondary
>> market you
>> > will be out of luck.
>> >
>> > We can't wrap this policy in a complicated beat stick. If a company has
>> a
>> > need for an initial allocation
>> > They are going to have to go to the transfer market. We should be able
>> to
>> > give them the initial allocation without adding complexity.
>> >
>> > Thanks,
>> >
>> > Kevin
>> > -----Original Message-----
>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> > Behalf Of David Farmer
>> > Sent: Friday, November 22, 2013 2:26 PM
>> > To: Brandon Ross; Jo Rhett
>> > Cc: ARIN-PPML List
>> > Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4
>> exhaustion
>> >
>> > On 11/22/13, 08:50 , Brandon Ross wrote:
>> > > On Thu, 21 Nov 2013, Jo Rhett wrote:
>> > >
>> > >> I'd like to see some actual documented issues with this. Almost
>> > >> everyone I know is sitting on large amounts of smaller blocks they
>> > >> can easily allocate to people. It's the larger (/21 or greater)
>> > >> blocks which are becoming scarce.
>> > >
>> > > What kind of documentation are you looking for?
>> >
>> > I would think an a copy of an email or a letter from the upstream which
>> > confirms the upstream can't/won't provide them address space, for some
>> > reason other than they don't think the customer justifies additional
>> address
>> > space.
>> >
>> > It is unfair for ARIN to withhold address space because the upstream has
>> > address space but won't provide it to the requester for what ever
>> reason.  I
>> > think it is reasonable to require some confirming documentation that the
>> > upstream is not providing address space.  You can't just "say" your ISP
>> is
>> > not providing it.
>> >
>> > However, if an ISP is saying you don't justify additional address
>> space, then
>> > you shouldn't qualify for address space from ARIN under an exception
>> like
>> > this.
>> >
>> > Also, ARIN should be able to refuse if they feel there is collusion
>> between
>> > an ISP and a requester.
>> >
>> > Thanks.
>> > --
>> > ================================================
>> > David Farmer               Email: farmer at umn.edu
>> > Office of Information Technology
>> > University of Minnesota
>> > 2218 University Ave SE     Phone: 1-612-626-0815
>> > Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>> > ================================================
>> > _______________________________________________
>> > 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.
>> >
>> >
>> _______________________________________________
>> 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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131127/150cf3b0/attachment.htm>

From mcr at sandelman.ca  Wed Nov 27 08:54:29 2013
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 27 Nov 2013 08:54:29 -0500
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
Message-ID: <18699.1385560469@sandelman.ca>


Thank you for these stats.
Numbers always cause more questions.

John Curran <jcurran at arin.net> wrote:
    > 682 assignments 2013 YTD, 584 (86%) to new entrants
    > 10,353 /24s issued in assignments 2013 YTD, 6,475 /24s (63%) to new
    > entrants

I'm understanding the term /24s here to be a gauge of quantity,
I think that most of the /24s were in fact given out in the form of /22s and
/21s and /20s...?

Is it easy to understand how many of the new-entrants asked for IPv6 space?
What is the distribution of allocation sizes new-entrants?
How did they qualify?   I would assume most had demonstrated exhaustion of
PA space they got from their upstream.

After a new-entrant returns their PA space upstream, does ARIN have any
statistics (from delegation records) on what happens to that address space
afterwards?  Does upstream ISP deploy it to new customers? How fast?
Or does upstream ISP tend to use it for internal uses?  Do upstream ISPs keep
it quiet for a cool-down period?

--
]               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    [




From jcurran at arin.net  Wed Nov 27 10:17:52 2013
From: jcurran at arin.net (John Curran)
Date: Wed, 27 Nov 2013 15:17:52 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <18699.1385560469@sandelman.ca>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
Message-ID: <51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>

On Nov 27, 2013, at 8:54 AM, Michael Richardson <mcr at sandelman.ca> wrote:

> 
> Thank you for these stats.
> Numbers always cause more questions.
> 
> John Curran <jcurran at arin.net> wrote:
>> 682 assignments 2013 YTD, 584 (86%) to new entrants
>> 10,353 /24s issued in assignments 2013 YTD, 6,475 /24s (63%) to new
>> entrants
> 
> I'm understanding the term /24s here to be a gauge of quantity,
> I think that most of the /24s were in fact given out in the form of /22s and
> /21s and /20s...?

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.

> Is it easy to understand how many of the new-entrants asked for IPv6 space?

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.

> What is the distribution of allocation sizes new-entrants?

We can generate this is necessary; the mean is approximately  14 /24 equivalents 
per new requester. 

> How did they qualify?   I would assume most had demonstrated exhaustion of
> PA space they got from their upstream.

Correct - this is required as part of initial ISP allocations.

> After a new-entrant returns their PA space upstream, does ARIN have any
> statistics (from delegation records) on what happens to that address space
> afterwards?  Does upstream ISP deploy it to new customers? How fast?
> Or does upstream ISP tend to use it for internal uses?  Do upstream ISPs keep
> it quiet for a cool-down period?

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)

FYI,
/John

John Curran
President and CEO
ARIN







From David.Huberman at microsoft.com  Wed Nov 27 10:33:50 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 27 Nov 2013 15:33:50 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>,
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
Message-ID: <6a47f761812c49b292cb67c55519eaac@BN1PR03MB250.namprd03.prod.outlook.com>

Thank you for collecting these stats.  I think they clearly show that "new entrants" are a very significant group for ARIN Policy to pay attention to.

86% of all end user requests issued in 2013YTD were new requestors -- that's very significant, I think.

31% of all ISP requests issued in 2013YTD were new requestors -- showing (I think) that there's still room for new entrants in an otherwise-saturated marketplace in North America and the Carribean.

So when thinking about policy updates, I think it behooves us to respect the needs of new entrants.

Just my opinion, but I feel it's well supported by the data.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: John Curran <jcurran at arin.net>
Sent: Tuesday, November 26, 2013 6:02:13 PM
To: David Huberman
Cc: ppml at arin.net
Subject: Statistics request regarding new entrants (was: Re: [arin-ppml] Stats request)

On Nov 25, 2013, at 11:06 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> All this talk about "new entrants" with no data basis for what's being discussed.
>
> ARIN this question is for you.  In 2013 YTD:
>
> - how many assignments of IPv4 were issued to end-users.
> Then:
> - how many assignments of IPv4 were issued to end-users who didn't previously have direct space from ARIN? (1)
>
> Repeat for ISPs:
> - how many allocations of IPv4 were issued to ISPs.
> Then:
> - how many allocations of IPv4 were issued to ISPs who didn't previously have direct space from ARIN (1)
>
> Thanks
> /david
>
> (1) Ignore the possibility of multiple accounts for the same company; they're statistical outliers and make data collection much more difficult


David -

As requested -

End users:

  682 assignments 2013 YTD, 584 (86%) to new entrants
  10,353 /24s issued in assignments 2013 YTD, 6,475 /24s (63%) to new entrants

ISPs:

  1234 allocations 2013 YTD, 387 (31%) to new entrants
  66,637 /24s issued in allocations 2013 YTD, 5,520 /24s (8%) to new entrants

Overall:

  1916 blocks issued 2013 YTD, 971 (51%) to new entrants
  76,990 /24s issued 2013 YTD, 11,995 /24s (16%) to new entrants

("new entrants" defined as organizations which did not have a direct IPv4
registration from ARIN prior to 2013)

FYI,
/John

John Curran
President and CEO
ARIN





From farmer at umn.edu  Wed Nov 27 12:15:12 2013
From: farmer at umn.edu (David Farmer)
Date: Wed, 27 Nov 2013 11:15:12 -0600
Subject: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
In-Reply-To: <c39901e3b3d0488da474270ad50e94aa@BN1PR03MB250.namprd03.prod.outlook.com>
References: <CAGkMwz4OnH9GLW1WeWBdQRJ3Tff=euOE5i7WLnmg1WkEhdw7hg@mail.gmail.com>	<CAGkMwz714awmwJt6og1Gn8nobEdadkc=koBch8OLz9MdGseiSA@mail.gmail.com>	<5292753A.1060904@quark.net>	<B4A84936-B457-4A19-B7E9-322CE52DC958@delong.com>	<CAC6JZKTB6YQ-sCqe6f31jV5J4uooj-QKD1Mt1r+MS-hjhMivaQ@mail.gmail.com>	<CAMApp37VH+wEW62RjXpwqK7rth_2S14C+t+2Es9fjjdi78Q2Qg@mail.gmail.com>	<314DB6A0-F495-4445-B92B-2567815D7C95@delong.com>	<CAGkMwz4Ob8hXNppt3=ktcqQdxUhKtx16A0-o0MxSSGxqtav3+Q@mail.gmail.com>	<e6470c71ce834d2481469f8468a01466@BN1PR03MB250.namprd03.prod.outlook.com>	<52BECAEC-8131-43DD-A6AD-D736C982DB61@gmail.com>	<203d8ba441e240e58832243c36010133@BN1PR03MB250.namprd03.prod.outlook.com>	<CAGkMwz47JQWRSpjyMXd1ycjAjxM+tcAdA5=MzMPT5chfsojWvg@mail.gmail.com>	<850a412669b3482eaf36148e2b43e7e3@BN1PR03MB250.namprd03.prod.outlook.com>,
	<21367CC8-441A-48BC-8D94-5CC7885C29C4@delong.com>
	<c39901e3b3d0488da474270ad50e94aa@BN1PR03MB250.namprd03.prod.outlook.com>
Message-ID: <529628A0.7050301@umn.edu>

FYI, Proposal 191, was just advanced as Draft Policy ARIN-2013-8 
"Subsequent Allocations for Additional Discrete Network Sites"

On 11/25/13, 17:45 , David Huberman wrote:
> Which one is 191, please?
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> ________________________________________
> From: Owen DeLong <owen at delong.com>
> Sent: Monday, November 25, 2013 3:40:05 PM
> To: David Huberman
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Bootstrapping new entrants after IPv4 exhaustion
>
> I actually like and could support this.
>
> (Though I don?t think it?s a panacea for the ISP vs. end-user debate in its entirety, from a policy perspective, I?m fine with the policy as expressed.)
>
> The one caveat is that I wouldn?t want to see this implemented in such a way that it would potentially interfere with what is currently known as proposal 191 if that achieves consensus (which I think is likely).
>
> Owen
>
> On Nov 25, 2013, at 12:45 PM, David Huberman <David.Huberman at microsoft.com> wrote:
>
>> Scott wrote:
>>
>>> I'm not sure it's all that helpful to ask me to re-justify the entire NRPM.
>>> That requirement, in a more strict form, is what is present in the NRPM today.
>>
>> But we can't make policy for policy's sake. ARIN exists to, in part, provide number resources to the operator community who needs them.  Section 4 of the NRPPM serves the needs of the network operator community circa 1996, not 2014 and beyond.   So how about:
>>
>> 4.2.0:
>>
>> An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
>>
>> 4.2.1
>>
>> An ISP can obtain an additional allocations by demonstrating 80% or better utilization of existing address space. The additional allocation block size determination uses the criterion in 4.2.0
>>
>> 4.3.0
>>
>> An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need to use at least 25% of the space within 90 days, and at least 50% of the space within one year.
>>
>> 4.3.1
>>
>> An end-user can obtain an additional assignment by demonstrating 80% or better utilization of existing address space. The additional assignment block size determination uses the criterion in 4.3.0
>>
>> Throw in a section on SWIP, keep 4.5 MDN as-is, and presto, you're done with section 4, and you've fixed NRPM 8.3 and you've harmonized the very broken ISP v End-user mechanic.
>>
>> Doesn't this serve the network operator community in 2014 better than making small changes to walls and walls of text from 1996?
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>> _______________________________________________
>> 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.
>


-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From owen at delong.com  Wed Nov 27 12:30:05 2013
From: owen at delong.com (Owen DeLong)
Date: Wed, 27 Nov 2013 09:30:05 -0800
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
Message-ID: <B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>


On Nov 27, 2013, at 07:17 , John Curran <jcurran at arin.net> wrote:

> On Nov 27, 2013, at 8:54 AM, Michael Richardson <mcr at sandelman.ca> wrote:
> 
>> 
>> Thank you for these stats.
>> Numbers always cause more questions.
>> 
>> John Curran <jcurran at arin.net> wrote:
>>> 682 assignments 2013 YTD, 584 (86%) to new entrants
>>> 10,353 /24s issued in assignments 2013 YTD, 6,475 /24s (63%) to new
>>> entrants
>> 
>> I'm understanding the term /24s here to be a gauge of quantity,
>> I think that most of the /24s were in fact given out in the form of /22s and
>> /21s and /20s...?
> 
> 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.

I have seen a few examples of this, myself, as well.

This problem will definitely continue to get worse as we get closer to runout.

>> Is it easy to understand how many of the new-entrants asked for IPv6 space?
> 
> 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.

>> After a new-entrant returns their PA space upstream, does ARIN have any
>> statistics (from delegation records) on what happens to that address space
>> afterwards?  Does upstream ISP deploy it to new customers? How fast?
>> Or does upstream ISP tend to use it for internal uses?  Do upstream ISPs keep
>> it quiet for a cool-down period?
> 
> 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.

Owen




From jcurran at arin.net  Wed Nov 27 12:56:44 2013
From: jcurran at arin.net (John Curran)
Date: Wed, 27 Nov 2013 17:56:44 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
Message-ID: <493B7454-660C-4AE5-BBDE-FDCD47D3B891@arin.net>

On Nov 27, 2013, at 12:30 PM, Owen DeLong <owen at delong.com> wrote:

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

I have heard similar concerns expressed anecdotally.

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

If this is important information for folks to have for the development of 
number resource policy, we can assemble these stats.  Would it be helpful
for us to do so?

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

Correct - we do not in general have visibility into this aspect of the
policy.

/John

John Curran
President and CEO
ARIN



From cja at daydream.com  Wed Nov 27 14:14:33 2013
From: cja at daydream.com (CJ Aronson)
Date: Wed, 27 Nov 2013 12:14:33 -0700
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <493B7454-660C-4AE5-BBDE-FDCD47D3B891@arin.net>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<493B7454-660C-4AE5-BBDE-FDCD47D3B891@arin.net>
Message-ID: <CAC6JZKTwNSV1oEjmm_=TG01+JLd1ui-7fzkQnCiYr5Fg_Y6Cfw@mail.gmail.com>

On Wed, Nov 27, 2013 at 10:56 AM, John Curran <jcurran at arin.net> wrote:

> On Nov 27, 2013, at 12:30 PM, Owen DeLong <owen at delong.com> wrote:
>
> > 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.
>
> I have heard similar concerns expressed anecdotally.
>
>
I hosted the lunch topic table at the last ARIN meeting that addressed
problems faced by small ISPs.   Everyone at this topic table faced the
issue we are discussing.   They can't get blocks from their upstream and
they can't justify blocks from ARIN.  Hopefully some of those folks will
speak up here too.

----Cathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20131127/c0c67539/attachment.htm>

From David.Huberman at microsoft.com  Wed Nov 27 17:07:56 2013
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 27 Nov 2013 22:07:56 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <CAC6JZKTwNSV1oEjmm_=TG01+JLd1ui-7fzkQnCiYr5Fg_Y6Cfw@mail.gmail.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<493B7454-660C-4AE5-BBDE-FDCD47D3B891@arin.net>,
	<CAC6JZKTwNSV1oEjmm_=TG01+JLd1ui-7fzkQnCiYr5Fg_Y6Cfw@mail.gmail.com>
Message-ID: <42272b313fb442d69b2848ec1ae788e7@BN1PR03MB250.namprd03.prod.outlook.com>

Owen wrote:

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

JC wrote:

> I have heard similar concerns expressed anecdotally.

CJ wrote:
?
> I hosted the lunch topic table at the last ARIN meeting that addressed problems 
> faced by small ISPs. ? Everyone at this topic table faced the issue we are discussing. ?
> They can't get blocks from their upstream and they can't justify blocks from ARIN. 
> Hopefully some of those folks will speak up here too. ?
?
This has been a problem for a long time.  The genesis is section 4.2 of the NRPM, which 
prescribes mechanics which were necessary, and worked, in the mid-to-late 1990s, but
aren't necessary now, and are actually pretty unfair to new and small businesses.  NRPM
4.2 has the unfortunate side effect of giving a competitive advantage to larger (or more 
established) ISPs.

As an ARIN hostmaster for 10 years, I worked with engineers from lots of ISP 
organizations who had difficulty dealing with an upstream -- especially in more rural 
areas where they had very little (if any) choice in who they do business with.

Secondly, the mechanic of "you must use space from an upstream first" is not only
anti-competitive, but it's bad engineering.  Forcing everyone to renumber at least once
(and that's only the folks clueful enough to design a long-term numbering plan that
has only one renumbering round) is not necessary.  We aren't desperate for routing slots 
like in 1996.

I believe NRPM 4.2 should be forward looking, and thus read something like:

4.2.0:
An ISP can obtain an initial allocation of a /24 or larger by demonstrating a need to use 
at least 25% of the space within 90 days, and at least 50% of the space within one year.

4.2.1
An ISP can obtain an additional allocations by demonstrating 80% or better utilization 
of existing address space. The additional allocation block size determination uses the 
criterion in 4.2.0

Then we streamline 4.3 (for end-users) so it looks like:

4.3.0
An end-user can obtain an initial assignment of a /24 or larger by demonstrating a need 
to use at least 25% of the space within 90 days, and at least 50% of the space within one 
year.

4.3.1
An end-user can obtain an additional assignment by demonstrating 80% or better 
utilization of existing address space. The additional assignment block size determination 
uses the criterion in 4.3.0

Then throw in a SWIP section, preserve 4.5 (MDN), and voila, you've updated NRPM 4 to 
be relevant in 2014.  It would remove ARIN policy's very unfair slant to large networks. It
would even out the playing field. 

Remember: one out of every three ISP requests that ARIN fulfills are from new entrants.  
Equality is important.  Good engineering is important, too.


David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)


From mcr at sandelman.ca  Wed Nov 27 19:51:53 2013
From: mcr at sandelman.ca (mcr at sandelman.ca)
Date: Wed, 27 Nov 2013 19:51:53 -0500
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
Message-ID: <7653.1385599913@sandelman.ca>


John Curran <jcurran at arin.net> wrote:
    >> How did they qualify?   I would assume most had demonstrated
    >>exhaustion of 
    >> PA space they got from their upstream.

    > Correct - this is required as part of initial ISP allocations.

They can also qualify by 4.2.1.6, Immediate Need.
I don't know how often that happens for new entrants.

    >> After a new-entrant returns their PA space upstream, does ARIN have any
    >> statistics (from delegation records) on what happens to that address space
    >> afterwards?  Does upstream ISP deploy it to new customers? How fast?
    >> Or does upstream ISP tend to use it for internal uses?  Do upstream ISPs keep
    >> it quiet for a cool-down period?

    > 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) 

I agree that there is no formal visibility, but one might see this through
SWIP's. 

-- 
]               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    [ 
	




From mcr at sandelman.ca  Wed Nov 27 19:56:14 2013
From: mcr at sandelman.ca (mcr at sandelman.ca)
Date: Wed, 27 Nov 2013 19:56:14 -0500
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
Message-ID: <8533.1385600174@sandelman.ca>


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    [ 
	





From owen at delong.com  Thu Nov 28 03:41:44 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 28 Nov 2013 00:41:44 -0800
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <8533.1385600174@sandelman.ca>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<8533.1385600174@sandelman.ca>
Message-ID: <A9097875-D2EB-4E00-92C1-9B77C07DC286@delong.com>


On Nov 27, 2013, at 16:56 , mcr at sandelman.ca wrote:

> 
> 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:

First, we have struggled to keep policy agnostic and I don't believe that making
policy to force new entrants to inflict translation services on users is a particularly
good policy choice.

Second, even if we choose to make such a move (which I think would be grossly
unfair among its other flaws), it would have to be translation technology agnostic
at least.

>  a) enough breathing room to demonstrate need.

I don't see how.

>  b) we could then count the IPv6 networks.

This would require much more complicated changes to policy than anything that
is currently being proposed and I'm not sure what the perceived advantage would
be.

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

Sure, but ARIN can't really control that and has limited ability to influence it.

The closest ARIN can come is measuring what ARIN has done in terms of
allocations and assignments. I will point out that allocating or assigning IPv4
also doesn't necessarily mean that it got deployed or advertised, either.

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

I'm not sure I understand your question here. Who are you seeking for ARIN to
ask what question?

We ask the downstream to return before we will grant the downstream a subsequent
direct allocation. The upstream isn't really involved other than (at least theoretically)
receiving the return.

In my experience there is a wide variance in the diligence of upstreams in processing
these returns which ranges from an extreme of not even noticing that the space was
returned and only removing it from SWIP or RWHOIS under substantial pressure from
the (often now desperate) downstream that long since returned the space to the other
extreme of placing it readily into their free pool and allocating almost immediately to
new customers with all manners of variation between those two extremes.

In my estimation (which is fairly close to a SWAG but based on significant industry
experience and conversations with a number of providers over many years), there
are far more providers somewhere closer to the extremely inattentive end of the
spectrum than the aggressively recycling end of the spectrum.

Owen



From mcr at sandelman.ca  Thu Nov 28 09:33:40 2013
From: mcr at sandelman.ca (mcr at sandelman.ca)
Date: Thu, 28 Nov 2013 09:33:40 -0500
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <A9097875-D2EB-4E00-92C1-9B77C07DC286@delong.com>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<8533.1385600174@sandelman.ca>
	<A9097875-D2EB-4E00-92C1-9B77C07DC286@delong.com>
Message-ID: <10781.1385649220@sandelman.ca>


Owen DeLong <owen at delong.com> wrote:
    > In my experience there is a wide variance in the diligence of upstreams
    > in processing these returns which ranges from an extreme of not even
    > noticing that the space was returned and only removing it from SWIP or
    > RWHOIS under substantial pressure from the (often now desperate)
    > downstream that long since returned the space to the other extreme of
    > placing it readily into their free pool and allocating almost
    > immediately to new customers with all manners of variation between
    > those two extremes.

    > In my estimation (which is fairly close to a SWAG but based on
    > significant industry experience and conversations with a number of
    > providers over many years), there are far more providers somewhere
    > closer to the extremely inattentive end of the spectrum than the
    > aggressively recycling end of the spectrum.

If upstream tends to ignore, then what's the point of making the downstream
return?    Seriously.

It's in upstream's interest to ignore, as it makes it is easier for them to
qualify for another block if they don't notice they have spare.

So it seems to me that ARIN needs to do an audit on blocks returned to
upstream should upstream ask for more space.  

Maybe there is a lot more space out there available for new entrants than we
think.   

-- 
]               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    [ 
	




From jcurran at arin.net  Thu Nov 28 09:53:32 2013
From: jcurran at arin.net (John Curran)
Date: Thu, 28 Nov 2013 14:53:32 +0000
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
 Stats request)
In-Reply-To: <10781.1385649220@sandelman.ca>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<8533.1385600174@sandelman.ca>
	<A9097875-D2EB-4E00-92C1-9B77C07DC286@delong.com>
	<10781.1385649220@sandelman.ca>
Message-ID: <5C42C9DF-2552-4725-AB37-749FFF44F62B@arin.net>

On Nov 28, 2013, at 9:33 AM, <mcr at sandelman.ca> <mcr at sandelman.ca> wrote:

> If upstream tends to ignore, then what's the point of making the downstream
> return?    Seriously.
> 
> It's in upstream's interest to ignore, as it makes it is easier for them to
> qualify for another block if they don't notice they have spare.
> 
> So it seems to me that ARIN needs to do an audit on blocks returned to
> upstream should upstream ask for more space.  

We are happy to administer whatever policy the community develops, but try to 
avoid creating additional administrative steps in implementation beyond those
clearly called for in policy.  We do take steps to check reported utilization,
but presently do not systemically record the upstream block and likely date of 
return to enable such auditing.  If this is considered important, then some 
guidance (similar to NRPM 4.6.4 "Timeframe for return") would be quite helpful.

Thanks! (and Happy Holidays!)
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Thu Nov 28 13:48:56 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 28 Nov 2013 10:48:56 -0800
Subject: [arin-ppml] Statistics request regarding new entrants (was: Re:
	Stats request)
In-Reply-To: <10781.1385649220@sandelman.ca>
References: <a1fd40d96cd74aee831eb27d6ed47125@BN1PR03MB250.namprd03.prod.outlook.com>
	<EFBFF9BC-E517-47F1-88F4-6DA194495754@arin.net>
	<18699.1385560469@sandelman.ca>
	<51E7AAAB-8783-44BE-A769-4E3BD72CF6C9@arin.net>
	<B724F08D-2359-44BF-9529-A8193AD86A5A@delong.com>
	<8533.1385600174@sandelman.ca>
	<A9097875-D2EB-4E00-92C1-9B77C07DC286@delong.com>
	<10781.1385649220@sandelman.ca>
Message-ID: <58B613BF-131E-4950-8273-3980C35755E9@delong.com>


On Nov 28, 2013, at 06:33 , mcr at sandelman.ca wrote:

> 
> Owen DeLong <owen at delong.com> wrote:
>> In my experience there is a wide variance in the diligence of upstreams
>> in processing these returns which ranges from an extreme of not even
>> noticing that the space was returned and only removing it from SWIP or
>> RWHOIS under substantial pressure from the (often now desperate)
>> downstream that long since returned the space to the other extreme of
>> placing it readily into their free pool and allocating almost
>> immediately to new customers with all manners of variation between
>> those two extremes.
> 
>> In my estimation (which is fairly close to a SWAG but based on
>> significant industry experience and conversations with a number of
>> providers over many years), there are far more providers somewhere
>> closer to the extremely inattentive end of the spectrum than the
>> aggressively recycling end of the spectrum.
> 
> If upstream tends to ignore, then what's the point of making the downstream
> return?    Seriously.
> 
> It's in upstream's interest to ignore, as it makes it is easier for them to
> qualify for another block if they don't notice they have spare.
> 
> So it seems to me that ARIN needs to do an audit on blocks returned to
> upstream should upstream ask for more space.  

I believe that happens, but not all upstreams end up asking for more space.

> 
> Maybe there is a lot more space out there available for new entrants than we
> think.   

If you measure it in terms of the number of years of useful life for IPv4 gained
vs. the number of years required to reclaim said space, it's most definitely a
strongly losing proposition.

In reality, IPv4 has been on life support, circling the drain for many years. The
first nails in the coffin came with the first implementations of NAT when we
(unfortunately) made the shift from a peer to peer network to an entirely client/
content provider model which has not actually served us all that well. There are
many applications and capabilities that have been severely hindered by this
model.

If you want to see significant examples, you can look at any of the various home
automation, health care, and other connected devices. Even home entertainment
services like TiVO are severely hampered by this situation.

On the other hand, services like "Back to My Mac" and "Go To My PC", etc.
wouldn't exist if it weren't for the need to overcome the limitations created by
NAT, so I suppose some would argue that is a good thing. To me, it just seems
like an additional unnecessary cost.

Owen

From narten at us.ibm.com  Fri Nov 29 08:08:36 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 29 Nov 2013 08:08:36 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201311291308.rATD8akt027075@rotala.raleigh.ibm.com>

Total of 68 messages in the last 7 days.
 
script run at: Fri Nov 29 08:08:36 EST 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 11.76% |    8 | 23.70% |   247991 | scottleibrand at gmail.com
 13.24% |    9 | 13.54% |   141655 | owen at delong.com
 13.24% |    9 |  6.93% |    72554 | david.huberman at microsoft.com
  1.47% |    1 | 15.76% |   164887 | andrew.dul at quark.net
  5.88% |    4 |  9.07% |    94850 | sryerse at eclipse-networks.com
  8.82% |    6 |  3.75% |    39204 | mcr at sandelman.ca
  8.82% |    6 |  3.59% |    37613 | jcurran at arin.net
  5.88% |    4 |  4.14% |    43267 | cja at daydream.com
  4.41% |    3 |  2.70% |    28235 | farmer at umn.edu
  2.94% |    2 |  3.28% |    34303 | billdarte at gmail.com
  4.41% |    3 |  1.71% |    17883 | csquat at ccsd.net
  2.94% |    2 |  1.39% |    14532 | serge at skycomp.ca
  2.94% |    2 |  1.16% |    12126 | info at arin.net
  1.47% |    1 |  2.05% |    21424 | jschiller at google.com
  1.47% |    1 |  1.30% |    13551 | bjones at vt.edu
  1.47% |    1 |  1.22% |    12754 | jrhett at netconsonance.com
  1.47% |    1 |  1.10% |    11505 | joelja at bogus.com
  1.47% |    1 |  0.90% |     9467 | rcarpen at network1.net
  1.47% |    1 |  0.74% |     7765 | kevinb at thewire.ca
  1.47% |    1 |  0.72% |     7513 | hannigan at gmail.com
  1.47% |    1 |  0.66% |     6887 | bross at pobox.com
  1.47% |    1 |  0.60% |     6330 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   68 |100.00% |  1046296 | Total