From joelja at bogus.com  Sat Aug  1 14:37:28 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Sat, 01 Aug 2009 20:37:28 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A732E7E.9030706@rollernet.us>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com><C6978482.971EB%mksmith@adhost.com>	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
	<4A732E7E.9030706@rollernet.us>
Message-ID: <4A748B68.9010800@bogus.com>

Seth Mattinen wrote:
> Michael K. Smith - Adhost wrote:

>>> Does that mean you actually used *less* BGP slots after getting
>>> your ARIN addresses? So in your case, current ARIN policy was
>>> actually counterproductive to its goal, causing you to announce
>>> *more* routes, yes?
>>> 
>>> 
>> That is correct.  When we went to ARIN space, this was in 1995 mind
>> you, we went from 6 announced PA blocks to one PI block.  But, we
>> had to keep getting PA blocks until we could justify the block from
>> ARIN. 

ARIN didn't exist in 1995.

>> This happened again in 2000 with another company when we
>> went from 4 PA blocks to one PI block.
>> 


From mksmith at adhost.com  Sat Aug  1 15:33:58 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Sat, 01 Aug 2009 12:33:58 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A748B68.9010800@bogus.com>
Message-ID: <C699E6B6.97F1C%mksmith@adhost.com>




On 8/1/09 11:37 AM, "Joel Jaeggli" <joelja at bogus.com> wrote:

> Seth Mattinen wrote:
>> Michael K. Smith - Adhost wrote:
> 
>>>> Does that mean you actually used *less* BGP slots after getting
>>>> your ARIN addresses? So in your case, current ARIN policy was
>>>> actually counterproductive to its goal, causing you to announce
>>>> *more* routes, yes?
>>>> 
>>>> 
>>> That is correct.  When we went to ARIN space, this was in 1995 mind
>>> you, we went from 6 announced PA blocks to one PI block.  But, we
>>> had to keep getting PA blocks until we could justify the block from
>>> ARIN. 
> 
> ARIN didn't exist in 1995.
> 
Mea Culpa.

RegDate:    1997-02-07

Mike



From leo.vegoda at icann.org  Mon Aug  3 06:07:02 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 3 Aug 2009 03:07:02 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A71D11D.16321.6D69D78@farmer.umn.edu>
Message-ID: <C69C04D6.26F4C%leo.vegoda@icann.org>

On 30/07/2009 2:58, "David Farmer" <farmer at umn.edu> wrote:

[...]

> When the IANA free pool reaches 20 or fewer /8s, an
> organization may choose to request up to a 6 month supply of
> IP addresses;
> 
> When the IANA free pool reaches 10 or fewer /8s, an
> organization may choose to request up to a 3 month supply of
> IP addresses;

I think the term "IANA free pool" needs to be unambiguously defined in order
to understand your text. The current "Global Policy for the Allocation of
the Remaining IPv4 Address Space" states that the five /8s set aside for the
final allocation to the RIRs are "no longer be part of the available space
at the IANA pool" and so might confuse things.

Do you intend to include those five /8s? In order to avoid the possibility
of misinterpretation, it might be clearest to use a phrase like "unallocated
IPv4 /8s" or something like that.

Regards,

Leo Vegoda



From farmer at umn.edu  Mon Aug  3 08:16:41 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 03 Aug 2009 07:16:41 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <C69C04D6.26F4C%leo.vegoda@icann.org>
References: <4A71D11D.16321.6D69D78@farmer.umn.edu>,
	<C69C04D6.26F4C%leo.vegoda@icann.org>
Message-ID: <4A768ED9.31775.195BCD7D@farmer.umn.edu>

On 3 Aug 2009 Leo Vegoda wrote:

> On 30/07/2009 2:58, "David Farmer" <farmer at umn.edu> wrote:
> 
> [...]
> 
> > When the IANA free pool reaches 20 or fewer /8s, an
> > organization may choose to request up to a 6 month supply of
> > IP addresses;
> > 
> > When the IANA free pool reaches 10 or fewer /8s, an
> > organization may choose to request up to a 3 month supply of
> > IP addresses;
> 
> I think the term "IANA free pool" needs to be unambiguously defined in order
> to understand your text. The current "Global Policy for the Allocation of
> the Remaining IPv4 Address Space" states that the five /8s set aside for the
> final allocation to the RIRs are "no longer be part of the available space
> at the IANA pool" and so might confuse things.
> 
> Do you intend to include those five /8s? In order to avoid the possibility
> of misinterpretation, it might be clearest to use a phrase like "unallocated
> IPv4 /8s" or something like that.

As written, the intent is to include the five reserved /8s.  I agree this need to 
be clearified.

So how about; 

When IANA reaches 20 or fewer unallocated /8s , an organization may 
choose to request up to a 6 month supply of IP addresses;  

When IANA reaches 10 or fewer unallocated /8s , an organization may 
choose to request up to a 3 month supply of IP addresses;  

And then add the following as the second paragraph of the Rationale;

The reductions in the length of supply will be triggered by IANA reaching 
defined levels of unallocated /8s, including the /8s reserved as part of section 
10.4 of the NRPM.  These triggers have been chosen base on the current 
rate of consumption of /8s by the RIRs.


> Regards,
> 
> Leo Vegoda
> 



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



From leo.vegoda at icann.org  Mon Aug  3 09:47:01 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 3 Aug 2009 06:47:01 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A768ED9.31775.195BCD7D@farmer.umn.edu>
Message-ID: <C69C3865.26F73%leo.vegoda@icann.org>

On 03/08/2009 5:16, "David Farmer" <farmer at umn.edu> wrote:

[...]

>> I think the term "IANA free pool" needs to be unambiguously defined in order
>> to understand your text. The current "Global Policy for the Allocation of
>> the Remaining IPv4 Address Space" states that the five /8s set aside for the
>> final allocation to the RIRs are "no longer be part of the available space
>> at the IANA pool" and so might confuse things.
>> 
>> Do you intend to include those five /8s? In order to avoid the possibility
>> of misinterpretation, it might be clearest to use a phrase like "unallocated
>> IPv4 /8s" or something like that.
> 
> As written, the intent is to include the five reserved /8s.  I agree this need
> to
> be clearified.
> 
> So how about;
> 
> When IANA reaches 20 or fewer unallocated /8s , an organization may
> choose to request up to a 6 month supply of IP addresses;
> 
> When IANA reaches 10 or fewer unallocated /8s , an organization may
> choose to request up to a 3 month supply of IP addresses;
> 
> And then add the following as the second paragraph of the Rationale;
> 
> The reductions in the length of supply will be triggered by IANA reaching
> defined levels of unallocated /8s, including the /8s reserved as part of
> section
> 10.4 of the NRPM.  These triggers have been chosen base on the current
> rate of consumption of /8s by the RIRs.

I think that's nice and clear.

Regards,

Leo



From stephen at sprunk.org  Mon Aug  3 11:30:08 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 03 Aug 2009 10:30:08 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <C6978482.971EB%mksmith@adhost.com>
References: <C6978482.971EB%mksmith@adhost.com>
Message-ID: <4A770280.4050007@sprunk.org>

Michael K. Smith wrote:
> What was the rationale for the /20 in the first place?  Was it more than an arbitrary number?

IIRC, it was a compromise between the folks wanting to be PI and the
folks who didn't want their routers to explode.  When routers got
bigger, the minimum went down to /22.

> I can't see any detraction from getting providers to get an ARIN-assigned /24 instead of having to get a /24 from one provider and route it out another, being historically on the "purchasing" side of that arrangement. 

There is one major difference: if you get a /24 from your upstream and
other folks in the DFZ filter it, you can still be reached via your
upstream's aggregate.  If you have a PI /24, there is a much greater
chance of breakage.

> The only downside I can see is providers that think having a customer with their assigned space somehow binds them together, fiscally speaking.
>   

Yes, lock-in is a serious issue.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/f3603176/attachment.bin>

From kkargel at polartel.com  Mon Aug  3 11:55:09 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 10:55:09 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com><20090730175643.GB76331@ussenterprise.ufp.org>
	<3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E41@mail>

Top post, sorry.

So long as the longer mask allocations are the single and sole allocation
for the organization, and assuming that the organization would get a shorter
mask allocation if they cannot get the longer one, then there would be no
net difference to the global routing table size.  A slot is a slot.  

The problem comes when/if an organization starts collecting multiple long
mask allocations, each of which take up a slot (or two) when they cannot be
efficiently aggregated.  Another problematic scenario would be if
organizations were created for the sole purpose of getting a long mask
allocation for whatever reason.

If, on the other hand, the organization would opt to utilize non portable
space from an upstream provider if they couldn't get a long mask allocation
then there would be conservation of table size.  It might mean only saving
one slot out of two, but it would exist.

What I was trying last week (ever so badly) to get someone else to point out
were two points:

1. That if I allocate small space to my multihomed customer I can no longer
treat that space as part of my allocation. It is allocated to the customer
and must be routed as such. This creates complexity in my network.  If I do
treat their allocation as within my block then stuff breaks.
2. Given circumstance 1 a case can be made that the customer may as well get
their smaller allocation directly from ARIN, again assuming it is a sole
allocation.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, July 30, 2009 4:48 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Thu, Jul 30, 2009 at 1:56 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> > I think many folks miss the most important item though when considering
> > the effects of minimum allocation size, or other polices that are
> > likely to affect the size of the global table.
> 
> Hi Leo,
> 
> If I may draw it back to the question I started with: Can you offer a
> well grounded reason to believe that changing the minimum allocation
> size for *multihomed* systems is likely to affect the size of the
> global table?
> 
> The only one I've been able to come up with goes something along the
> lines of, "If we reduce the minimum allocation size, more folks will
> multihome yielding more table consumption." That seems pretty weak in
> light of NRPM 4.2.3.6.
> 
> A couple of folks have said something along the lines of "you can
> aggregate mutlihomed users anyway," but as you know those arguments
> turn on some basic misunderstandings about how BGP works.
> 
> Another suggested that the minimums allow a convenient place to filter
> when trying to preserve older hardware a little longer, but as you
> know such filtering is just as functional (or dysfunctional) at any
> prefix size, not just the RIR minimums. At most, the RIR minimums give
> the BOFH somewhere to [disingenuously] point his finger when his
> customers complain.
> 
> Like you, still others have pointed out that if every single-homed
> user announced a route the Internet would collapse. That is not in
> dispute. RIRs assigning addresses to single-homed users would increase
> the route table size. PI for single-homed users is frankly a
> discussion for another era. In BGP/IPv4, that ship has sailed. My
> question covers only multihomed uses, and my real focus is multivendor
> multihomed uses where route aggregation is impractical regardless of
> who assigns the addresses.
> 
> So can you offer a justifiable reason to believe that changing the RIR
> minimum allocation size for *multihomed* systems is likely to affect
> the size of the global table?
> 
> Regards,
> Bill
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/9cfcd6fe/attachment.bin>

From kkargel at polartel.com  Mon Aug  3 12:14:24 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 11:14:24 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com><4A71F1C0.999.7561B2A@farmer.umn.edu><20090731033041.GA14598@ussenterprise.ufp.org>
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>

One quick point on the existance or emergence of small multi-homed
networks..

In the past year and a half I have seen a very noticeable increase in the
number of small organizations that are going or attempting to go multi-homed
with DSL connections to multiple upstream providers.  They are doing this as
a means to try and do what they did before with expensive dedicated circuits
like T1.  Increased reliability of a $39.95 SDSL has led these customers
down the primrose path to think that if they have a couple of these then
they don't need an $800 ATM circuit.  

I am not saying I agree with this philosophy or even that I think it is
functional, but I am seeing it happen.

As these customers get educated they figure out that they are technically
"multi-homed" and that they "can" get their own IP space, and if they invest
in a router that can do BGP they can gain transparent (to the end user)
routing reliability using these DSL connections.  Bean counters tend to
prefer non-recurring expenditures to recurring expenditures.  

These organizations are small hospitals, clinics, small banks, farmers,
insurance agencies, non-chain manufacturers and distributers, et.al.  They
don't need a lot of IP, but they do need routing failover.  They are
learning that it is theoretically (albeit not realistically) possible to do
what used to require a T1 on SDSL better for a fraction of the cost.  

I believe we will see a mushrooming incidence of these small multi-homed
organizations in the routing tables in the coming years.  

This will affect the issue of global routing table size and does have a
bearing on reducing the minimum allocation unit.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/41dcb7fc/attachment.bin>

From bill at herrin.us  Mon Aug  3 12:17:21 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 12:17:21 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A770280.4050007@sprunk.org>
References: <C6978482.971EB%mksmith@adhost.com> <4A770280.4050007@sprunk.org>
Message-ID: <3c3e3fca0908030917t673a7290iaac9d71c47d51661@mail.gmail.com>

On Mon, Aug 3, 2009 at 11:30 AM, Stephen Sprunk<stephen at sprunk.org> wrote:
>> I can't see any detraction from getting providers to get an
>> ARIN-assigned /24 instead of having to get a /24 from one provider
>> and route it out another, being historically on the "purchasing"
>> side of that arrangement.
>
> There is one major difference: if you get a /24 from your upstream and
> other folks in the DFZ filter it, you can still be reached via your
> upstream's aggregate. ?If you have a PI /24, there is a much greater
> chance of breakage.

Hi Stephen,

We've discussed this point several times in this thread. The bottom
line: nobody actually does this any more, at least not that we've been
able to identify.

In the 2009 backbone, you either carry "full" routes down to /24 or
you carry partial routes and a default. The default takes you to
someone who does carry full routes. Whether those partials are
composed by filtering on the RIR minimums or using some other criteria
(e.g. distant routes) makes little difference.

IMHO, that's the reality on the ground that ARIN policy should target,
not a hypothetical network in which folks carry partial routes without
a default and it works out for them.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kkargel at polartel.com  Mon Aug  3 12:46:42 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 11:46:42 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0908030917t673a7290iaac9d71c47d51661@mail.gmail.com>
References: <C6978482.971EB%mksmith@adhost.com> <4A770280.4050007@sprunk.org>
	<3c3e3fca0908030917t673a7290iaac9d71c47d51661@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E44@mail>

> 
> On Mon, Aug 3, 2009 at 11:30 AM, Stephen Sprunk<stephen at sprunk.org> wrote:
> >> I can't see any detraction from getting providers to get an
> >> ARIN-assigned /24 instead of having to get a /24 from one provider
> >> and route it out another, being historically on the "purchasing"
> >> side of that arrangement.
> >
> > There is one major difference: if you get a /24 from your upstream and
> > other folks in the DFZ filter it, you can still be reached via your
> > upstream's aggregate. ?If you have a PI /24, there is a much greater
> > chance of breakage.
> 
> Hi Stephen,
> 
> We've discussed this point several times in this thread. The bottom
> line: nobody actually does this any more, at least not that we've been
> able to identify.
> 
> In the 2009 backbone, you either carry "full" routes down to /24 or
> you carry partial routes and a default. The default takes you to
> someone who does carry full routes. Whether those partials are
> composed by filtering on the RIR minimums or using some other criteria
> (e.g. distant routes) makes little difference.
> 
> IMHO, that's the reality on the ground that ARIN policy should target,
> not a hypothetical network in which folks carry partial routes without
> a default and it works out for them.
> 
> Regards,
> Bill Herrin
> 
As a piece of trivia, I know of one small multihomed ISP who runs BGP to
announce routes, carries no routes at all except for direct connected peers
and has two default routes with some rather complex priorities and mapping
to upstreams that do carry full routes and it seems to work quite well for
them.  

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/7eb8a36c/attachment.bin>

From jlewis at lewis.org  Mon Aug  3 13:55:43 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 3 Aug 2009 13:55:43 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E44@mail>
References: <C6978482.971EB%mksmith@adhost.com> <4A770280.4050007@sprunk.org>
	<3c3e3fca0908030917t673a7290iaac9d71c47d51661@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E44@mail>
Message-ID: <Pine.LNX.4.61.0908031347470.4187@soloth.lewis.org>

On Mon, 3 Aug 2009, Kevin Kargel wrote:

>> In the 2009 backbone, you either carry "full" routes down to /24 or
>> you carry partial routes and a default. The default takes you to
>> someone who does carry full routes. Whether those partials are
>> composed by filtering on the RIR minimums or using some other criteria
>> (e.g. distant routes) makes little difference.
>>
>> IMHO, that's the reality on the ground that ARIN policy should target,
>> not a hypothetical network in which folks carry partial routes without
>> a default and it works out for them.
>>
> As a piece of trivia, I know of one small multihomed ISP who runs BGP to
> announce routes, carries no routes at all except for direct connected peers
> and has two default routes with some rather complex priorities and mapping
> to upstreams that do carry full routes and it seems to work quite well for
> them.

That's really not at all relevant and can be considered a subset of 
filtered routes + default.

AFAIK, it's not an uncommon setup.  I have multiple customers doing it as 
they wanted to multihome to protected against single circuit or single 
provider failures, but didn't want the expense of one or more routers big 
enough to deal with full routes.  These customers effectively have a 
primary and a backup internet provider.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From farmer at umn.edu  Mon Aug  3 14:01:38 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 03 Aug 2009 13:01:38 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>,
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>,
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
Message-ID: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>

On 3 Aug 2009 Kevin Kargel wrote:

> One quick point on the existance or emergence of small multi-homed
> networks..
> 
> In the past year and a half I have seen a very noticeable increase in the
> number of small organizations that are going or attempting to go multi-homed
> with DSL connections to multiple upstream providers.  They are doing this as
> a means to try and do what they did before with expensive dedicated circuits
> like T1.  Increased reliability of a $39.95 SDSL has led these customers
> down the primrose path to think that if they have a couple of these then
> they don't need an $800 ATM circuit.  
> 
> I am not saying I agree with this philosophy or even that I think it is
> functional, but I am seeing it happen.
> 
> As these customers get educated they figure out that they are technically
> "multi-homed" and that they "can" get their own IP space, and if they invest
> in a router that can do BGP they can gain transparent (to the end user)
> routing reliability using these DSL connections.  Bean counters tend to
> prefer non-recurring expenditures to recurring expenditures.  
> 
> These organizations are small hospitals, clinics, small banks, farmers,
> insurance agencies, non-chain manufacturers and distributers, et.al.  They
> don't need a lot of IP, but they do need routing failover.  They are
> learning that it is theoretically (albeit not realistically) possible to do
> what used to require a T1 on SDSL better for a fraction of the cost.  
> 
> I believe we will see a mushrooming incidence of these small multi-homed
> organizations in the routing tables in the coming years.  
> 
> This will affect the issue of global routing table size and does have a
> bearing on reducing the minimum allocation unit.  

This is exactly the situation that providing PI /24s could create 
the inducement for many more users to multihome that I was 
refering to and then create the tipping point Leo was refering 
to.

Thinking a little out side the box here and I'm not even sure 
something like this would be legal, it might be considered 
colluding.  What if a pair of providers or maybe even a set of 
providers were to jointly obtain a block of addresses to allow 
customers to multihome.  Customers would connect to two or 
more participating providers, announce there block to the 
providers and then the providers contain the customer 
announcements within there joint infrastructure and only 
announce the aggeraget to the Internet.

As I said I'm not sure how to set this up legaly and we would 
probablly need ARIN policy to enable it, as I beieve it would 
probablly violate one or two policies.

As I don't work for an ISP, I'm not sure this could work from a 
business model point of view either.  It would definitely take a 
set of ISP with an enlightened view of competition to make it 
work.

Could something like this work?  

I'm sure I'm missing one or two details.  But, at least Kevin's 
anecdote makes me think there could be a market for such a 
service.  And with this kind of a solution end-users could 
multihome down to a /28 or /29 without creating minutia in the 
global route table.



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



From tedm at ipinc.net  Mon Aug  3 14:03:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 03 Aug 2009 11:03:26 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com><4A71F1C0.999.7561B2A@farmer.umn.edu><20090731033041.GA14598@ussenterprise.ufp.org>	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
Message-ID: <4A77266E.9010904@ipinc.net>

Kevin Kargel wrote:
> One quick point on the existance or emergence of small multi-homed
> networks..
> 
> In the past year and a half I have seen a very noticeable increase in the
> number of small organizations that are going or attempting to go multi-homed
> with DSL connections to multiple upstream providers.  They are doing this as
> a means to try and do what they did before with expensive dedicated circuits
> like T1.  Increased reliability of a $39.95 SDSL has led these customers
> down the primrose path to think that if they have a couple of these then
> they don't need an $800 ATM circuit.  
> 
> I am not saying I agree with this philosophy or even that I think it is
> functional, but I am seeing it happen.
> 
> As these customers get educated they figure out that they are technically
> "multi-homed" and that they "can" get their own IP space,

No, they can't because they aren't really multihomed.

> and if they invest
> in a router that can do BGP they can gain transparent (to the end user)
> routing reliability using these DSL connections.

Very few ISP's provide BGP over DSL.  We are the only one in our city
that does, as a matter of fact.

> Bean counters tend to
> prefer non-recurring expenditures to recurring expenditures.  
> 
> These organizations are small hospitals, clinics, small banks, farmers,
> insurance agencies, non-chain manufacturers and distributers, et.al.  They
> don't need a lot of IP, but they do need routing failover.  They are
> learning that it is theoretically (albeit not realistically) possible to do
> what used to require a T1 on SDSL better for a fraction of the cost.  
> 
> I believe we will see a mushrooming incidence of these small multi-homed
> organizations in the routing tables in the coming years.  
> 
> This will affect the issue of global routing table size and does have a
> bearing on reducing the minimum allocation unit.  
>

I don't think so, Kevin.  The main reason for this is that all of the 
small "2 DSL multihomed" routers that are on the market operate on
the same principle, they expect 2 DSL lines that are PPP-mode DSL.
The router uses a single NAT translation table with 2 default routes
and some fancy load-balancing programming that puts half of the 
translation sessions on one default and the other half on the other
default.

 From the outside if the org is fielding servers internally, the
org publishes both IP numbers for the server forward - with the
caveat that if one of the DSL sessions goes down then connectivity
to the internal server is intermittent.  Obviously, you would have
severe problems fielding any kind of serious server behind such
a thing - like a DNS server for example.

NAT is an essential and required component of these schemes because
these routers are mainly load-balancing OUTBOUND requests for HTTP
traffic and suchlike.

These routers are cheap, generally under $200 or so.  The orgs that
deploy these solutions are generally very satisfied with them because
their primary purpose is failover, so that if one of their DSL lines 
goes down, they still can surf the web.  But their understanding of
failover is pretty much limited to that - when you tell them that an
upstream ISP of theirs could lose it's connectivity, yet their little
router wouldn't detect this, you generally get blank stares.

Trying to convince an org like you have described to toss out their
little sub $200 "load balancing" NAT/router and go to a real router that
costs 20 times more that can speak BGP is an exercise in futility.
They have a solution that gets them 90% of the way towards real
multihoming, is cheap, and does that 90% really well.  And most
importantly, they don't have to actually understand anything at all
about networking, they just plug it in and go.

Ted




From bill at herrin.us  Mon Aug  3 14:12:26 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 14:12:26 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A76DFB2.11465.1A979EFA@farmer.umn.edu>
Message-ID: <3c3e3fca0908031112x4b0be3ao45a7bfba7b2e30b3@mail.gmail.com>

On Mon, Aug 3, 2009 at 2:01 PM, David Farmer<farmer at umn.edu> wrote:
> Thinking a little out side the box here and I'm not even sure
> something like this would be legal, it might be considered
> colluding. ?What if a pair of providers or maybe even a set of
> providers were to jointly obtain a block of addresses to allow
> customers to multihome. ?Customers would connect to two or
> more participating providers, announce there block to the
> providers and then the providers contain the customer
> announcements within there joint infrastructure and only
> announce the aggeraget to the Internet.
>
> As I don't work for an ISP, I'm not sure this could work from a
> business model point of view either. ?It would definitely take a
> set of ISP with an enlightened view of competition to make it
> work.
>
> Could something like this work?

Hi David,

Yes and no.

Malfunctions inside or between the ISPs announcing the aggregate could
break it for all of downstream users. Suck the packets into the
malfunctioning ISP and drop them on the floor. However, as a "poor
man's multihoming" it could provide a platform for solving the more
common "oops my T1 is down" problem without having to announce the
route world-wide.

But the telling factor is this: ISPs don't do it now. Nothing prevents
two or several ISPs from doing a joint venture and having the JV
request addresses from ARIN for precisely this sort of scenario. But
they don't because of the complexity and because folks who want
multihoming and can afford to do BGP at all tend to want real
multihoming rather than a stripped down version.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From tedm at ipinc.net  Mon Aug  3 14:20:52 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 03 Aug 2009 11:20:52 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>,
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>,
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A76DFB2.11465.1A979EFA@farmer.umn.edu>
Message-ID: <4A772A84.4050800@ipinc.net>

David Farmer wrote:
> On 3 Aug 2009 Kevin Kargel wrote:
> 
>> One quick point on the existance or emergence of small multi-homed
>> networks..
>>
>> In the past year and a half I have seen a very noticeable increase in the
>> number of small organizations that are going or attempting to go multi-homed
>> with DSL connections to multiple upstream providers.  They are doing this as
>> a means to try and do what they did before with expensive dedicated circuits
>> like T1.  Increased reliability of a $39.95 SDSL has led these customers
>> down the primrose path to think that if they have a couple of these then
>> they don't need an $800 ATM circuit.  
>>
>> I am not saying I agree with this philosophy or even that I think it is
>> functional, but I am seeing it happen.
>>
>> As these customers get educated they figure out that they are technically
>> "multi-homed" and that they "can" get their own IP space, and if they invest
>> in a router that can do BGP they can gain transparent (to the end user)
>> routing reliability using these DSL connections.  Bean counters tend to
>> prefer non-recurring expenditures to recurring expenditures.  
>>
>> These organizations are small hospitals, clinics, small banks, farmers,
>> insurance agencies, non-chain manufacturers and distributers, et.al.  They
>> don't need a lot of IP, but they do need routing failover.  They are
>> learning that it is theoretically (albeit not realistically) possible to do
>> what used to require a T1 on SDSL better for a fraction of the cost.  
>>
>> I believe we will see a mushrooming incidence of these small multi-homed
>> organizations in the routing tables in the coming years.  
>>
>> This will affect the issue of global routing table size and does have a
>> bearing on reducing the minimum allocation unit.  
> 
> This is exactly the situation that providing PI /24s could create 
> the inducement for many more users to multihome that I was 
> refering to and then create the tipping point Leo was refering 
> to.
> 
> Thinking a little out side the box here and I'm not even sure 
> something like this would be legal, it might be considered 
> colluding.  What if a pair of providers or maybe even a set of 
> providers were to jointly obtain a block of addresses to allow 
> customers to multihome.  Customers would connect to two or 
> more participating providers, announce there block to the 
> providers and then the providers contain the customer 
> announcements within there joint infrastructure and only 
> announce the aggeraget to the Internet.
> 
> As I said I'm not sure how to set this up legaly and we would 
> probablly need ARIN policy to enable it, as I beieve it would 
> probablly violate one or two policies.
> 
> As I don't work for an ISP, I'm not sure this could work from a 
> business model point of view either.  It would definitely take a 
> set of ISP with an enlightened view of competition to make it 
> work.
> 
> Could something like this work?  
> 

It could work and it would be legal.  The problem is that
it wouldn't last.  Remember, DSL/cable customers are least-cost
customers. (Hey, I have DSL at my house!)  All that would happen is the
customer would set this up, then observe both of their connections
for a year to 6 months.  After doing this they would decide which
ISP was more reliable and just cut service with the other ISP
to save money.

So you can imagine what would happen if, say, ISP A and ISP B
join forces to do this, then ISP A markets this solution to
their userbase, and then finds 6 months later that a user
which they had spent sales and marketing dollars to get on
to their own network, then spent more sales and marketing
dollars to pitch this multihomed solution to, just up and
disconnects from them and makes ISP B their only ISP.

This is why you don't see Pepsi Co running the "Pepsi Challenge"
advertising campaign much anymore.  They found out that
longtime Pepsi drinkers were taking the challenge and some
of them were preferring Coke, then switching to it.

There's big risks to advertising for your competition.

Ted


From kkargel at polartel.com  Mon Aug  3 14:21:56 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 13:21:56 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A77266E.9010904@ipinc.net>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com><4A71F1C0.999.7561B2A@farmer.umn.edu><20090731033041.GA14598@ussenterprise.ufp.org>	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A77266E.9010904@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E47@mail>

> 
> Kevin Kargel wrote:
> > One quick point on the existance or emergence of small multi-homed
> > networks..
> >
> > In the past year and a half I have seen a very noticeable increase in
> the
> > number of small organizations that are going or attempting to go multi-
> homed
> > with DSL connections to multiple upstream providers.  They are doing
> this as
> > a means to try and do what they did before with expensive dedicated
> circuits
> > like T1.  Increased reliability of a $39.95 SDSL has led these customers
> > down the primrose path to think that if they have a couple of these then
> > they don't need an $800 ATM circuit.
> >
> > I am not saying I agree with this philosophy or even that I think it is
> > functional, but I am seeing it happen.
> >
> > As these customers get educated they figure out that they are
> technically
> > "multi-homed" and that they "can" get their own IP space,
> 
> No, they can't because they aren't really multihomed.

Please educate me, if they have more than one connection to the internet it
was my understanding they were multi-homed.  I do not recall any
specification on the type of connection as a requirement to be multi-homed. 

Technically there is nothing stopping an organization from being multi-homed
with a collection of 56K dialup accounts.

> 
> > and if they invest
> > in a router that can do BGP they can gain transparent (to the end user)
> > routing reliability using these DSL connections.
> 
> Very few ISP's provide BGP over DSL.  We are the only one in our city
> that does, as a matter of fact.

The Big Bells won't do it, and I suspect the larger ISP's won't do it, but
there are plenty of small ISP's around the country who will.  In fact their
admins might even think it would be a fun experiment.

> 
> > Bean counters tend to
> > prefer non-recurring expenditures to recurring expenditures.
> >
> > These organizations are small hospitals, clinics, small banks, farmers,
> > insurance agencies, non-chain manufacturers and distributers, et.al.
> They
> > don't need a lot of IP, but they do need routing failover.  They are
> > learning that it is theoretically (albeit not realistically) possible to
> do
> > what used to require a T1 on SDSL better for a fraction of the cost.
> >
> > I believe we will see a mushrooming incidence of these small multi-homed
> > organizations in the routing tables in the coming years.
> >
> > This will affect the issue of global routing table size and does have a
> > bearing on reducing the minimum allocation unit.
> >
> 
> I don't think so, Kevin.  The main reason for this is that all of the
> small "2 DSL multihomed" routers that are on the market operate on
> the same principle, they expect 2 DSL lines that are PPP-mode DSL.
> The router uses a single NAT translation table with 2 default routes
> and some fancy load-balancing programming that puts half of the
> translation sessions on one default and the other half on the other
> default.

It is easily done with a Cisco SoHo router (or with a SonicWall for that
matter). Any routing device (can you say Linux?) that will run BGP and allow
you to forward IP and customize the LAN network will do. Bridge two DSL
modems to act as media converters, configure your router WAN ports for
PPPoE, get your upstreams to assign static or persistant IP's to your PPPoE
authentication, and you are off and running.  

It is also eminently doable using DD-WRT.


> 
>  From the outside if the org is fielding servers internally, the
> org publishes both IP numbers for the server forward - with the
> caveat that if one of the DSL sessions goes down then connectivity
> to the internal server is intermittent.  Obviously, you would have
> severe problems fielding any kind of serious server behind such
> a thing - like a DNS server for example.

So long as the upstream providers accept and promulgate your BGP
advertisements I don't see the problem.

> 
> NAT is an essential and required component of these schemes because
> these routers are mainly load-balancing OUTBOUND requests for HTTP
> traffic and suchlike.

That is why the orgs that want to do this need to invest ($500 or more) in a
real router.  A residential grade router won't do it right, I agree.

> 
> These routers are cheap, generally under $200 or so.  The orgs that
> deploy these solutions are generally very satisfied with them because
> their primary purpose is failover, so that if one of their DSL lines
> goes down, they still can surf the web.  But their understanding of
> failover is pretty much limited to that - when you tell them that an
> upstream ISP of theirs could lose it's connectivity, yet their little
> router wouldn't detect this, you generally get blank stares.
> 
> Trying to convince an org like you have described to toss out their
> little sub $200 "load balancing" NAT/router and go to a real router that
> costs 20 times more that can speak BGP is an exercise in futility.
> They have a solution that gets them 90% of the way towards real
> multihoming, is cheap, and does that 90% really well.  And most
> importantly, they don't have to actually understand anything at all
> about networking, they just plug it in and go.

I am not saying everyone will want to do it, or even that a majority of
those that can will opt to do it, I am just saying that some fringe element
*is* doing it.  I will also predict that we will see more organizations
doing it in the future.

> 
> Ted
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/a3f5f452/attachment.bin>

From bill at herrin.us  Mon Aug  3 14:28:54 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 14:28:54 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
Message-ID: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>

A hundred messages later, here's a summary of the discussion on
lowering the ARIN minimum allocation for Multihomed organizations:

1. Singlehomed and single-vendor multihomed uses a priori excluded
from the discussion. Single-homed users' routes are aggregable with
the ISP's if assigned by the ISP. If assigned by ARIN they're not
aggregable. Multi-vendor multihomed users' routes are not aggregable
regardless of who assigns them. Hence it is appropriate to consider
the two cases (multihomed, not multihomed) separately.

2. Current ARIN minimum allocation is /22 for multihomed
organizations. Defacto Internet backbone routing minimum is /24.

3. RIR minimums are about routing. They help suppress the growth of
the backbone BGP table by encouraging aggregability. They appear to
serve no other purpose and are actually counterproductive to ARIN's
companion goal of allocating the minimum number of addresses an
organization needs.

4. If a multihomed organization announcing a /24 cut from an ISPs's
space trades that /24 for a CIDR block from ARIN, there is zero net
impact on the routing table. The impact comes if organizations who
weren't multihoming before start announcing a route.

5. Should make cautious, conservative changes to the minimum
allocation and look for unintended consequences before lowering the
minimums further.

6. Doubtful value to lowering the minimums beyond /24 since routes
smaller than /24 are not generally routable on the backbone right now.
Would probably be counterproductive since we'd  allocate scarce IP
addresses in quantities that aren't actually usable for any valid
purpose.

7. Unable to identify any ISPs who presently both filter on RIR
minimums and choose not to carry a default route to an upstream ISP
that doesn't filter. Hence no apparent route filtering value to the
RIR minimums, at least not in practice.

8. Common counterproductive situations with the current policy
observed where an organization separately announced as many as 6
discontiguous /24's from ISPs' space into the BGP table before finally
requesting and receiving a single ARIN allocation.

9. The current minimum can result in allocating more addresses than
the requesting organization actually wants, as long as it finds a way
to qualify.

10. No major ill effects noted from APNIC (I think it was) lowering
their minimums to a level that includes /24 allocations.

11. Worries about the effect of multihomed DSL users on the routing
table, regardless of whether addresses are assigned from ISP space or
from ARIN. Some observe that ISPs generally don't provide BGP service
to DSL or cable modem users.

12. Worries about whether the availability of provider-independent
(PI) space for multihomers would push folks who don't already
multihome to start.


With all of this in mind, it seems to me that there are two ways we
can reasonably go with the policy:

Alternative #1: Lower the minimum for multihomed organizations to /23.
Give it a year to see if we get unintended consequences. Then lower it
to /24.

Alternative #2: Craft a fresh policy for small multihomed
organizations to fill the gap between the current /22 ARIN minimum and
the /24 defacto minimum on the backbone. Limit folks to 1 assignment
at a time longer than /24 and none once they have at least a /22 so
that starting allocations smaller doesn't induce routing table growth.
Exclude folks for whom their ISP bills are less than the systemic cost
of carrying a route. Make sure folks getting these allocations are and
stay multihomed with multiple vendors who are really doing BGP. Make
sure they're not just using it as an excuse to get PI space. Maybe
eventually raise the regular minimum from /22 back to /20 in order to
encourage aggregation if this /24 policy works out.


Both approaches are cautious steps forward. The first approach is very
straightforward but offers no protection against the mostly
hypothetical problems with allowing more orgs to qualify for ARIN
addresses. The second tries to more creatively tackle the risks and
liabilities at a cost of greater complexity.

Thoughts?


Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kkargel at polartel.com  Mon Aug  3 14:29:43 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 13:29:43 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>,
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>,
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A76DFB2.11465.1A979EFA@farmer.umn.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E48@mail>

> On 3 Aug 2009 Kevin Kargel wrote:
> 
> >
> > I believe we will see a mushrooming incidence of these small multi-homed
> > organizations in the routing tables in the coming years.
> >
> > This will affect the issue of global routing table size and does have a
> > bearing on reducing the minimum allocation unit.
> 
> This is exactly the situation that providing PI /24s could create
> the inducement for many more users to multihome that I was
> refering to and then create the tipping point Leo was refering
> to.
> 
> Thinking a little out side the box here and I'm not even sure
> something like this would be legal, it might be considered
> colluding.  What if a pair of providers or maybe even a set of
> providers were to jointly obtain a block of addresses to allow
> customers to multihome.  Customers would connect to two or
> more participating providers, announce there block to the
> providers and then the providers contain the customer
> announcements within there joint infrastructure and only
> announce the aggeraget to the Internet.
> 
> As I said I'm not sure how to set this up legaly and we would
> probablly need ARIN policy to enable it, as I beieve it would
> probablly violate one or two policies.

I think it is already enabled, just by virtue of the fact that there is
nothing that I know of in policy to proscribe it.  This would actually be an
operational/routing issue which is a pie ARIN has worked hard to keep it's
fingers out of.

What we may be witnessing is the advent of the multi-homed end user.

> 
> As I don't work for an ISP, I'm not sure this could work from a
> business model point of view either.  It would definitely take a
> set of ISP with an enlightened view of competition to make it
> work.

There are many many ISP's out there who are co-op telco's who would be happy
to fit this into their business model for their members.  These companies
are cooperatives, not corporations and do not operate under the same
business constraints as a corporation.  The co-ops are not afraid of custom
configurations.


> 
> Could something like this work?
> 
> I'm sure I'm missing one or two details.  But, at least Kevin's
> anecdote makes me think there could be a market for such a
> service.  And with this kind of a solution end-users could
> multihome down to a /28 or /29 without creating minutia in the
> global route table.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/228f162a/attachment.bin>

From kkargel at polartel.com  Mon Aug  3 14:38:26 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 13:38:26 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A772A84.4050800@ipinc.net>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>,
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>,
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A76DFB2.11465.1A979EFA@farmer.umn.edu>
	<4A772A84.4050800@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E49@mail>

> 
> It could work and it would be legal.  The problem is that
> it wouldn't last.  Remember, DSL/cable customers are least-cost
> customers. (Hey, I have DSL at my house!)  All that would happen is the
> customer would set this up, then observe both of their connections
> for a year to 6 months.  After doing this they would decide which
> ISP was more reliable and just cut service with the other ISP
> to save money.

I disagree.  I think you may be falling into the trap of urban thinking.  In
rural environments a whole different set of challenges come in to play.
Long transmission lines, increased weather exposure and smaller provider
scale all come in to play to affect DSL reliability.  DSL reliability is
getting better all the time, and five 9's is a nice target, but I don't
think it is yet the norm for DSL.  

Quite often all that is available to these customers are the services of
micro-ISP's.  These micro-ISP's may have technical or reliability issues of
their own, or the customer may greatly desire the immunity of not being
addicted to the provider.

We have to remember that a pretty accurate axiom is "You get what you pay
for"..  a DSL without an SLA is never going to be as reliable as a DS3 with
an SLA.  Multi-homing to different providers is one method of mitigating the
lower reliability of a DSL connection.  The customer may well be happy long
term with two or three $39.95 DSL's .

> 
> So you can imagine what would happen if, say, ISP A and ISP B
> join forces to do this, then ISP A markets this solution to
> their userbase, and then finds 6 months later that a user
> which they had spent sales and marketing dollars to get on
> to their own network, then spent more sales and marketing
> dollars to pitch this multihomed solution to, just up and
> disconnects from them and makes ISP B their only ISP.
> 
> This is why you don't see Pepsi Co running the "Pepsi Challenge"
> advertising campaign much anymore.  They found out that
> longtime Pepsi drinkers were taking the challenge and some
> of them were preferring Coke, then switching to it.
> 
> There's big risks to advertising for your competition.
> 
> Ted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/261c7456/attachment.bin>

From bicknell at ufp.org  Mon Aug  3 14:40:33 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 3 Aug 2009 14:40:33 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
Message-ID: <20090803184033.GA90786@ussenterprise.ufp.org>

In a message written on Mon, Aug 03, 2009 at 02:28:54PM -0400, William Herrin wrote:
> A hundred messages later, here's a summary of the discussion on
> lowering the ARIN minimum allocation for Multihomed organizations:

I notice something missing.  IPv6.

I say this because it would appear we have ~2 years of IPv4 left.
Given a policy cycle to get something implemented, it would appear
we might be talking about policy changes that matter for ~18 months.
That's not to say we shouldn't do it, but that we may need to direct
some focus elsewhere.

I would prefer a new policy look directly at multi-homing end-users
in IPv6, and if there are smart things we can be doing there.  Since
the space is larger, we have many more opportunities to do things
like right-sizing the first allocation, and doing spare allocation
in ways that allocations can grow without turning into multiple
route announcements.  Work in this area is likely to pay dividends
for 10's of years, not a year and a half.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/83060b1b/attachment.sig>

From bill at herrin.us  Mon Aug  3 14:48:16 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 14:48:16 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803184033.GA90786@ussenterprise.ufp.org>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0908031148j5f8e9474x116d601c097f72ed@mail.gmail.com>

On Mon, Aug 3, 2009 at 2:40 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> I would prefer a new policy look directly at multi-homing end-users
> in IPv6, and if there are smart things we can be doing there.

Leo,

I did that a month ago but the AC shot it down. If they have any
better ideas, they haven't offered them.

Even if we revive that discussion, the IPv4 issues and the IPv6 issues
are distinct from each other just as the single and multihomed
minimums have a different set of issues. They can and probably should
be considered separately and addressed with different policy
proposals.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kkargel at polartel.com  Mon Aug  3 14:49:35 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 13:49:35 -0500
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E4A@mail>

> With all of this in mind, it seems to me that there are two ways we
> can reasonably go with the policy:
> 
> Alternative #1: Lower the minimum for multihomed organizations to /23.
> Give it a year to see if we get unintended consequences. Then lower it
> to /24.
> 
> Alternative #2: Craft a fresh policy for small multihomed
> organizations to fill the gap between the current /22 ARIN minimum and
> the /24 defacto minimum on the backbone. Limit folks to 1 assignment
> at a time longer than /24 and none once they have at least a /22 so
> that starting allocations smaller doesn't induce routing table growth.
> Exclude folks for whom their ISP bills are less than the systemic cost
> of carrying a route. Make sure folks getting these allocations are and
> stay multihomed with multiple vendors who are really doing BGP. Make
> sure they're not just using it as an excuse to get PI space. Maybe
> eventually raise the regular minimum from /22 back to /20 in order to
> encourage aggregation if this /24 policy works out.
> 
> 
> Both approaches are cautious steps forward. The first approach is very
> straightforward but offers no protection against the mostly
> hypothetical problems with allowing more orgs to qualify for ARIN
> addresses. The second tries to more creatively tackle the risks and
> liabilities at a cost of greater complexity.
> 
> Thoughts?

Thanks for the summary, Bill.

I don't see the downside to slowly increasing the mask length, especially as
APNIC has done the basal experimentation.

I do think that there should be a requirement that micro-allocations be
offered only as initial allocations, and that there be a requirement that
they must be replaced by or aggregated in to any future allocations.


Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/c023866b/attachment.bin>

From bmanning at vacation.karoshi.com  Mon Aug  3 14:49:31 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 3 Aug 2009 18:49:31 +0000
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803184033.GA90786@ussenterprise.ufp.org>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
Message-ID: <20090803184931.GB958@vacation.karoshi.com.>

On Mon, Aug 03, 2009 at 02:40:33PM -0400, Leo Bicknell wrote:
> In a message written on Mon, Aug 03, 2009 at 02:28:54PM -0400, William Herrin wrote:
> > A hundred messages later, here's a summary of the discussion on
> > lowering the ARIN minimum allocation for Multihomed organizations:
> 
> I notice something missing.  IPv6.
> 
> I say this because it would appear we have ~2 years of IPv4 left.
> Given a policy cycle to get something implemented, it would appear
> we might be talking about policy changes that matter for ~18 months.
> That's not to say we shouldn't do it, but that we may need to direct
> some focus elsewhere.
> 
> I would prefer a new policy look directly at multi-homing end-users
> in IPv6, and if there are smart things we can be doing there.  Since
> the space is larger, we have many more opportunities to do things
> like right-sizing the first allocation, and doing spare allocation
> in ways that allocations can grow without turning into multiple
> route announcements.  Work in this area is likely to pay dividends
> for 10's of years, not a year and a half.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/



	you raise a couple of interesting ideas.

	a) that once the last "greenfield" IPv4 prefix is handed out,
	   that any/all policy for IPv4 is dead.

	b) there are fundamental differences in how one constructs
	   policy for the different address families.

	and I am not sure I agree with either lema.

--bill


From bicknell at ufp.org  Mon Aug  3 15:02:19 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 3 Aug 2009 15:02:19 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803184931.GB958@vacation.karoshi.com.>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<20090803184931.GB958@vacation.karoshi.com.>
Message-ID: <20090803190218.GA92191@ussenterprise.ufp.org>

In a message written on Mon, Aug 03, 2009 at 06:49:31PM +0000, bmanning at vacation.karoshi.com wrote:
> 	a) that once the last "greenfield" IPv4 prefix is handed out,
> 	   that any/all policy for IPv4 is dead.

I did not say that.  The policy doesn't magically die.  However,
the discussion here is of a policy that describes a process for
giving things out from the free pool.  If there is no free pool,
or a free pool created only from the voluntary return of address
space then I don't think the policy is going to get used very often,
post-runout.

I also included my own feeling about the future.  IPv4 will end.
IPv6 will replace it.  You can argue if that's in 2, 5, or 50 years,
but no matter the timeframe IPv6 policy matters for a longer period
of time from now than IPv4 policy.

> 	b) there are fundamental differences in how one constructs
> 	   policy for the different address families.

I might remove the word fundametal, but with that removed there are
differences.

Case in point, subnet size does not matter in IPv6.  Under current
policy if you have 1, 100, 100,000, or 100,000,000 boxes in a subnet
you use a /64.  That is not the case in IPv4, those would all get
different sized subnets.

Today many small business get a /27 from their upstream; outgrow
it and add a /27 overlay, outgrow it and renumber into a /24, outgrow
that and renumber into a /23.  In IPv6 they get a /64 (minimum,
maybe a /56, or even a /48), and all those renumbering steps go
away.

So yes, they are different.  Fundamentally different, perhaps not,
but still different.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/f9497d24/attachment.sig>

From tedm at ipinc.net  Mon Aug  3 15:08:33 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 03 Aug 2009 12:08:33 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E47@mail>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com><4A71F1C0.999.7561B2A@farmer.umn.edu><20090731033041.GA14598@ussenterprise.ufp.org>	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A77266E.9010904@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E47@mail>
Message-ID: <4A7735B1.7050307@ipinc.net>

Kevin Kargel wrote:
>> Kevin Kargel wrote:
>>> One quick point on the existance or emergence of small multi-homed
>>> networks..
>>>
>>> In the past year and a half I have seen a very noticeable increase in
>> the
>>> number of small organizations that are going or attempting to go multi-
>> homed
>>> with DSL connections to multiple upstream providers.  They are doing
>> this as
>>> a means to try and do what they did before with expensive dedicated
>> circuits
>>> like T1.  Increased reliability of a $39.95 SDSL has led these customers
>>> down the primrose path to think that if they have a couple of these then
>>> they don't need an $800 ATM circuit.
>>>
>>> I am not saying I agree with this philosophy or even that I think it is
>>> functional, but I am seeing it happen.
>>>
>>> As these customers get educated they figure out that they are
>> technically
>>> "multi-homed" and that they "can" get their own IP space,
>> No, they can't because they aren't really multihomed.
> 
> Please educate me, if they have more than one connection to the internet it
> was my understanding they were multi-homed.

multihoming, as the term is commonly used, indicates redundancy.


> I do not recall any
> specification on the type of connection as a requirement to be multi-homed. 
> 
> Technically there is nothing stopping an organization from being multi-homed
> with a collection of 56K dialup accounts.
> 

OK, if you want to say multihoming technically does not include 
redundancy, sure thing, kemo sahbee.

>>> and if they invest
>>> in a router that can do BGP they can gain transparent (to the end user)
>>> routing reliability using these DSL connections.
>> Very few ISP's provide BGP over DSL.  We are the only one in our city
>> that does, as a matter of fact.
> 
> The Big Bells won't do it, and I suspect the larger ISP's won't do it, but
> there are plenty of small ISP's around the country who will.  In fact their
> admins might even think it would be a fun experiment.
> 

It was.

>>> Bean counters tend to
>>> prefer non-recurring expenditures to recurring expenditures.
>>>
>>> These organizations are small hospitals, clinics, small banks, farmers,
>>> insurance agencies, non-chain manufacturers and distributers, et.al.
>> They
>>> don't need a lot of IP, but they do need routing failover.  They are
>>> learning that it is theoretically (albeit not realistically) possible to
>> do
>>> what used to require a T1 on SDSL better for a fraction of the cost.
>>>
>>> I believe we will see a mushrooming incidence of these small multi-homed
>>> organizations in the routing tables in the coming years.
>>>
>>> This will affect the issue of global routing table size and does have a
>>> bearing on reducing the minimum allocation unit.
>>>
>> I don't think so, Kevin.  The main reason for this is that all of the
>> small "2 DSL multihomed" routers that are on the market operate on
>> the same principle, they expect 2 DSL lines that are PPP-mode DSL.
>> The router uses a single NAT translation table with 2 default routes
>> and some fancy load-balancing programming that puts half of the
>> translation sessions on one default and the other half on the other
>> default.
> 
> It is easily done with a Cisco SoHo router (or with a SonicWall for that
> matter). 

Both of which are much more expensive than sub-$200.

> Any routing device (can you say Linux?) that will run BGP and allow
> you to forward IP and customize the LAN network will do. Bridge two DSL
> modems to act as media converters, configure your router WAN ports for
> PPPoE, get your upstreams to assign static or persistant IP's to your PPPoE
> authentication, and you are off and running.  
> 
> It is also eminently doable using DD-WRT.
> 

Heh.  Last Thursday I bought a Belkin F5D7231-4 for $1.99 from
Goodwill.  Granted, it only runs DD-WRT micro, but it's still
useful.

> 
>>  From the outside if the org is fielding servers internally, the
>> org publishes both IP numbers for the server forward - with the
>> caveat that if one of the DSL sessions goes down then connectivity
>> to the internal server is intermittent.  Obviously, you would have
>> severe problems fielding any kind of serious server behind such
>> a thing - like a DNS server for example.
> 
> So long as the upstream providers accept and promulgate your BGP
> advertisements I don't see the problem.
> 

This is assuming both upstream providers are cooperating with each
other to assign IP for your 2 PPP sessions from the same block.

>> NAT is an essential and required component of these schemes because
>> these routers are mainly load-balancing OUTBOUND requests for HTTP
>> traffic and suchlike.
> 
> That is why the orgs that want to do this need to invest ($500 or more) in a
> real router.  A residential grade router won't do it right, I agree.
> 

A FreeBSD or Linux based router will do it right - if the people running 
it know what they are doing.

>> These routers are cheap, generally under $200 or so.  The orgs that
>> deploy these solutions are generally very satisfied with them because
>> their primary purpose is failover, so that if one of their DSL lines
>> goes down, they still can surf the web.  But their understanding of
>> failover is pretty much limited to that - when you tell them that an
>> upstream ISP of theirs could lose it's connectivity, yet their little
>> router wouldn't detect this, you generally get blank stares.
>>
>> Trying to convince an org like you have described to toss out their
>> little sub $200 "load balancing" NAT/router and go to a real router that
>> costs 20 times more that can speak BGP is an exercise in futility.
>> They have a solution that gets them 90% of the way towards real
>> multihoming, is cheap, and does that 90% really well.  And most
>> importantly, they don't have to actually understand anything at all
>> about networking, they just plug it in and go.
> 
> I am not saying everyone will want to do it, or even that a majority of
> those that can will opt to do it, I am just saying that some fringe element
> *is* doing it.  I will also predict that we will see more organizations
> doing it in the future.
> 

The fring element that is doing it know what the hell they are doing,
they understand routing and BGP and all of that.  However, the
"...small hospitals, clinics, small banks, farmers,
insurance agencies, non-chain manufacturers and distributers, et.al...."
that you described, don't understand this and don't WANT to understand
this.  They want to pay someone, like the ISP, who does understand it to
do it for them.  And that org isn't going to select portable space with
an AS number and all that for any of these kinds of customers.

Be serious, Kevin.  There's a lot of cool stuff that "the fringe"
does that will never make it to mainstream because the cooler heads
aren't ever going to do what is needed to make this cool stuff
available to the unwashed masses who don't want to take the time
to learn about how things work.

You too, can soup up your garden-variety, stogy minivan to turn
12 second ETs on the quarter mile, but the vast majority aren't doing 
it, and never will.

Ted

PS  Yes, the 12 second minivan exists, here:

http://www.turbominivan.com/


From owen at delong.com  Mon Aug  3 15:10:49 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Aug 2009 12:10:49 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A770280.4050007@sprunk.org>
References: <C6978482.971EB%mksmith@adhost.com> <4A770280.4050007@sprunk.org>
Message-ID: <0F9C8A2C-E55F-4250-BCEB-A2633908A95F@delong.com>


On Aug 3, 2009, at 8:30 AM, Stephen Sprunk wrote:

> Michael K. Smith wrote:
>> What was the rationale for the /20 in the first place?  Was it more  
>> than an arbitrary number?
>
> IIRC, it was a compromise between the folks wanting to be PI and the
> folks who didn't want their routers to explode.  When routers got
> bigger, the minimum went down to /22.
>
>> I can't see any detraction from getting providers to get an ARIN- 
>> assigned /24 instead of having to get a /24 from one provider and  
>> route it out another, being historically on the "purchasing" side  
>> of that arrangement.
>
> There is one major difference: if you get a /24 from your upstream and
> other folks in the DFZ filter it, you can still be reached via your
> upstream's aggregate.  If you have a PI /24, there is a much greater
> chance of breakage.
>
Yes, and, no.  If you have a PA /24, then, it creates the illusion  
that the
behavior you describe above is somehow acceptable.  However, the
reality is that such filtration seriously jeopardizes the purpose of  
multi-homing
in the first place -- the ability to survive failure of one of your  
upstream
providers.

If you have a covering aggregate and the provider advertising the  
aggregate
is the one that fails, filtration of the other more specific creates  
just as much
breakage, but, has the additional downside that said breakage could be
much more transient in nature and much harder to identify and/or  
troubleshoot.

Nonetheless, the consequence to the routing table is identical.

Owen



From owen at delong.com  Mon Aug  3 15:42:08 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Aug 2009 12:42:08 -0700
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
Message-ID: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>

TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
2.      Proposal Originator
         a.      name: Owen DeLong
         b.      email: owen at delong.com
         c.      telephone: 408-890-7992
         d.      organization: Hurricane Electric
3.      Proposal Version: 0.9
4.      Date: 8/3/09
5.      Proposal type: new
6.      Policy term: permanent
7.      Policy statement:

	Replace section 4.3.2.2 of the NRPM with the following:

	4.3.2.2 Multihomed Connection

	For end-users who demonstrate an intent to announce the requested  
space in a
	multihomed fashion to two or more distinct providers, 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 longer than /20, they will be from a block  
reserved for that
	purpose so long as that is feasible. End-users may not receive a  
block smaller
	than /22 under this policy if they already have resources from ARIN,  
except as
	specified in section 4.3.6.2.

	Renumber the existing paragraph under the 4.3.6 to

	4.3.6.1 Utilization requirements for additional Assignment

	Add the following paragraph 4.3.6.2

	4.3.6.2	Replacement assignments for small multi-homers

	Any end-user that possesses an assignment smaller than /22 under any  
part of
	section 4.3 shall not be able to get an additional assignment unless  
they agree
	to return all existing assignments within 12 months of receiving a  
new assignment.
	The new assignment shall be sized to accommodate their existing  
utilization in
	addition to their justified additional growth space under section  
4.3.6.1.
	The common cases for this are expected to be a /24 returned after  
receipt of a /23,
	or a /23 returned after receipt of a /22.

8.      Rationale:

	This policy attempts to incorporate the recent and historical  
discussions of
	policy for multi-home users on PPML. The intent is to provide as fair  
a process
	as possible for multi-homed organizations down to the smallest  
feasible size
	while still preserving some control over growth in the routing table.

	It has been repeatedly noted that /24 multi-homers exist today with  
PA space
	and still occupy a routing table slot, so, it is unlikely that moving  
this
	boundary to /24 would significantly impact the routing table.

	By requiring smaller assignments to renumber and return, rather than  
add more
	small blocks to their assignments, this policy seeks to further  
reduce the
	chances of unnecessary growth in the routing table and encourage good  
aggregation
	where possible.

9.      Timetable for implementation: Immediate

END OF TEMPLATE

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

From kkargel at polartel.com  Mon Aug  3 15:52:58 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 14:52:58 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A7735B1.7050307@ipinc.net>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com><4A71F1C0.999.7561B2A@farmer.umn.edu><20090731033041.GA14598@ussenterprise.ufp.org>	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E43@mail>
	<4A77266E.9010904@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E47@mail>
	<4A7735B1.7050307@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E4E@mail>



> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
> Sent: Monday, August 03, 2009 2:09 PM
> To: Kevin Kargel
> Cc: William Herrin; ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Kevin Kargel wrote:
> >> Kevin Kargel wrote:
> >>> One quick point on the existance or emergence of small multi-homed
> >>> networks..
> >>>
> >>> In the past year and a half I have seen a very noticeable increase in
> >> the
> >>> number of small organizations that are going or attempting to go
> multi-
> >> homed
> >>> with DSL connections to multiple upstream providers.  They are doing
> >> this as
> >>> a means to try and do what they did before with expensive dedicated
> >> circuits
> >>> like T1.  Increased reliability of a $39.95 SDSL has led these
> customers
> >>> down the primrose path to think that if they have a couple of these
> then
> >>> they don't need an $800 ATM circuit.
> >>>
> >>> I am not saying I agree with this philosophy or even that I think it
> is
> >>> functional, but I am seeing it happen.
> >>>
> >>> As these customers get educated they figure out that they are
> >> technically
> >>> "multi-homed" and that they "can" get their own IP space,
> >> No, they can't because they aren't really multihomed.
> >
> > Please educate me, if they have more than one connection to the internet
> it
> > was my understanding they were multi-homed.
> 
> multihoming, as the term is commonly used, indicates redundancy.

And there would be redundancy in the way that the two connections are used
for failover.  It is the two or more connections that provide the
redundancy.  BGP just improves and facilitates the redundancy.

> 
> 
> > I do not recall any
> > specification on the type of connection as a requirement to be multi-
> homed.
> >
> > Technically there is nothing stopping an organization from being multi-
> homed
> > with a collection of 56K dialup accounts.
> >
> 
> OK, if you want to say multihoming technically does not include
> redundancy, sure thing, kemo sahbee.

See above.

> 
> >>> and if they invest
> >>> in a router that can do BGP they can gain transparent (to the end
> user)
> >>> routing reliability using these DSL connections.
> >> Very few ISP's provide BGP over DSL.  We are the only one in our city
> >> that does, as a matter of fact.
> >
> > The Big Bells won't do it, and I suspect the larger ISP's won't do it,
> but
> > there are plenty of small ISP's around the country who will.  In fact
> their
> > admins might even think it would be a fun experiment.
> >
> 
> It was.
> 
> >>> Bean counters tend to
> >>> prefer non-recurring expenditures to recurring expenditures.
> >>>
> >>> These organizations are small hospitals, clinics, small banks,
> farmers,
> >>> insurance agencies, non-chain manufacturers and distributers, et.al.
> >> They
> >>> don't need a lot of IP, but they do need routing failover.  They are
> >>> learning that it is theoretically (albeit not realistically) possible
> to
> >> do
> >>> what used to require a T1 on SDSL better for a fraction of the cost.
> >>>
> >>> I believe we will see a mushrooming incidence of these small multi-
> homed
> >>> organizations in the routing tables in the coming years.
> >>>
> >>> This will affect the issue of global routing table size and does have
> a
> >>> bearing on reducing the minimum allocation unit.
> >>>
> >> I don't think so, Kevin.  The main reason for this is that all of the
> >> small "2 DSL multihomed" routers that are on the market operate on
> >> the same principle, they expect 2 DSL lines that are PPP-mode DSL.
> >> The router uses a single NAT translation table with 2 default routes
> >> and some fancy load-balancing programming that puts half of the
> >> translation sessions on one default and the other half on the other
> >> default.
> >
> > It is easily done with a Cisco SoHo router (or with a SonicWall for that
> > matter).
> 
> Both of which are much more expensive than sub-$200.

Agreed, which is why I said they would have to invest in a more capable
router.

> 
> > Any routing device (can you say Linux?) that will run BGP and allow
> > you to forward IP and customize the LAN network will do. Bridge two DSL
> > modems to act as media converters, configure your router WAN ports for
> > PPPoE, get your upstreams to assign static or persistant IP's to your
> PPPoE
> > authentication, and you are off and running.
> >
> > It is also eminently doable using DD-WRT.
> >
> 
> Heh.  Last Thursday I bought a Belkin F5D7231-4 for $1.99 from
> Goodwill.  Granted, it only runs DD-WRT micro, but it's still
> useful.
> 
> >
> >>  From the outside if the org is fielding servers internally, the
> >> org publishes both IP numbers for the server forward - with the
> >> caveat that if one of the DSL sessions goes down then connectivity
> >> to the internal server is intermittent.  Obviously, you would have
> >> severe problems fielding any kind of serious server behind such
> >> a thing - like a DNS server for example.
> >
> > So long as the upstream providers accept and promulgate your BGP
> > advertisements I don't see the problem.
> >
> 
> This is assuming both upstream providers are cooperating with each
> other to assign IP for your 2 PPP sessions from the same block.

Not at all..  if one ISP gives you a static of a.a.a.a and another gives you
a static of b.b.b.b and you advertise BGP to both then your block should
have return routes through each connection.  

I don't believe that your edge connection needs to be in your assigned block
so long as your router can forward the packets where you want them to go.

> 
> >> NAT is an essential and required component of these schemes because
> >> these routers are mainly load-balancing OUTBOUND requests for HTTP
> >> traffic and suchlike.
> >
> > That is why the orgs that want to do this need to invest ($500 or more)
> in a
> > real router.  A residential grade router won't do it right, I agree.
> >
> 
> A FreeBSD or Linux based router will do it right - if the people running
> it know what they are doing.
> 
> >> These routers are cheap, generally under $200 or so.  The orgs that
> >> deploy these solutions are generally very satisfied with them because
> >> their primary purpose is failover, so that if one of their DSL lines
> >> goes down, they still can surf the web.  But their understanding of
> >> failover is pretty much limited to that - when you tell them that an
> >> upstream ISP of theirs could lose it's connectivity, yet their little
> >> router wouldn't detect this, you generally get blank stares.
> >>
> >> Trying to convince an org like you have described to toss out their
> >> little sub $200 "load balancing" NAT/router and go to a real router
> that
> >> costs 20 times more that can speak BGP is an exercise in futility.
> >> They have a solution that gets them 90% of the way towards real
> >> multihoming, is cheap, and does that 90% really well.  And most
> >> importantly, they don't have to actually understand anything at all
> >> about networking, they just plug it in and go.
> >
> > I am not saying everyone will want to do it, or even that a majority of
> > those that can will opt to do it, I am just saying that some fringe
> element
> > *is* doing it.  I will also predict that we will see more organizations
> > doing it in the future.
> >
> 
> The fring element that is doing it know what the hell they are doing,
> they understand routing and BGP and all of that.  However, the
> "...small hospitals, clinics, small banks, farmers,
> insurance agencies, non-chain manufacturers and distributers, et.al...."
> that you described, don't understand this and don't WANT to understand
> this.  They want to pay someone, like the ISP, who does understand it to
> do it for them.  And that org isn't going to select portable space with
> an AS number and all that for any of these kinds of customers.
> 
> Be serious, Kevin.  There's a lot of cool stuff that "the fringe"
> does that will never make it to mainstream because the cooler heads
> aren't ever going to do what is needed to make this cool stuff
> available to the unwashed masses who don't want to take the time
> to learn about how things work.

More and more we are seeing educated network admins in small business who
know what they are doing, and we are also seeing more and more network
consultants catering to small business.  

While I agree this is not mainstream, I do think we have to keep them in
mind when writing policy.

It is the fringe element and their experimenting and adventurism that has
brought the Internet to where it is, I am loathe to stifle that.

> 
> You too, can soup up your garden-variety, stogy minivan to turn
> 12 second ETs on the quarter mile, but the vast majority aren't doing
> it, and never will.

That doesn't mean that we should make the rules to preclude them from being
able to do it.  I have a hard time basing policy on a particular business
model.

> 
> Ted
> 
> PS  Yes, the 12 second minivan exists, here:
> 
> http://www.turbominivan.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/49369b24/attachment.bin>

From owen at delong.com  Mon Aug  3 15:51:34 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Aug 2009 12:51:34 -0700
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803190218.GA92191@ussenterprise.ufp.org>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<20090803184931.GB958@vacation.karoshi.com.>
	<20090803190218.GA92191@ussenterprise.ufp.org>
Message-ID: <C233714E-CB91-4503-B280-11779AA87071@delong.com>


On Aug 3, 2009, at 12:02 PM, Leo Bicknell wrote:

> In a message written on Mon, Aug 03, 2009 at 06:49:31PM +0000, bmanning at vacation.karoshi.com 
>  wrote:
>> 	a) that once the last "greenfield" IPv4 prefix is handed out,
>> 	   that any/all policy for IPv4 is dead.
>
> I did not say that.  The policy doesn't magically die.  However,
> the discussion here is of a policy that describes a process for
> giving things out from the free pool.  If there is no free pool,
> or a free pool created only from the voluntary return of address
> space then I don't think the policy is going to get used very often,
> post-runout.
>
> I also included my own feeling about the future.  IPv4 will end.
> IPv6 will replace it.  You can argue if that's in 2, 5, or 50 years,
> but no matter the timeframe IPv6 policy matters for a longer period
> of time from now than IPv4 policy.
>
If it weren't for the following, I might agree with you:

6.5.8. Direct assignments from ARIN to end-user organizations

6.5.8.1. Criteria
To qualify for a direct assignment, an organization must:
not be an IPv6 LIR; and
qualify for an IPv4 assignment or allocation from ARIN under the IPv4  
policy currently in effect, or demonstrate efficient utilization of  
all direct IPv4 assignments and allocations, each of which must be  
covered by any current ARIN RSA.

Given that section of the NRPM, any change we make to the IPv4
policy here automatically benefits IPv6 users as well.

>
> Case in point, subnet size does not matter in IPv6.  Under current
> policy if you have 1, 100, 100,000, or 100,000,000 boxes in a subnet
> you use a /64.  That is not the case in IPv4, those would all get
> different sized subnets.
>
Does this in any way indicate that someone who receives a /24
direct assignment should not be eligible for a /56, or, if requested
a /48 from ARIN?

> Today many small business get a /27 from their upstream; outgrow
> it and add a /27 overlay, outgrow it and renumber into a /24, outgrow
> that and renumber into a /23.  In IPv6 they get a /64 (minimum,
> maybe a /56, or even a /48), and all those renumbering steps go
> away.
>
Sure, but, I believe that existing policy coupled with the proposal
I just posted handles this perfectly well for both the IPv4 and IPv6
cases. If you do not, please show me where the problem is.

Owen

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

From bicknell at ufp.org  Mon Aug  3 16:13:43 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 3 Aug 2009 16:13:43 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <C233714E-CB91-4503-B280-11779AA87071@delong.com>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<20090803184931.GB958@vacation.karoshi.com.>
	<20090803190218.GA92191@ussenterprise.ufp.org>
	<C233714E-CB91-4503-B280-11779AA87071@delong.com>
Message-ID: <20090803201342.GB98052@ussenterprise.ufp.org>

In a message written on Mon, Aug 03, 2009 at 12:51:34PM -0700, Owen DeLong wrote:
>    Does this in any way indicate that someone who receives a /24
>    direct assignment should not be eligible for a /56, or, if requested
>    a /48 from ARIN?

Your asking the wrong question.

Largely I think folks who multi-home should be able to get IPv4 and
IPv6 space from ARIN to do just that.  My opinion may change if
multi-homing becomes popular in particular user bases (e.g. residential
end users), but for now I'm fairly happy to give anyone who buys
BGP capable service from two providers space.

With IPv4, there's not a lot more we can do, due to the lack of
available free address space, and the impending pressure on free
address space.

With IPv6, there's a lot we can do.  There are a number of proposed
sparce allocation models, for example, that would allow companies
to grow their allocations over time.  Staff is already doing some
sparce allocation in IPv6, but it's not clear to me they are using
the optimal procedure.

We need to stop looking at IPv6 as something you get as an add-on
after IPv4, and start to think about it as a first-rate protocol
that someone may want without IPv4, and that needs to be managed
intelligently on its own.  That's the real issue lurking in the
shadows here.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/5428464a/attachment.sig>

From kkargel at polartel.com  Mon Aug  3 16:25:08 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 15:25:08 -0500
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E52@mail>

Pretty good Leo.  Can we build in the proviso to allow the user to keep the
space if ARIN issues a larger block that aggregates the existing space?  For
example I would hate to see someone because of policy wording have to return
1.0.0.0/24 within 12 months after ARIN gave them 1.0.0.0/23 ..

Kevin




From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Monday, August 03, 2009 2:42 PM
To: policy at arin.net; ARIN PPML
Subject: [arin-ppml] Lower End User IPv4 threshold to /24

TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1. ? ? ?Policy Proposal Name: /24 End User Minimum Allocation Unit
2. ? ? ?Proposal Originator
?? ? ? ?a. ? ? ?name: Owen DeLong
?? ? ? ?b. ? ? ?email: owen at delong.com
?? ? ? ?c. ? ? ?telephone: 408-890-7992
?? ? ? ?d. ? ? ?organization: Hurricane Electric
3. ? ? ?Proposal Version: 0.9
4. ? ? ?Date: 8/3/09
5. ? ? ?Proposal type: new
6. ? ? ?Policy term: permanent
7. ? ? ?Policy statement:

	Replace?section?4.3.2.2?of?the?NRPM?with?the?following:

	4.3.2.2?Multihomed?Connection

	
For?end-users?who?demonstrate?an?intent?to?announce?the?requested?space?in?a
	
multihomed?fashion?to?two?or?more?distinct?providers,?the?minimum?block?of?I
P
	
address?space?assigned?is?a?/24.?If?assignments?smaller?than?a?/24?are?neede
d,
	
multihomed?end-users?should?contact?their?upstream?providers.?When?prefixes?
are
	
assigned?which?are?longer?than?/20,?they?will?be?from?a?block?reserved?for?t
hat
	purpose?so?long?as?that?is?feasible. End-users may not receive a
block smaller
	than /22 under this policy if they already have resources from ARIN,
except as
	specified in section 4.3.6.2.

	Renumber the existing paragraph under the 4.3.6 to?

	4.3.6.1 Utilization requirements for additional Assignment

	Add the following paragraph 4.3.6.2

	4.3.6.2	Replacement?assignments?for?small?multi-homers

	Any end-user that possesses an assignment smaller than /22 under any
part of
	section 4.3 shall not be able to get an additional assignment unless
they agree
	to return all existing assignments within 12 months of receiving a
new assignment.
	The new assignment shall be sized to accommodate their existing
utilization in
	addition to their justified additional growth space under section
4.3.6.1.
	The common cases for this are expected to be a /24 returned after
receipt of a /23,
	or a /23 returned after receipt of a /22.

8. ? ? ?Rationale:

	
This?policy?attempts?to?incorporate?the?recent?and?historical?discussions?of
	
policy?for?multi-home?users?on?PPML.?The?intent?is?to?provide?as?fair?a?proc
ess
	
as?possible?for?multi-homed?organizations?down?to?the?smallest?feasible?size
	
while?still?preserving?some?control?over?growth?in?the?routing?table.

	
It?has?been?repeatedly?noted?that?/24?multi-homers?exist?today?with?PA?space
	
and?still?occupy?a?routing?table?slot,?so,?it?is?unlikely?that?moving?this
	boundary?to?/24?would?significantly?impact?the?routing?table.

	
By?requiring?smaller?assignments?to?renumber?and?return,?rather?than?add?mor
e
	
small?blocks?to?their?assignments,?this?policy?seeks?to?further?reduce?the
	
chances?of?unnecessary?growth?in?the?routing?table?and?encourage?good?aggreg
ation
	where?possible.

9. ? ? ?Timetable for implementation: Immediate

END OF TEMPLATE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/df9090e1/attachment.bin>

From kkargel at polartel.com  Mon Aug  3 16:27:50 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 15:27:50 -0500
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B3A9@mail>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B3A9@mail>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E53@mail>


Ach..  I meant Pretty Good Owen..  apologies to Owen and Leo..  

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/a2bd6200/attachment.bin>

From bill at herrin.us  Mon Aug  3 16:30:43 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 16:30:43 -0400
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803201342.GB98052@ussenterprise.ufp.org>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<20090803184931.GB958@vacation.karoshi.com.>
	<20090803190218.GA92191@ussenterprise.ufp.org>
	<C233714E-CB91-4503-B280-11779AA87071@delong.com>
	<20090803201342.GB98052@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0908031330lbd3a7bas3499bcf83a566aa0@mail.gmail.com>

On Mon, Aug 3, 2009 at 4:13 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> We need to stop looking at IPv6 as something you get as an add-on
> after IPv4, and start to think about it as a first-rate protocol
> that someone may want without IPv4, and that needs to be managed
> intelligently on its own. ?That's the real issue lurking in the
> shadows here.

*cough* Proposal 92 *cough*

-Bill


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From info at arin.net  Mon Aug  3 16:37:15 2009
From: info at arin.net (Member Services)
Date: Mon, 03 Aug 2009 16:37:15 -0400
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
Message-ID: <4A774A7B.3010109@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

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

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Owen DeLong wrote:
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>
> 1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
> 2.      Proposal Originator: Owen DeLong
>     
>
> 3.      Proposal Version: 0.9
> 4.      Date: 8/3/09
> 5.      Proposal type: new
> 6.      Policy term: permanent
> 7.      Policy statement:
>
> Replace section 4.3.2.2 of the NRPM with the following:
>
> 4.3.2.2 Multihomed Connection
>
> For end-users who demonstrate an intent to announce the requested space in a
> multihomed fashion to two or more distinct providers, 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 longer than /20, they will be from a block reserved for that
> purpose so long as that is feasible. End-users may not receive a block 
> smaller
> than /22 under this policy if they already have resources from ARIN, 
> except as
> specified in section 4.3.6.2.
>
> Renumber the existing paragraph under the 4.3.6 to 
>
> 4.3.6.1 Utilization requirements for additional Assignment
>
> Add the following paragraph 4.3.6.2
>
> 4.3.6.2 Replacement assignments for small multi-homers
>
> Any end-user that possesses an assignment smaller than /22 under any 
> part of
> section 4.3 shall not be able to get an additional assignment unless 
> they agree
> to return all existing assignments within 12 months of receiving a new 
> assignment.
> The new assignment shall be sized to accommodate their existing 
> utilization in
> addition to their justified additional growth space under section 4.3.6.1.
> The common cases for this are expected to be a /24 returned after 
> receipt of a /23,
> or a /23 returned after receipt of a /22.
>
> 8.      Rationale:
>
> This policy attempts to incorporate the recent and historical discussions of
> policy for multi-home users on PPML. The intent is to provide as fair a process
> as possible for multi-homed organizations down to the smallest feasible size
> while still preserving some control over growth in the routing table.
>
> It has been repeatedly noted that /24 multi-homers exist today with PA space
> and still occupy a routing table slot, so, it is unlikely that moving this
> boundary to /24 would significantly impact the routing table.
>
> By requiring smaller assignments to renumber and return, rather than add more
> small blocks to their assignments, this policy seeks to further reduce the
> chances of unnecessary growth in the routing table and encourage good aggregation
> where possible.
>
> 9.      Timetable for implementation: Immediate
>
> END OF TEMPLATE
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 mksmith at adhost.com  Mon Aug  3 16:42:19 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 3 Aug 2009 13:42:19 -0700
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <4A774A7B.3010109@arin.net>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<4A774A7B.3010109@arin.net>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B9F6@ad-exh01.adhost.lan>

> 
> Owen DeLong wrote:
> > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> >
> > 1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
> > 2.      Proposal Originator: Owen DeLong
> >
> >
> > 3.      Proposal Version: 0.9
> > 4.      Date: 8/3/09
> > 5.      Proposal type: new
> > 6.      Policy term: permanent
> > 7.      Policy statement:
> >
> > Replace section 4.3.2.2 of the NRPM with the following:
> >
> > 4.3.2.2 Multihomed Connection
> >
> > For end-users who demonstrate an intent to announce the requested
> space in a
> > multihomed fashion to two or more distinct providers, 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 longer than /20, they will be from a block
> reserved for that
> > purpose so long as that is feasible. End-users may not receive a
> block
> > smaller
> > than /22 under this policy if they already have resources from ARIN,
> > except as
> > specified in section 4.3.6.2.
> >
> > Renumber the existing paragraph under the 4.3.6 to
> >
> > 4.3.6.1 Utilization requirements for additional Assignment
> >
> > Add the following paragraph 4.3.6.2
> >
> > 4.3.6.2 Replacement assignments for small multi-homers
> >
> > Any end-user that possesses an assignment smaller than /22 under any
> > part of
> > section 4.3 shall not be able to get an additional assignment unless
> > they agree
> > to return all existing assignments within 12 months of receiving a
> new
> > assignment.
> > The new assignment shall be sized to accommodate their existing
> > utilization in
> > addition to their justified additional growth space under section
> 4.3.6.1.
> > The common cases for this are expected to be a /24 returned after
> > receipt of a /23,
> > or a /23 returned after receipt of a /22.
> >
> > 8.      Rationale:
> >
> > This policy attempts to incorporate the recent and historical
> discussions of
> > policy for multi-home users on PPML. The intent is to provide as
fair
> a process
> > as possible for multi-homed organizations down to the smallest
> feasible size
> > while still preserving some control over growth in the routing
table.
> >
> > It has been repeatedly noted that /24 multi-homers exist today with
> PA space
> > and still occupy a routing table slot, so, it is unlikely that
moving
> this
> > boundary to /24 would significantly impact the routing table.
> >
> > By requiring smaller assignments to renumber and return, rather than
> add more
> > small blocks to their assignments, this policy seeks to further
> reduce the
> > chances of unnecessary growth in the routing table and encourage
good
> aggregation
> > where possible.
> >
> > 9.      Timetable for implementation: Immediate
> >
> > END OF TEMPLATE
> >


I support this policy as written.  If I understand Kevin's response
correctly, it's a matter of procedure how ARIN assigns space, not
policy, so it doesn't need to be accounted for in this policy.

Regards,

Mike


From bill at herrin.us  Mon Aug  3 16:46:21 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 16:46:21 -0400
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <4A774A7B.3010109@arin.net>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<4A774A7B.3010109@arin.net>
Message-ID: <3c3e3fca0908031346p1a122503t8f0137834cb6c377@mail.gmail.com>

On Mon, Aug 3, 2009 at 4:37 PM, Member Services<info at arin.net> wrote:
>> 1. ? ? ?Policy Proposal Name: /24 End User Minimum Allocation Unit

I support this proposal as written, although I intend to offer an
alternative as well.

-Bill



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From lar at mwtcorp.net  Mon Aug  3 16:24:48 2009
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Mon, 03 Aug 2009 14:24:48 -0600
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <3c3e3fca0908031148j5f8e9474x116d601c097f72ed@mail.gmail.com>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<3c3e3fca0908031148j5f8e9474x116d601c097f72ed@mail.gmail.com>
Message-ID: <web-17074726@be2.mail.trib.com>

On Mon, 3 Aug 2009 14:48:16 -0400
  William Herrin <bill at herrin.us> wrote:
> On Mon, Aug 3, 2009 at 2:40 PM, Leo Bicknell<bicknell at ufp.org> wrote:
>> I would prefer a new policy look directly at multi-homing end-users
>> in IPv6, and if there are smart things we can be doing there.
> 


> Leo,
> 
> I did that a month ago but the AC shot it down. If they have any
> better ideas, they haven't offered them.
> 
> Even if we revive that discussion, the IPv4 issues and the IPv6 issues
> are distinct from each other just as the single and multihomed
> minimums have a different set of issues. They can and probably should
> be considered separately and addressed with different policy
> proposals.
> 
> Regards,
> Bill Herrin

It may be time to play a little ping pong with the AC.

V4 and V6 are different technically but the effects of both
sets of policies bleed very much into the other. It's
folly to establish a V4 policy that encourages a group
of small concerns to get PI space and then not take into
consideration that WE want them to use V6. Are you going to
tell them they can have V4 but not V6 but by the way we want
you to convert/implement V6?
  
If we really want to move V6 forward we need to begin tying
the policies together.

Such as - after some date you have to have an
operational V6 net running and announced to get further V4
allocations.
-AND-
In order to get an initial V4 allocation you need to apply
and qualify for an initial V6 allocation and commit to
bringing the V6 up within 12 months.

I realize there are upstream and equipment issues but
if we are serious about V6 we will have to press. We
don't have to wait for exhaustion before starting to turn
up the heat.

At the very least we should synchronize the V4 policies
to current V6 policies.

> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>Falls Church, VA 22042-3004
> _______________________________________________
> 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.

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387


From bill at herrin.us  Mon Aug  3 16:59:49 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 16:59:49 -0400
Subject: [arin-ppml] IPv6 and minimum allocations
Message-ID: <3c3e3fca0908031359o7111276eo942bdb8f53dbdb95@mail.gmail.com>

On Mon, Aug 3, 2009 at 4:24 PM, <lar at mwtcorp.net> wrote:
> V4 and V6 are different technically but the effects of both
> sets of policies bleed very much into the other. It's
> folly to establish a V4 policy that encourages a group
> of small concerns to get PI space and then not take into
> consideration that WE want them to use V6. Are you going to
> tell them they can have V4 but not V6 but by the way we want
> you to convert/implement V6?
> ?If we really want to move V6 forward we need to begin tying
> the policies together.

Hi Larry,

Perhaps, but whether we want to tie continued IPv4 assignments to IPv6
deployment is a different question than whether /22 is a better
minimum size for IPv4 than /24. It merits a separate conversation that
doesn't hijack the IPv4 minimum size thread. Same for whether /56 is
better than /48 and whether the assignment criteria for IPv6 should
depend in any way on the applicant's qualification for IPv4.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From michael.dillon at bt.com  Mon Aug  3 17:08:15 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 3 Aug 2009 22:08:15 +0100
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>
Message-ID: <28E139F46D45AF49A31950F88C4974580275F1A1@E03MVZ2-UKDY.domain1.systemhost.net>


> Thinking a little out side the box here and I'm not even sure 
> something like this would be legal, it might be considered 
> colluding.  What if a pair of providers or maybe even a set 
> of providers were to jointly obtain a block of addresses to 
> allow customers to multihome.  Customers would connect to two 
> or more participating providers, announce there block to the 
> providers and then the providers contain the customer 
> announcements within there joint infrastructure and only 
> announce the aggeraget to the Internet.

No need to "jointly obtain" addresses. The two ISPs just need
to agree to use a block from one of their allocations and to
maintain direct peering links with sufficient bandwidth to 
handle the failover traffic.

When I was with Ebone back in 2000 we arranged this for a major
customer who wanted to have a backup ISP but did not want to
be responsible for managing multihoming. From the business 
point of view they wanted ONE provider and that was Ebone. But
they wanted Ebone to buy and managed multihomed connectivity 
to another major ISP. Since Ebone was supposed to be fully managing
the solution, we couldn't register a PI block in their name, but
had to use a chunk of our own space and get another ISP to announce
that chunk as well.

--Michael Dillon


From owen at delong.com  Mon Aug  3 17:06:41 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Aug 2009 14:06:41 -0700
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <web-17074726@be2.mail.trib.com>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com>
	<20090803184033.GA90786@ussenterprise.ufp.org>
	<3c3e3fca0908031148j5f8e9474x116d601c097f72ed@mail.gmail.com>
	<web-17074726@be2.mail.trib.com>
Message-ID: <199FD57A-2A52-4592-9C25-F1AB390FA1A6@delong.com>

I believe that this issue is addressed by the nature of existing IPv6
policy section 6.5.8.1

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

Owen

On Aug 3, 2009, at 1:24 PM, "" <lar at mwtcorp.net> wrote:

> On Mon, 3 Aug 2009 14:48:16 -0400
> William Herrin <bill at herrin.us> wrote:
>> On Mon, Aug 3, 2009 at 2:40 PM, Leo Bicknell<bicknell at ufp.org> wrote:
>>> I would prefer a new policy look directly at multi-homing end-users
>>> in IPv6, and if there are smart things we can be doing there.
>
>
>> Leo,
>> I did that a month ago but the AC shot it down. If they have any
>> better ideas, they haven't offered them.
>> Even if we revive that discussion, the IPv4 issues and the IPv6  
>> issues
>> are distinct from each other just as the single and multihomed
>> minimums have a different set of issues. They can and probably should
>> be considered separately and addressed with different policy
>> proposals.
>> Regards,
>> Bill Herrin
>
> It may be time to play a little ping pong with the AC.
>
> V4 and V6 are different technically but the effects of both
> sets of policies bleed very much into the other. It's
> folly to establish a V4 policy that encourages a group
> of small concerns to get PI space and then not take into
> consideration that WE want them to use V6. Are you going to
> tell them they can have V4 but not V6 but by the way we want
> you to convert/implement V6?
> If we really want to move V6 forward we need to begin tying
> the policies together.
>
> Such as - after some date you have to have an
> operational V6 net running and announced to get further V4
> allocations.
> -AND-
> In order to get an initial V4 allocation you need to apply
> and qualify for an initial V6 allocation and commit to
> bringing the V6 up within 12 months.
>
> I realize there are upstream and equipment issues but
> if we are serious about V6 we will have to press. We
> don't have to wait for exhaustion before starting to turn
> up the heat.
>
> At the very least we should synchronize the V4 policies
> to current V6 policies.
>
>> -- 
>> William D. Herrin ................ herrin at dirtside.com   
>> bill at herrin.us
>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>> Falls Church, VA 22042-3004
>> _______________________________________________
>> 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.
>
> Larry Ash
> Network Administrator
> Mountain West Telephone
> 400 East 1st St.
> Casper, WY 82601
> Office 307 233-8387
> _______________________________________________
> 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 terry.l.davis at boeing.com  Mon Aug  3 17:18:26 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 3 Aug 2009 14:18:26 -0700
Subject: [arin-ppml] Summary: lowering the ARIN minimum allocation
In-Reply-To: <20090803184931.GB958@vacation.karoshi.com.>
References: <3c3e3fca0908031128i65dfa75ay4a01e7e2f05b56e0@mail.gmail.com><20090803184033.GA90786@ussenterprise.ufp.org>
	<20090803184931.GB958@vacation.karoshi.com.>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841CCF7353@XCH-NW-CCR1V.nw.nos.boeing.com>

Bill/Leo

Also down the road on the IPv6 vein, a couple things some of the corporate (Enterprise not ISP) legal beagles need to review and discuss, relate to Sarbanes-Oxley (SOX) reporting and critical infrastructure sectors.

- From some reading and visiting with different corporate audit folks, SOX may require corporate dual-homing and PIA space to meet their obligations to their stockholders as the lack of either places them in a position that their "business continuity" would rely on a single provider.

- Likewise looking at the "critical infrastructure sectors", some of the sector regulations coming out look to have the same general guidance/requirements.

Hopefully some of the legal and regulatory folks might eventually provide some solid answers here on these potentially emerging issues.  But if either is going to be the case, we will need to consider how to meet that condition.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of bmanning at vacation.karoshi.com
> Sent: Monday, August 03, 2009 11:50 AM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Summary: lowering the ARIN minimum allocation
> 
> On Mon, Aug 03, 2009 at 02:40:33PM -0400, Leo Bicknell wrote:
> > In a message written on Mon, Aug 03, 2009 at 02:28:54PM -0400, William
> Herrin wrote:
> > > A hundred messages later, here's a summary of the discussion on
> > > lowering the ARIN minimum allocation for Multihomed organizations:
> >
> > I notice something missing.  IPv6.
> >
> > I say this because it would appear we have ~2 years of IPv4 left.
> > Given a policy cycle to get something implemented, it would appear
> > we might be talking about policy changes that matter for ~18 months.
> > That's not to say we shouldn't do it, but that we may need to direct
> > some focus elsewhere.
> >
> > I would prefer a new policy look directly at multi-homing end-users
> > in IPv6, and if there are smart things we can be doing there.  Since
> > the space is larger, we have many more opportunities to do things
> > like right-sizing the first allocation, and doing spare allocation
> > in ways that allocations can grow without turning into multiple
> > route announcements.  Work in this area is likely to pay dividends
> > for 10's of years, not a year and a half.
> >
> > --
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> 
> 
> 
> 	you raise a couple of interesting ideas.
> 
> 	a) that once the last "greenfield" IPv4 prefix is handed out,
> 	   that any/all policy for IPv4 is dead.
> 
> 	b) there are fundamental differences in how one constructs
> 	   policy for the different address families.
> 
> 	and I am not sure I agree with either lema.
> 
> --bill
> _______________________________________________
> 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 bill at herrin.us  Mon Aug  3 18:56:40 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 3 Aug 2009 18:56:40 -0400
Subject: [arin-ppml] Multihomed Microallocations
Message-ID: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>

1. Policy Proposal Name: Multihomed Microallocations
2. Proposal Originator:
  a. name: William Herrin
  b. email:  bill at herrin.us
  c. telephone: 703-534-2652
  d. organization: self
3. Proposal Version: 1.0
4. Date: 3 August 2009
5. Proposal type: new
6. Policy term: permanent
7. Policy statement:

4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations

4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4
address blocks to end users and ISPs where the requesting organization
is multihomed with multiple Internet vendors but does not meet the
minimum usage criteria for address allocation or assignment under
Sections 4.2 and 4.3.

4.4.2 Except as specified in section 4.4, the requesting organization
must also meet all criteria for receiving addresses specified in
section 4.2 if an ISP or section 4.3 if an end user.

4.4.3 Criteria for allocation or assignment

4.4.3.1 The requesting organization must hold exactly one AS number
and must already announce IPv4 addresses to the Internet via BGP using
its AS number.

4.4.3.2. The requesting organization must announce IPv4 addresses to
the Internet via at least two distinct Internet vendors.

4.4.3.3. The requesting organization must spend at least $8000/year on
the Internet services in 4.4.3.2.

4.4.3.4. Upon annual renewal of the allocation or assignment received
under section 4.4, if the requesting organization fails to demonstrate
that it continues to announce IPv4 addresses to the Internet via at
least two distinct Internet vendors the allocation or assignment is
revoked and returned to ARIN.

4.4.3.5. The requesting organization must agree to withdraw any other
BGP routes it announces from the BGP table within 6 months of
receiving an allocation or assignment under section 4.4. If the
organization continues to receive IP addresses from its ISPs, those IP
addresses will be single-homed within the ISP's larger aggregate
announcement.

4.4.3.6. If the requesting organization fails to announce the
allocation or assignment received under section 4.4 to the Internet
using its AS number for at least 4 months total within a service year,
the allocation or assignment is revoked and returned to ARIN.

4.4.3.7. If the requesting organization already holds IPv4 addresses
directly from ARIN, from any other RIR or legacy addresses, the
organization must agree to renumber out of those addresses and
surrender them to the appropriate RIR within 6 months of receiving an
allocation or assignment under section 4.4.

4.4.3.8. The requesting organization agrees to return the allocation
or assignment received under section 4.4 to ARIN within 6 months of
receiving another allocation or assignment from any RIR.

4.4.3.9. For allocations of /23 and larger, the requesting
organization shall meet the utilization rate criteria described in
section 4.2 for ISPs and section 4.3 for end users. As /24 is the
smallest address block known to be generally routable on the Internet,
no utilization criteria will be applied to requests for a /24.


8. Rationale

The reason behind a /20 minimum assignment for single-homed orgs is
fairly straightforward: an ARIN allocation adds a route to the BGP
table which wouldn't otherwise be needed. Routes are expensive and the
cost falls into overhead since it isn't recoverable directly from the
org announcing the route. And we're not really certain how many routes
we can handle before the network falls over. So, we restrict the
availability of non-aggregable IP addresses to just very large
organizations. For smaller orgs, renumbering sucks but at least it
only costs the renumbering org, not everyone else.

The reason behind nothing smaller than a /24 is also straightforward:
many if not most ISPs filter out BGP announcements smaller than /24.
There is tremendous inertia behind /24 as the minimum
backbone-routable quantity going back to the pre-CIDR days of class-C
addresses. So, an ARIN allocation smaller than /24 would generally be
wasted addresses, unusable on the Internet.

But why peg multihomed orgs at /22 instead of /24? Multivendor
multihomed orgs have to announce a route anyway, regardless of whether
the addresses are from an ISP or directly from ARIN. Their routes are
not aggregable, even if assigned from ISP space. That's the way the
technology works and no new tech in the pipeline is likely to change
it.

With load balanced server clusters and NAT you can pack a heck of a
lot of punch into a multihomed /24 if you want to. And as a community
it's to our benefit to want registrants to pack the maximum punch into
their address space: IPv4 addresses are becoming scarce. So why
restrict ARIN assignments to folks who can write papers which justify
a /22?

FAQ

Q. Why not just use ISP addresses if you're too small?

A1. ISPs have conflicting requirements placed on their use of IP
addresses. They want, for example, to prevent address spoofing at
their borders by not allowing traffic from their addresses to enter
their network from another ISP. These goals conflict with multivendor
multihoming and generally make a mess when a customer wants to
multihome.

A2. Renumbering is expensive and painful. We should require it only
when it serves a reasonable public policy goal such as reducing the
consumption of BGP routing slots.

A3. We've seen common counterproductive situations where multihomed
end users make many discontiguous /24 announcements until they
eventually seek ARIN address space.

Q. But aren't your routes aggregable with your ISP's routes if you use
your ISP's address space?

A. No. For routes to be aggregable, two things must be true:

1. The routes must be contiguous, sharing a common network/netmask.
2. The routes must share an identical network topology.

In the mutlivendor multihomed case addressed by this proposal, the
routes almost never share an identical network topology. As a result
the routes can not be aggregated even if cut from the ISP's address
space. Single-homed networks are excluded from this proposal precisely
because they always share a network topology with the ISP.

Q. Can't other organizations filter routes at the RIR minimums and
user the ISP's covering route to reach you?

A. Maybe. With a bunch of ifs. You might not be connected to the ISP
who has the covering route, and what if he doesn't have the more
specific route to you?

The answer is more decisive on a practical level: The author was
unable to identify any ISPs who presently both filters on RIR minimums
and chooses not to carry a default route to an upstream ISP that
doesn't filter. Hence there is no apparent route filtering value to
the RIR minimums.

Q. What's so messy about multihoming with a cutout from an ISP's
allocation?

A. Many things. Here are some of them:

* As an ISP I want to drop packets from the Internet that purport to
be from my addresses (spoofed packets). I can't do that with packets
from a multihomed network: in the normal course of failure recovery or
traffic engineering, the multihomed user may originate packets to
hosts on my network using the IP addresses I assigned him, but via his
other ISPs. These packets will arrive at my Internet interfaces and if
I drop them as spoofed packets, I've broken my customer's
connectivity.

* As an ISP I want to reject false route announcements entering my
system which purport to serve my addresses. And I want my pager to go
off and let me know someone is trying to hijack my address space. My
multihomed customer will, in some circumstances, want me to route all
packets to him via his other ISP. That means I have to accept his
route announcement from other ISPs. To do this, I have to write some
tricky filtering rules that accept his routes right smack in the
middle of the address space where I generally want to reject routes.

* As an ISP, I want to aggregate my contiguous address space into a
single route announcement. It's part of being a good citizen: don't
waste the TCAM slots in everybody else's router. But I have to
carefully exclude my multihomed customer's routes from that
aggregation. Packets follow the more specific route. If he announces
his more specific route to his other ISP but I roll his route up into
my less specific route when I announce it then all his packets will go
to his other ISP instead of to me and I won't get paid.

* Lots of folks disaggregate their route announcements for the purpose
of traffic engineering. Two or three hops away from their system,
those TE routes are irrelevant. In theory I should be able to filter a
lot of that out by discarding the routes smaller than the RIR minimum
allocation for that /8. That would save me money and make my routing
updates work faster. But if I try it, I end up filtering mutlihomed
customers so that I can only reach them via the ISP that assigned
their addresses. At best that damages the effectiveness of my routing.
At worst it cuts me off from sites my customers want to access when my
competitors who just accept /24 everywhere don't have a problem. Oops.

Q. Where do the announced addresses in 4.4.3.1 come from?

A. Most likely from one of the ISPs as described in NRPM section
4.2.3.6. You go through the process of getting them assigned and
announced to demonstrate that you're not a poser. Then you get
addresses from ARIN under this proposal and return the 4.2.3.6
addresses to your ISP.

Q. What does "distinct vendors" mean?

A. It means two different ISPs like Verizon and Sprint. Two T1s with a
single ISP can be accommodated without announcing a route into the
Internet backbone, so such a connection does not qualify for addresses
under this proposal.

Q. $8000? What's that all about?

A. The best available estimate of the systemic cost of carrying a
route in the Internet backbone table is around $8000/year. See
http://bill.herrin.us/network/bgpcost.html for the cost estimate.
If you're going to play in the backbone, you should really be putting
more money into the system than you're taking out. If you have two
$600 T1's then you're spending nearly twice that anyway. This  limits
the folks who want to multihome their $50 DSL and cable modems.

Q. How reliable is that estimate? Does it change? Shouldn't ARIN
routinely update that estimate rather than codifying the specific
number in the policy?

A. In theory ARIN staff should set the number. In practice,
professional cost analysts are expensive and hard data on things like
router count is almost impossible to get anyway. Even if a more
reliable cost analysis could be produced, we still wouldn't know what
multiple of that cost was "fair" for the pay-in. 1x? 2x? 5x? Let's
just pick a number that's our best guess at fair, and move forward
with it.

Besides, the $8k rule will probably turn out to be a non-operative
part of the policy. Companies providing $50 DSL service are
disinclined to set up BGP sessions with their customers anyway. I
include it in the name of caution so that we're proof against a deluge
of multihomed cable-modem users but I expect that with some experience
under our belts we'll find that we can safely submit a follow-on
policy proposal that removes the $8k requirement.

Q. I have to renumber when exactly?

A. If you have IP addresses under section 4.4, you get to announce
that one allocation or assignment to the Internet via BGP. In fact,
we'd really prefer that you only announce one single route, even if
you get a /23 or larger. You don't get to collect two assignments and
then ten discontiguous assignments and burn up the BGP table. Until
you reach the minimums in sections 4.2 or 4.3, you renumber each time
you grow large enough to justify the next bigger allocation or
assignment. Yes, that's unfortunate and painful. But burning up the
BGP table would be even more unfortunate.

Practically speaking, you'll renumber zero or one times. Either you'll
never renumber because the /24 was enough to do the job, or when you
run out of space in your original assignment, you'll be big enough to
find a way to meet the minimum size criteria in section 4.2 or 4.3 so
that you don't have to renumber again.

Q. But renumbering is expensive! What's the difference between having
to renumber under this proposal and having to renumber when I change
ISPs?

A. You'll have to renumber less often if at all. The big deal is that
you don't have to renumber merely because you changed vendors and you
don't run into a sticky mess of   filtering rules as ISPs try to keep
control of their address space.

Q. Doesn't this discriminate against some kinds of multihoming?

A. In addition to multihoming with your own AS number, its possible to
have two ISPs separately announce your addresses or announce with a
private AS number that they strip from their peer announcements. This
proposal is more than complex enough. For the sake of making
verification simple, let's just say that tiny registrants will
announce with their own AS number, period.

Q. Does this proposal affect IPv6 allocations and assignments?

A. It does not appear to impact ISP allocations whose criteria is
spelled out in NRPM section 6.5.1.1. It does impact end user
assignments under NRPM section 6.5.8.1. End users who qualify for
addresses under this policy will also be qualified for an IPv6 /48.

Q. Have there been previous policy proposals to extend allocations and
assignments from ARIN to /24?

A. Yes. See the discussions in March and April of 2007 for proposal
2007-6. http://lists.arin.net/pipermail/arin-ppml/

In proposal 2007-6, the /22 size for multihomers in section 4.3 was
simply changed to /24. It met the following criticisms:

* Could make it easier for spammers. This seems to reflect some
concern at the time over whether ARIN's policies made things easy for
spammers to hop IP addresses and was probably a red herring. Spammers
aren't interested in registering with anybody. They want address space
as anonymously as possible for as long as possible as cheaply as
possible exerting as little effort as possible. All of these things
make address space under this proposal unattractive to spammers.

* Could create a land rush. This seems like an unreasonable concern
for the instant proposal: anyone who can justify addresses under this
proposal can justify the same addresses from their ISP already. So why
hassle them with ISP addresses?

* Could create a new swamp. The renumbering requirements in this
proposal prevent that problem.

* Unfair to ISPs since it only applies to end users. This proposal
applies to both.

* Staff worried that it could increase request workload. If it does,
the fees could presumably be set accordingly.

Proposal 2007-6 also tried to make the following point: Don't penalize
the honest. An org that has ponied up the cash to be multihomed with
multiple vendors can often restructure their network to require a /22
long enough to get one. Refusing ARIN assignments smaller than /22
encourages behavior which is contrary to ARIN's general public policy
goal of conservation. We'll be better off as a community if the folks
who are completely honest about their need get the same or better
treatment than the ones who lie.


Implementation notes:

This proposal asks for verification of multihoming somewhat beyond
what the rest of the NRPM requires. It does this in order to prevent a
land rush of cheaters. Not that there's likely to be a land rush of
cheaters (or if there is that they're likely to ask for less than a
/22), but better safe than sorry.

Verifying that there's a BGP announcement is trivial: go to any of the
hundreds of looking glasses. For the four-month rule, staff may want
to let it be practiced in the breach for now. That is, don't go out
and look unless someone complains. Writing software that actively
checks for it can be part of the address recovery strategy after
depletion.

Same deal with the route withdrawals: if slot consumption bugs the
ISPs, let them write a script which trolls for cheaters and then
complain.

To verify multihoming, I would suggest asking the registrant to
provide a letter of service from two ISPs in which they indicate that
they're under contract to announce routes for AS XXX.

To verify $8k, you might ask for a month's bills and check that 12
months worth adds up to $8k.

There's a respectable chance that folks requesting a /23 or larger
will continue to grow. It would be nice if ARIN staff made reasonable
efforts to reserve adjacent space for a year or so they may be able to
get the next larger size without having to renumber. With the scarcity
of IPv4 addresses this won't always be possible, but it would be good
to do as a "best efforts" kind of thing. .


9. Timetable for implementation: immediate


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From cgrundemann at gmail.com  Mon Aug  3 19:10:52 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 3 Aug 2009 17:10:52 -0600
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <28E139F46D45AF49A31950F88C4974580275F1A1@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>
	<28E139F46D45AF49A31950F88C4974580275F1A1@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <443de7ad0908031610k7a894180v6168586d21a7991c@mail.gmail.com>

On Mon, Aug 3, 2009 at 15:08, <michael.dillon at bt.com> wrote:
>
> > Thinking a little out side the box here and I'm not even sure
> > something like this would be legal, it might be considered
> > colluding. ?What if a pair of providers or maybe even a set
> > of providers were to jointly obtain a block of addresses to
> > allow customers to multihome. ?Customers would connect to two
> > or more participating providers, announce there block to the
> > providers and then the providers contain the customer
> > announcements within there joint infrastructure and only
> > announce the aggeraget to the Internet.
>
> No need to "jointly obtain" addresses. The two ISPs just need
> to agree to use a block from one of their allocations and to
> maintain direct peering links with sufficient bandwidth to
> handle the failover traffic.
>
> When I was with Ebone back in 2000 we arranged this for a major
> customer who wanted to have a backup ISP but did not want to
> be responsible for managing multihoming. From the business
> point of view they wanted ONE provider and that was Ebone. But
> they wanted Ebone to buy and managed multihomed connectivity
> to another major ISP. Since Ebone was supposed to be fully managing
> the solution, we couldn't register a PI block in their name, but
> had to use a chunk of our own space and get another ISP to announce
> that chunk as well.

We see something along these lines fairly regularly - A managed
services provider of some sort who peers with multiple ISPs sells
their customer a redundant connection which they manage. i.e. their
AS, their IP space, their routers - just two handoffs to the customer
(or maybe one, I don't typically see that side).  Multihoming by proxy
I guess you would call it.  Thing is, we usually see these guys
advertise long prefixes (often /24s) to get some load-balancing of the
upstream circuits I expect.

More to the point of these threads (i hope); is that right now,
obtaining address space is not the roadblock for those who can justify
that space and want to multihome.  I do not think that ARIN assigning
/24s to multihomers (who can justify the need) will cause any
explosion in the demand for multihomed /24s - a drop in the price of
BGP speaking routers and/or a growth of BGP cluefull engineers is
probably more worrisome...

~Chris

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



--
Chris Grundemann
www.chrisgrundemann.com
www.coisoc.org


From kkargel at polartel.com  Mon Aug  3 19:18:58 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 3 Aug 2009 18:18:58 -0500
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E55@mail>

Bill,
I suspect that we would be better off without the $8K/annum limiting policy.
Orgs who may want to do completely experimental or frivolous multi-homing
will probably be put off my the ASN/ARIN membership requirements and costs
in any case.  

I have only glanced through your proposal.  I am very interested and will
give it more attention tomorrow.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/b96b4ef6/attachment.bin>

From farmer at umn.edu  Mon Aug  3 20:01:31 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 03 Aug 2009 19:01:31 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <443de7ad0908031610k7a894180v6168586d21a7991c@mail.gmail.com>
References: <4A76DFB2.11465.1A979EFA@farmer.umn.edu>,
	<28E139F46D45AF49A31950F88C4974580275F1A1@E03MVZ2-UKDY.domain1.systemhost.net>,
	<443de7ad0908031610k7a894180v6168586d21a7991c@mail.gmail.com>
Message-ID: <4A77340B.11209.1BE1189E@farmer.umn.edu>

On 3 Aug 2009 Chris Grundemann wrote:

...

> More to the point of these threads (i hope); is that right now,
> obtaining address space is not the roadblock for those who can justify
> that space and want to multihome.  I do not think that ARIN assigning
> /24s to multihomers (who can justify the need) will cause any
> explosion in the demand for multihomed /24s - a drop in the price of
> BGP speaking routers and/or a growth of BGP cluefull engineers is
> probably more worrisome...

So your saying I shouldn't write the BGP book for the 
venerable "for Dummies" series or push Linksys (AKA Cisco) 
to put a BGP announcement stub in their next line of High-End 
multi-port broadband routers.  The High-End ones are the 
$150 to $200 ones, not the cheap ones at $50 to $75.

Darn, there goes my master plan for 2010, NOT!!!  :)

You know the sad thing is some one will probablly do just that, 
and make a bunch of money at it too. :(

> ~Chris


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



From owen at delong.com  Mon Aug  3 23:43:23 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Aug 2009 20:43:23 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
Message-ID: <97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>

The primary reason for applying as an ISP organization rather than an  
end-user
organization is to be able to reassign blocks to your customers in a  
manner which
can be recorded via SWIP.  The minimum amount of space subject to SWIP  
is
a /28, which there are only 16 in a /24 and 32 in a /23. That makes no  
allowance
for the ISP's internal infrastructure.

I'm not opposed to extending this ability to ISPs if there is a need,  
but, at present,
I think that when you are talking about reassignable space, a /21 is  
already a
pretty small chunk. If I'm wrong about this, I welcome people to set  
me straight.
(It won't be the first time).

> 4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations
>
> 4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4
> address blocks to end users and ISPs where the requesting organization
> is multihomed with multiple Internet vendors but does not meet the
> minimum usage criteria for address allocation or assignment under
> Sections 4.2 and 4.3.
>
> 4.4.2 Except as specified in section 4.4, the requesting organization
> must also meet all criteria for receiving addresses specified in
> section 4.2 if an ISP or section 4.3 if an end user.
>
> 4.4.3 Criteria for allocation or assignment
>
> 4.4.3.1 The requesting organization must hold exactly one AS number
> and must already announce IPv4 addresses to the Internet via BGP using
> its AS number.
>
I'm not sure I understand the need to exclude the following classes of
organizations from this policy:

1.	Organizations which are obtaining their AS number and IPv4 resources
	at the same time as part of a start-up process.

2.	Organizations which may wish to utilize their ability to qualify  
under
	IPv4 policy for obtaining IPv6 space, but, which have no desire to
	obtain or implement IPv4.

Noteworthy, it also excludes organizations holding more than one AS  
number,
but, that is presumably to discourage fragmentation of the allocation/ 
assignment.

> 4.4.3.2. The requesting organization must announce IPv4 addresses to
> the Internet via at least two distinct Internet vendors.
>
> 4.4.3.3. The requesting organization must spend at least $8000/year on
> the Internet services in 4.4.3.2.
>
I think this requirement is absurd.  First of all, as the price of  
transit continues
to fall (currently transit is available for as little as $2/mbps on 95th
%ile billing) requiring some arbitrary price per year
(here $333/provider/month) could easily become anachronistic.
Second, in general ARIN policy tries to avoid dictating business
models or practices, and, requiring paid transit at all (vs. settlement
free peering as a viable counter-example) seems odd.

[snip]
>
> 4.4.3.5. The requesting organization must agree to withdraw any other
> BGP routes it announces from the BGP table within 6 months of
> receiving an allocation or assignment under section 4.4. If the
> organization continues to receive IP addresses from its ISPs, those IP
> addresses will be single-homed within the ISP's larger aggregate
> announcement.
>
6 months might be  a bit hasty here.  I think current ARIN address
replacement policies allow a longer timeframe and I think this
should be consistent.

> 4.4.3.6. If the requesting organization fails to announce the
> allocation or assignment received under section 4.4 to the Internet
> using its AS number for at least 4 months total within a service year,
> the allocation or assignment is revoked and returned to ARIN.
>
Does this mean that ARIN is expected to monitor such announcements?
Is there a defined test point which is considered valid from which the
routes must be visible? By what objective mechanism and criteria
can this actually be measured?

> 4.4.3.7. If the requesting organization already holds IPv4 addresses
> directly from ARIN, from any other RIR or legacy addresses, the
> organization must agree to renumber out of those addresses and
> surrender them to the appropriate RIR within 6 months of receiving an
> allocation or assignment under section 4.4.
>
See above comment on 4.4.3.5

> 4.4.3.8. The requesting organization agrees to return the allocation
> or assignment received under section 4.4 to ARIN within 6 months of
> receiving another allocation or assignment from any RIR.
>
See above comment on 4.4.3.5

>
> Q. $8000? What's that all about?
>
> A. The best available estimate of the systemic cost of carrying a
> route in the Internet backbone table is around $8000/year. See
> http://bill.herrin.us/network/bgpcost.html for the cost estimate.
> If you're going to play in the backbone, you should really be putting
> more money into the system than you're taking out. If you have two
> $600 T1's then you're spending nearly twice that anyway. This  limits
> the folks who want to multihome their $50 DSL and cable modems.
>
Depending on where you measure this $8,000/year, it also could
eliminate folks who connect via exchange points or live in carrier
hotels and get inexpensive transit by other perfectly legitimate
means. I understand the theory here, but, in my opinion, it is not
the role of ARIN policy to dictate economics or business practices.

[snip]


> Besides, the $8k rule will probably turn out to be a non-operative
> part of the policy. Companies providing $50 DSL service are
> disinclined to set up BGP sessions with their customers anyway. I
> include it in the name of caution so that we're proof against a deluge
> of multihomed cable-modem users but I expect that with some experience
> under our belts we'll find that we can safely submit a follow-on
> policy proposal that removes the $8k requirement.
>
This is the best reason of all to strike the requirement.  It's  
unnecessary
and any place it would have effect is probably unintended.
>
>
> Q. Does this proposal affect IPv6 allocations and assignments?
>
> A. It does not appear to impact ISP allocations whose criteria is
> spelled out in NRPM section 6.5.1.1. It does impact end user
> assignments under NRPM section 6.5.8.1. End users who qualify for
> addresses under this policy will also be qualified for an IPv6 /48.
>
However, it also precludes a network from qualifying under this
policy and deploying IPv6 without IPv4 resources deployed.

While this may not be a significant issue today, it does shorten
the potential valid lifespan of this policy.

Owen

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

From leo.vegoda at icann.org  Tue Aug  4 03:55:09 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 4 Aug 2009 00:55:09 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
Message-ID: <C69D376D.27011%leo.vegoda@icann.org>

On 03/08/2009 8:43, "Owen DeLong" <owen at delong.com> wrote:

[...]

>> 4.4.3.2. The requesting organization must announce IPv4 addresses to
>> the Internet via at least two distinct Internet vendors.
>> 
>> 4.4.3.3. The requesting organization must spend at least $8000/year on
>> the Internet services in 4.4.3.2.
>> 
> I think this requirement is absurd.  First of all, as the price of transit
> continues
> to fall (currently transit is available for as little as $2/mbps on 95th
> %ile billing) requiring some arbitrary price per year
> (here $333/provider/month) could easily become anachronistic.

I read this section differently from you. I'm not sure if my interpretation
was the intended one but I thought the $8k/year would also include the costs
of hardware and related licenses and support contracts. That is, $8k was for
the cost of routers, software licenses, vendor support and connectivity to
two or more other ASs.

Perhaps I misunderstood the intent.

Regards,

Leo



From bill at herrin.us  Tue Aug  4 08:56:37 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 08:56:37 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
Message-ID: <3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>

On Mon, Aug 3, 2009 at 11:43 PM, Owen DeLong<owen at delong.com> wrote:
> I'm not opposed to extending this ability to ISPs if there is a need, but,
> at present, I think that when you are talking about reassignable
> space, a /21 is already a pretty small chunk. If?I'm?wrong?about?this,
>?I?welcome?people?to?set?me?straight.

Hi Owen,

Lots of comments. I'll try to take them one at a time.

The way I see it, there is no compelling reason to pre-suppose what
the ISP's needs are. If he needs a /21 and can document that need,
he'll surely ask for a /21. If he's a co-op serving a neighborhood,
maybe he only needs a /24.


> 4.4.3.1 The requesting organization must hold exactly one AS number
> and must already announce IPv4 addresses to the Internet via BGP using
> its AS number.
>
> I'm not sure I understand the need to exclude the following classes of
> organizations from this policy:
> 1. Organizations which are obtaining their AS number and IPv4 resources
> at the same time as part of a start-up process.

These folks are not excluded; they're just given extra work. Instead
of merely claiming they're going to multihome as they start up, they
have to actually do it. 24 hours after they first announce the ISP /24
they can apply for an ARIN /24 and ARIN is pretty zippy about
completing allocations.


> 2. Organizations which may wish to utilize their ability to qualify under
> IPv4?policy?for?obtaining?IPv6?space,?but,?which?have?no?desire?to
> obtain?or?implement?IPv4.

That only applies to end users and is, IMHO, a defect in the IPv6
policy. The appropriate place to correct it is in the IPv6 policy but
the AC will have to actually carry such a proposal to a meeting and
seek consensus before that can happen.

> Noteworthy,?it?also?excludes?organizations?holding?more?than?one?AS?number,
> but,?that?is?presumably?to?discourage?fragmentation?of?the?allocation/assignment.

My point of view was that if you're holding more than one AS number
then you're already past the point where you should be seeking
allocations and assignments below the existing minimums.


> 4.4.3.3. The requesting organization must spend at least $8000/year on
> the Internet services in 4.4.3.2.
>
> I think this requirement is absurd. ?First of all, as the price of transit
> continues to fall (currently transit is available for as little
> as $2/mbps on 95th %ile billing) requiring some arbitrary
> price per year?(here $333/provider/month) could easily
> become anachronistic.
> Second, in general ARIN policy tries to avoid dictating business
> models or practices, and, requiring paid transit at all (vs. settlement
> free peering as a viable counter-example) seems odd.

I'm open to altering 4.4.3.3 or dropping it entirely if folks feel
it's unwanted and unneeded. But I'd offer two points:

1. The existing minimums are a harmful and backwards way of applying a
limit on how much money you have to spend to participate. We know that
routing slots are an expensive resource, so why not tackle that issue
more directly instead of placing odd technical requirements that hit
it only indirectly?

2. The number isn't arbitrary; it's based on the only available
estimate of the cost of BGP routing which for all its faults has
actually been reviewed by a professional cost analyst. It could become
anachronistic over time, but so what? Like any ARIN policy its subject
to update at need.



> 4.4.3.5. The requesting organization must agree to withdraw any other
> BGP routes it announces from the BGP table within 6 months of
> receiving an allocation or assignment under section 4.4. If the
> organization continues to receive IP addresses from its ISPs, those IP
> addresses will be single-homed within the ISP's larger aggregate
> announcement.
>
> 6 months might be ?a bit hasty here. ?I think current ARIN address
> replacement policies allow a longer timeframe and I think this
> should be consistent.

If the consensus is 12 months I'm fine with moving it there.


> 4.4.3.6. If the requesting organization fails to announce the
> allocation or assignment received under section 4.4 to the Internet
> using its AS number for at least 4 months total within a service year,
> the allocation or assignment is revoked and returned to ARIN.
>
> Does this mean that ARIN is expected to monitor such announcements?
> Is there a defined test point which is considered valid from which the
> routes must be visible? By what objective mechanism and criteria
> can this actually be measured?

>From my "implementation notes" towards the end of the rationale section:

Verifying that there's a BGP announcement is trivial: go to any of the
hundreds of looking glasses. For the four-month rule, staff may want
to let it be practiced in the breach for now. That is, don't go out
and look unless someone complains. Writing software that actively
checks for it can be part of the address recovery strategy after
depletion.

Same deal with the route withdrawals: if slot consumption bugs the
ISPs, let them write a script which trolls for cheaters and then
complain.


As for how you'd write the software down the road, getting copies of
various table views is not particularly hard. A number of researchers
currently do it. If the route isn't in any of them then whatever the
registrant is doing, it isn't what the policy intended.



> Depending on where you measure this $8,000/year, it also could
> eliminate folks who connect via exchange points or live in carrier
> hotels and get inexpensive transit by other perfectly legitimate
> means. I understand the theory here, but, in my opinion, it is not
> the role of ARIN policy to dictate economics or business practices.

You can go to Vegas, stay in the discounted rooms in the casino hotels
and play the quarter slots. You can also sit at the high stakes table,
but if you do you have to ante up.

BGP on the backbone is the Internet's high stakes table. Arranging for
your connectivity costs to rise to $8k/year is always trivially done.
Instead of counting computers, I suggest using your willingness to
ante up to determine whether you're allowed to sit at the table.

Of course, if you can somehow justify a /22 without spending at least
$8k per year on connectivity then more power to you.

Besides, if you live in a carrier hotel, you're paying for cross
connects or access to the peering switch. That's generally not cheap
and is very obviously part of the connectivity costs.


> Q. Does this proposal affect IPv6 allocations and assignments?
>
> A. It does not appear to impact ISP allocations whose criteria is
> spelled out in NRPM section 6.5.1.1. It does impact end user
> assignments under NRPM section 6.5.8.1. End users who qualify for
> addresses under this policy will also be qualified for an IPv6 /48.
>
> However, it also precludes a network from qualifying under this
> policy and deploying IPv6 without IPv4 resources deployed.
> While this may not be a significant issue today, it does shorten
> the potential valid lifespan of this policy.

That's not a defect with this policy proposal per se. Rather it's a
defect with the IPv6 policy for end users which should be addressed
there. Here it's just a red herring like the spammer issue was for
proposal 2007-6.

This particular policy proposal need not outlive IPv4.



On Tue, Aug 4, 2009 at 3:55 AM, Leo Vegoda<leo.vegoda at icann.org> wrote:
> I read this section differently from you. I'm not sure if my interpretation
> was the intended one but I thought the $8k/year would also include the costs
> of hardware and related licenses and support contracts. That is, $8k was for
> the cost of routers, software licenses, vendor support and connectivity to
> two or more other ASs.

Hi Leo,

My intention was that the $8k be restricted to ISP connectivity costs
but if folks feel it would be more fair to include some other costs
such as routers or data center charges, I would not object to
adjusting it.

Alternately, we could punt here: specify "qualifying Internet costs"
in the policy and ask ARIN staff to determine which costs qualify as
contributing to the system from which the registrant consumes a
routing slot. The $50 DSL user isn't going to spend $8k per year on
Internet service no matter how you qualify the costs, and that's who
we really want to keep out of the backbone.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From leo.vegoda at icann.org  Tue Aug  4 09:23:04 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 4 Aug 2009 06:23:04 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
Message-ID: <C69D8448.2703A%leo.vegoda@icann.org>

Hi Bill,

On 04/08/2009 5:56, "William Herrin" <bill at herrin.us> wrote:

[...]

>> I read this section differently from you. I'm not sure if my interpretation
>> was the intended one but I thought the $8k/year would also include the costs
>> of hardware and related licenses and support contracts. That is, $8k was for
>> the cost of routers, software licenses, vendor support and connectivity to
>> two or more other ASs.

[...]

> My intention was that the $8k be restricted to ISP connectivity costs
> but if folks feel it would be more fair to include some other costs
> such as routers or data center charges, I would not object to
> adjusting it.

If you want to maintain this section I think you need to tighten up the
wording to unambiguously exclude costs incurred in providing the potential
registrant's own network infrastructure. Perhaps use a phrase like "paid to
ISPs for connectivity services".

I think that this kind of market price and access regulation is a bit blunt
though, however whatever value is used in place of the $8k.

Regards,

Leo



From spetty at iconnect-corp.com  Tue Aug  4 10:28:37 2009
From: spetty at iconnect-corp.com (Steven E. Petty)
Date: Tue, 4 Aug 2009 10:28:37 -0400
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <4A774A7B.3010109@arin.net>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<4A774A7B.3010109@arin.net>
Message-ID: <402EB9414506BC40BB42CD47317FD1B312CCDFD6B5@Maggie.iconnect-corp.com>


  While I am very much in favor of this idea, I think there needs to be very stringent/serious language to prevent these microallocations from being abused with respect to the recent 'ip market' discussions.

  I would also expect an explicit statement that there is a return of space requirement if multihoming ceases.  Hmmm..  How do do that without muddying Arin's (non)role in routing...


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Monday, August 03, 2009 4:37 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Lower End User IPv4 threshold to /24

ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within 10 days.

The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations.

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

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Owen DeLong wrote:
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>
> 1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
> 2.      Proposal Originator: Owen DeLong
>
>
> 3.      Proposal Version: 0.9
> 4.      Date: 8/3/09
> 5.      Proposal type: new
> 6.      Policy term: permanent
> 7.      Policy statement:
>
> Replace section 4.3.2.2 of the NRPM with the following:
>
> 4.3.2.2 Multihomed Connection
>
> For end-users who demonstrate an intent to announce the requested
> space in a multihomed fashion to two or more distinct providers, 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 longer
> than /20, they will be from a block reserved for that purpose so long
> as that is feasible. End-users may not receive a block smaller than
> /22 under this policy if they already have resources from ARIN, except
> as specified in section 4.3.6.2.
>
> Renumber the existing paragraph under the 4.3.6 to
>
> 4.3.6.1 Utilization requirements for additional Assignment
>
> Add the following paragraph 4.3.6.2
>
> 4.3.6.2 Replacement assignments for small multi-homers
>
> Any end-user that possesses an assignment smaller than /22 under any
> part of section 4.3 shall not be able to get an additional assignment
> unless they agree to return all existing assignments within 12 months
> of receiving a new assignment.
> The new assignment shall be sized to accommodate their existing
> utilization in addition to their justified additional growth space
> under section 4.3.6.1.
> The common cases for this are expected to be a /24 returned after
> receipt of a /23, or a /23 returned after receipt of a /22.
>
> 8.      Rationale:
>
> This policy attempts to incorporate the recent and historical
> discussions of policy for multi-home users on PPML. The intent is to
> provide as fair a process as possible for multi-homed organizations
> down to the smallest feasible size while still preserving some control over growth in the routing table.
>
> It has been repeatedly noted that /24 multi-homers exist today with PA
> space and still occupy a routing table slot, so, it is unlikely that
> moving this boundary to /24 would significantly impact the routing table.
>
> By requiring smaller assignments to renumber and return, rather than
> add more small blocks to their assignments, this policy seeks to
> further reduce the chances of unnecessary growth in the routing table
> and encourage good aggregation where possible.
>
> 9.      Timetable for implementation: Immediate
>
> END OF TEMPLATE
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> 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 bill at herrin.us  Tue Aug  4 10:53:02 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 10:53:02 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <C69D8448.2703A%leo.vegoda@icann.org>
References: <3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<C69D8448.2703A%leo.vegoda@icann.org>
Message-ID: <3c3e3fca0908040753w4ae7d4acw9071bbf1242e5d7f@mail.gmail.com>

On Tue, Aug 4, 2009 at 9:23 AM, Leo Vegoda<leo.vegoda at icann.org> wrote:
>> My intention was that the $8k be restricted to ISP connectivity costs
>> but if folks feel it would be more fair to include some other costs
>> such as routers or data center charges, I would not object to
>> adjusting it.
>
> If you want to maintain this section I think you need to tighten up the
> wording to unambiguously exclude costs incurred in providing the potential
> registrant's own network infrastructure. Perhaps use a phrase like "paid to
> ISPs for connectivity services".

Hi Leo,

I'll note that for the first update. Thanks.

> I think that this kind of market price and access regulation is a bit blunt
> though, however whatever value is used in place of the $8k.

I'm curious which meaning you intend for "blunt" here.

It is blunt in the sense that it doesn't duck the basic issue: routing
slots are expensive. The RIR minimums are a somewhat disingenuous way
of getting at that issue... If you will have the 500 computers online
that you need to qualify for a /22, you'll certainly be pumping enough
money into the backbone to merit a routing slot. Simply saying that
you have to pump enough money into the backbone to merit a routing
slot offers no finesse or disguise.

On the other hand, I'd argue that the /22 minimum is the blunt
instrument. It blocks the $50 DSL user, true, but it also pummels the
multimillion dollar online service whose only failing is that he found
a way to be efficient with his use of IP addresses. Declaring a
minimum ante to play is more surgically precise. It cuts closer to the
real issue: that we want to be paid for the routing slot we provide.

Still, if the /22 minimum is demonstrated harmful and pay-enough has
no finesse, what's a third alternative for controlling access to the
BGP system so that we aren't overwhelmed by router expense? If there's
a better way, I'm all for it.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From info at arin.net  Tue Aug  4 11:02:01 2009
From: info at arin.net (Member Services)
Date: Tue, 04 Aug 2009 11:02:01 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
Message-ID: <4A784D69.3060802@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

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

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

William Herrin wrote:
> 1. Policy Proposal Name: Multihomed Microallocations
> 2. Proposal Originator: William Herrin
>   
> 3. Proposal Version: 1.0
> 4. Date: 3 August 2009
> 5. Proposal type: new
> 6. Policy term: permanent
> 7. Policy statement:
>
> 4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations
>
> 4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4
> address blocks to end users and ISPs where the requesting organization
> is multihomed with multiple Internet vendors but does not meet the
> minimum usage criteria for address allocation or assignment under
> Sections 4.2 and 4.3.
>
> 4.4.2 Except as specified in section 4.4, the requesting organization
> must also meet all criteria for receiving addresses specified in
> section 4.2 if an ISP or section 4.3 if an end user.
>
> 4.4.3 Criteria for allocation or assignment
>
> 4.4.3.1 The requesting organization must hold exactly one AS number
> and must already announce IPv4 addresses to the Internet via BGP using
> its AS number.
>
> 4.4.3.2. The requesting organization must announce IPv4 addresses to
> the Internet via at least two distinct Internet vendors.
>
> 4.4.3.3. The requesting organization must spend at least $8000/year on
> the Internet services in 4.4.3.2.
>
> 4.4.3.4. Upon annual renewal of the allocation or assignment received
> under section 4.4, if the requesting organization fails to demonstrate
> that it continues to announce IPv4 addresses to the Internet via at
> least two distinct Internet vendors the allocation or assignment is
> revoked and returned to ARIN.
>
> 4.4.3.5. The requesting organization must agree to withdraw any other
> BGP routes it announces from the BGP table within 6 months of
> receiving an allocation or assignment under section 4.4. If the
> organization continues to receive IP addresses from its ISPs, those IP
> addresses will be single-homed within the ISP's larger aggregate
> announcement.
>
> 4.4.3.6. If the requesting organization fails to announce the
> allocation or assignment received under section 4.4 to the Internet
> using its AS number for at least 4 months total within a service year,
> the allocation or assignment is revoked and returned to ARIN.
>
> 4.4.3.7. If the requesting organization already holds IPv4 addresses
> directly from ARIN, from any other RIR or legacy addresses, the
> organization must agree to renumber out of those addresses and
> surrender them to the appropriate RIR within 6 months of receiving an
> allocation or assignment under section 4.4.
>
> 4.4.3.8. The requesting organization agrees to return the allocation
> or assignment received under section 4.4 to ARIN within 6 months of
> receiving another allocation or assignment from any RIR.
>
> 4.4.3.9. For allocations of /23 and larger, the requesting
> organization shall meet the utilization rate criteria described in
> section 4.2 for ISPs and section 4.3 for end users. As /24 is the
> smallest address block known to be generally routable on the Internet,
> no utilization criteria will be applied to requests for a /24.
>
>
> 8. Rationale
>
> The reason behind a /20 minimum assignment for single-homed orgs is
> fairly straightforward: an ARIN allocation adds a route to the BGP
> table which wouldn't otherwise be needed. Routes are expensive and the
> cost falls into overhead since it isn't recoverable directly from the
> org announcing the route. And we're not really certain how many routes
> we can handle before the network falls over. So, we restrict the
> availability of non-aggregable IP addresses to just very large
> organizations. For smaller orgs, renumbering sucks but at least it
> only costs the renumbering org, not everyone else.
>
> The reason behind nothing smaller than a /24 is also straightforward:
> many if not most ISPs filter out BGP announcements smaller than /24.
> There is tremendous inertia behind /24 as the minimum
> backbone-routable quantity going back to the pre-CIDR days of class-C
> addresses. So, an ARIN allocation smaller than /24 would generally be
> wasted addresses, unusable on the Internet.
>
> But why peg multihomed orgs at /22 instead of /24? Multivendor
> multihomed orgs have to announce a route anyway, regardless of whether
> the addresses are from an ISP or directly from ARIN. Their routes are
> not aggregable, even if assigned from ISP space. That's the way the
> technology works and no new tech in the pipeline is likely to change
> it.
>
> With load balanced server clusters and NAT you can pack a heck of a
> lot of punch into a multihomed /24 if you want to. And as a community
> it's to our benefit to want registrants to pack the maximum punch into
> their address space: IPv4 addresses are becoming scarce. So why
> restrict ARIN assignments to folks who can write papers which justify
> a /22?
>
> FAQ
>
> Q. Why not just use ISP addresses if you're too small?
>
> A1. ISPs have conflicting requirements placed on their use of IP
> addresses. They want, for example, to prevent address spoofing at
> their borders by not allowing traffic from their addresses to enter
> their network from another ISP. These goals conflict with multivendor
> multihoming and generally make a mess when a customer wants to
> multihome.
>
> A2. Renumbering is expensive and painful. We should require it only
> when it serves a reasonable public policy goal such as reducing the
> consumption of BGP routing slots.
>
> A3. We've seen common counterproductive situations where multihomed
> end users make many discontiguous /24 announcements until they
> eventually seek ARIN address space.
>
> Q. But aren't your routes aggregable with your ISP's routes if you use
> your ISP's address space?
>
> A. No. For routes to be aggregable, two things must be true:
>
> 1. The routes must be contiguous, sharing a common network/netmask.
> 2. The routes must share an identical network topology.
>
> In the mutlivendor multihomed case addressed by this proposal, the
> routes almost never share an identical network topology. As a result
> the routes can not be aggregated even if cut from the ISP's address
> space. Single-homed networks are excluded from this proposal precisely
> because they always share a network topology with the ISP.
>
> Q. Can't other organizations filter routes at the RIR minimums and
> user the ISP's covering route to reach you?
>
> A. Maybe. With a bunch of ifs. You might not be connected to the ISP
> who has the covering route, and what if he doesn't have the more
> specific route to you?
>
> The answer is more decisive on a practical level: The author was
> unable to identify any ISPs who presently both filters on RIR minimums
> and chooses not to carry a default route to an upstream ISP that
> doesn't filter. Hence there is no apparent route filtering value to
> the RIR minimums.
>
> Q. What's so messy about multihoming with a cutout from an ISP's
> allocation?
>
> A. Many things. Here are some of them:
>
> * As an ISP I want to drop packets from the Internet that purport to
> be from my addresses (spoofed packets). I can't do that with packets
> from a multihomed network: in the normal course of failure recovery or
> traffic engineering, the multihomed user may originate packets to
> hosts on my network using the IP addresses I assigned him, but via his
> other ISPs. These packets will arrive at my Internet interfaces and if
> I drop them as spoofed packets, I've broken my customer's
> connectivity.
>
> * As an ISP I want to reject false route announcements entering my
> system which purport to serve my addresses. And I want my pager to go
> off and let me know someone is trying to hijack my address space. My
> multihomed customer will, in some circumstances, want me to route all
> packets to him via his other ISP. That means I have to accept his
> route announcement from other ISPs. To do this, I have to write some
> tricky filtering rules that accept his routes right smack in the
> middle of the address space where I generally want to reject routes.
>
> * As an ISP, I want to aggregate my contiguous address space into a
> single route announcement. It's part of being a good citizen: don't
> waste the TCAM slots in everybody else's router. But I have to
> carefully exclude my multihomed customer's routes from that
> aggregation. Packets follow the more specific route. If he announces
> his more specific route to his other ISP but I roll his route up into
> my less specific route when I announce it then all his packets will go
> to his other ISP instead of to me and I won't get paid.
>
> * Lots of folks disaggregate their route announcements for the purpose
> of traffic engineering. Two or three hops away from their system,
> those TE routes are irrelevant. In theory I should be able to filter a
> lot of that out by discarding the routes smaller than the RIR minimum
> allocation for that /8. That would save me money and make my routing
> updates work faster. But if I try it, I end up filtering mutlihomed
> customers so that I can only reach them via the ISP that assigned
> their addresses. At best that damages the effectiveness of my routing.
> At worst it cuts me off from sites my customers want to access when my
> competitors who just accept /24 everywhere don't have a problem. Oops.
>
> Q. Where do the announced addresses in 4.4.3.1 come from?
>
> A. Most likely from one of the ISPs as described in NRPM section
> 4.2.3.6. You go through the process of getting them assigned and
> announced to demonstrate that you're not a poser. Then you get
> addresses from ARIN under this proposal and return the 4.2.3.6
> addresses to your ISP.
>
> Q. What does "distinct vendors" mean?
>
> A. It means two different ISPs like Verizon and Sprint. Two T1s with a
> single ISP can be accommodated without announcing a route into the
> Internet backbone, so such a connection does not qualify for addresses
> under this proposal.
>
> Q. $8000? What's that all about?
>
> A. The best available estimate of the systemic cost of carrying a
> route in the Internet backbone table is around $8000/year. See
> http://bill.herrin.us/network/bgpcost.html for the cost estimate.
> If you're going to play in the backbone, you should really be putting
> more money into the system than you're taking out. If you have two
> $600 T1's then you're spending nearly twice that anyway. This  limits
> the folks who want to multihome their $50 DSL and cable modems.
>
> Q. How reliable is that estimate? Does it change? Shouldn't ARIN
> routinely update that estimate rather than codifying the specific
> number in the policy?
>
> A. In theory ARIN staff should set the number. In practice,
> professional cost analysts are expensive and hard data on things like
> router count is almost impossible to get anyway. Even if a more
> reliable cost analysis could be produced, we still wouldn't know what
> multiple of that cost was "fair" for the pay-in. 1x? 2x? 5x? Let's
> just pick a number that's our best guess at fair, and move forward
> with it.
>
> Besides, the $8k rule will probably turn out to be a non-operative
> part of the policy. Companies providing $50 DSL service are
> disinclined to set up BGP sessions with their customers anyway. I
> include it in the name of caution so that we're proof against a deluge
> of multihomed cable-modem users but I expect that with some experience
> under our belts we'll find that we can safely submit a follow-on
> policy proposal that removes the $8k requirement.
>
> Q. I have to renumber when exactly?
>
> A. If you have IP addresses under section 4.4, you get to announce
> that one allocation or assignment to the Internet via BGP. In fact,
> we'd really prefer that you only announce one single route, even if
> you get a /23 or larger. You don't get to collect two assignments and
> then ten discontiguous assignments and burn up the BGP table. Until
> you reach the minimums in sections 4.2 or 4.3, you renumber each time
> you grow large enough to justify the next bigger allocation or
> assignment. Yes, that's unfortunate and painful. But burning up the
> BGP table would be even more unfortunate.
>
> Practically speaking, you'll renumber zero or one times. Either you'll
> never renumber because the /24 was enough to do the job, or when you
> run out of space in your original assignment, you'll be big enough to
> find a way to meet the minimum size criteria in section 4.2 or 4.3 so
> that you don't have to renumber again.
>
> Q. But renumbering is expensive! What's the difference between having
> to renumber under this proposal and having to renumber when I change
> ISPs?
>
> A. You'll have to renumber less often if at all. The big deal is that
> you don't have to renumber merely because you changed vendors and you
> don't run into a sticky mess of   filtering rules as ISPs try to keep
> control of their address space.
>
> Q. Doesn't this discriminate against some kinds of multihoming?
>
> A. In addition to multihoming with your own AS number, its possible to
> have two ISPs separately announce your addresses or announce with a
> private AS number that they strip from their peer announcements. This
> proposal is more than complex enough. For the sake of making
> verification simple, let's just say that tiny registrants will
> announce with their own AS number, period.
>
> Q. Does this proposal affect IPv6 allocations and assignments?
>
> A. It does not appear to impact ISP allocations whose criteria is
> spelled out in NRPM section 6.5.1.1. It does impact end user
> assignments under NRPM section 6.5.8.1. End users who qualify for
> addresses under this policy will also be qualified for an IPv6 /48.
>
> Q. Have there been previous policy proposals to extend allocations and
> assignments from ARIN to /24?
>
> A. Yes. See the discussions in March and April of 2007 for proposal
> 2007-6. http://lists.arin.net/pipermail/arin-ppml/
>
> In proposal 2007-6, the /22 size for multihomers in section 4.3 was
> simply changed to /24. It met the following criticisms:
>
> * Could make it easier for spammers. This seems to reflect some
> concern at the time over whether ARIN's policies made things easy for
> spammers to hop IP addresses and was probably a red herring. Spammers
> aren't interested in registering with anybody. They want address space
> as anonymously as possible for as long as possible as cheaply as
> possible exerting as little effort as possible. All of these things
> make address space under this proposal unattractive to spammers.
>
> * Could create a land rush. This seems like an unreasonable concern
> for the instant proposal: anyone who can justify addresses under this
> proposal can justify the same addresses from their ISP already. So why
> hassle them with ISP addresses?
>
> * Could create a new swamp. The renumbering requirements in this
> proposal prevent that problem.
>
> * Unfair to ISPs since it only applies to end users. This proposal
> applies to both.
>
> * Staff worried that it could increase request workload. If it does,
> the fees could presumably be set accordingly.
>
> Proposal 2007-6 also tried to make the following point: Don't penalize
> the honest. An org that has ponied up the cash to be multihomed with
> multiple vendors can often restructure their network to require a /22
> long enough to get one. Refusing ARIN assignments smaller than /22
> encourages behavior which is contrary to ARIN's general public policy
> goal of conservation. We'll be better off as a community if the folks
> who are completely honest about their need get the same or better
> treatment than the ones who lie.
>
>
> Implementation notes:
>
> This proposal asks for verification of multihoming somewhat beyond
> what the rest of the NRPM requires. It does this in order to prevent a
> land rush of cheaters. Not that there's likely to be a land rush of
> cheaters (or if there is that they're likely to ask for less than a
> /22), but better safe than sorry.
>
> Verifying that there's a BGP announcement is trivial: go to any of the
> hundreds of looking glasses. For the four-month rule, staff may want
> to let it be practiced in the breach for now. That is, don't go out
> and look unless someone complains. Writing software that actively
> checks for it can be part of the address recovery strategy after
> depletion.
>
> Same deal with the route withdrawals: if slot consumption bugs the
> ISPs, let them write a script which trolls for cheaters and then
> complain.
>
> To verify multihoming, I would suggest asking the registrant to
> provide a letter of service from two ISPs in which they indicate that
> they're under contract to announce routes for AS XXX.
>
> To verify $8k, you might ask for a month's bills and check that 12
> months worth adds up to $8k.
>
> There's a respectable chance that folks requesting a /23 or larger
> will continue to grow. It would be nice if ARIN staff made reasonable
> efforts to reserve adjacent space for a year or so they may be able to
> get the next larger size without having to renumber. With the scarcity
> of IPv4 addresses this won't always be possible, but it would be good
> to do as a "best efforts" kind of thing. .
>
>
> 9. Timetable for implementation: immediate
>
>
>   



From Keith at jcc.com  Tue Aug  4 11:49:47 2009
From: Keith at jcc.com (Keith W. Hare)
Date: Tue, 4 Aug 2009 11:49:47 -0400
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <402EB9414506BC40BB42CD47317FD1B312CCDFD6B5@Maggie.iconnect-corp.com>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<4A774A7B.3010109@arin.net>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD6B5@Maggie.iconnect-corp.com>
Message-ID: <e9205929e288371fe2ab4f4bffd52f504a78589d@jcc.com>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven E. Petty
> Sent: Tuesday, August 04, 2009 10:29 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Lower End User IPv4 threshold to /24
> 
> 
>   While I am very much in favor of this idea, I think there 
> needs to be very stringent/serious language to prevent these 
> microallocations from being abused with respect to the recent 
> 'ip market' discussions.
> 

I don't think the "ip market" is a concern with this level of allocation. A /24 is 254 usable addresses. The per-addresses prices that have been kicked around are too small to bother with if one only has a /24.

Keith





From owen at delong.com  Tue Aug  4 11:44:40 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 4 Aug 2009 08:44:40 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
Message-ID: <E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>


On Aug 4, 2009, at 5:56 AM, William Herrin wrote:

> On Mon, Aug 3, 2009 at 11:43 PM, Owen DeLong<owen at delong.com> wrote:
>> I'm not opposed to extending this ability to ISPs if there is a  
>> need, but,
>> at present, I think that when you are talking about reassignable
>> space, a /21 is already a pretty small chunk. If I'm wrong about  
>> this,
>>  I welcome people to set me straight.
>
> Hi Owen,
>
> Lots of comments. I'll try to take them one at a time.
>
> The way I see it, there is no compelling reason to pre-suppose what
> the ISP's needs are. If he needs a /21 and can document that need,
> he'll surely ask for a /21. If he's a co-op serving a neighborhood,
> maybe he only needs a /24.
>
You again miss my point.  A co-op serving a neighborhood who only
needs a /24 will not likely need to SWIP portions of said /24, so,
does not need to register with ARIN as an ISP and pay the (much
higher) ISP fee schedule instead of the end-user fee schedule
($100/year).

I tend to think that such a small ISP is thoroughly unlikely to pay
fees they don't need, and, as such, think that there are not likely
to be ISPs that would fall into this policy.


>
>> 4.4.3.1 The requesting organization must hold exactly one AS number
>> and must already announce IPv4 addresses to the Internet via BGP  
>> using
>> its AS number.
>>
>> I'm not sure I understand the need to exclude the following classes  
>> of
>> organizations from this policy:
>> 1. Organizations which are obtaining their AS number and IPv4  
>> resources
>> at the same time as part of a start-up process.
>
> These folks are not excluded; they're just given extra work. Instead
> of merely claiming they're going to multihome as they start up, they
> have to actually do it. 24 hours after they first announce the ISP /24
> they can apply for an ARIN /24 and ARIN is pretty zippy about
> completing allocations.
>
Again, this seems absurd to me.  ARIN already asks for copies of
transit contracts to prove multihomed status on existing policy. I think
that is adequate.
>
>> 2. Organizations which may wish to utilize their ability to qualify  
>> under
>> IPv4 policy for obtaining IPv6 space, but, which have no desire to
>> obtain or implement IPv4.
>
> That only applies to end users and is, IMHO, a defect in the IPv6
> policy. The appropriate place to correct it is in the IPv6 policy but
> the AC will have to actually carry such a proposal to a meeting and
> seek consensus before that can happen.
>
It's not currently a defect.  The existing IPv6 policy does just fine in
this area for end users. The only barrier on this for ISPs is the 200
site requirement which I am strongly in favor of eliminating, but,
which is still controversial. I think that number will get relaxed in
the near future, but, probably not eliminated.

In any case, an organization which qualified for an ISP IPv4
allocation under existing policy would at that point count as an
existing known ISP in the ARIN region.

>> Noteworthy, it also excludes organizations holding more than one AS  
>> number,
>> but, that is presumably to discourage fragmentation of the  
>> allocation/assignment.
>
> My point of view was that if you're holding more than one AS number
> then you're already past the point where you should be seeking
> allocations and assignments below the existing minimums.
>
There are lots of reasons for holding multiple AS numbers that have
almost nothing to do with the size of your network.

>
>> 4.4.3.3. The requesting organization must spend at least $8000/year  
>> on
>> the Internet services in 4.4.3.2.
>>
>> I think this requirement is absurd.  First of all, as the price of  
>> transit
>> continues to fall (currently transit is available for as little
>> as $2/mbps on 95th %ile billing) requiring some arbitrary
>> price per year (here $333/provider/month) could easily
>> become anachronistic.
>> Second, in general ARIN policy tries to avoid dictating business
>> models or practices, and, requiring paid transit at all (vs.  
>> settlement
>> free peering as a viable counter-example) seems odd.
>
> I'm open to altering 4.4.3.3 or dropping it entirely if folks feel
> it's unwanted and unneeded. But I'd offer two points:
>
> 1. The existing minimums are a harmful and backwards way of applying a
> limit on how much money you have to spend to participate. We know that
> routing slots are an expensive resource, so why not tackle that issue
> more directly instead of placing odd technical requirements that hit
> it only indirectly?
>
I guess we'll just agree to disagree here.

> 2. The number isn't arbitrary; it's based on the only available
> estimate of the cost of BGP routing which for all its faults has
> actually been reviewed by a professional cost analyst. It could become
> anachronistic over time, but so what? Like any ARIN policy its subject
> to update at need.
>
We've already been through my issues with your cost analysis of a BGP
routing table slot, and, again, I suppose we should agree to disagree
there as well.

>
>
>> 4.4.3.5. The requesting organization must agree to withdraw any other
>> BGP routes it announces from the BGP table within 6 months of
>> receiving an allocation or assignment under section 4.4. If the
>> organization continues to receive IP addresses from its ISPs, those  
>> IP
>> addresses will be single-homed within the ISP's larger aggregate
>> announcement.
>>
>> 6 months might be  a bit hasty here.  I think current ARIN address
>> replacement policies allow a longer timeframe and I think this
>> should be consistent.
>
> If the consensus is 12 months I'm fine with moving it there.
>
>
>> 4.4.3.6. If the requesting organization fails to announce the
>> allocation or assignment received under section 4.4 to the Internet
>> using its AS number for at least 4 months total within a service  
>> year,
>> the allocation or assignment is revoked and returned to ARIN.
>>
>> Does this mean that ARIN is expected to monitor such announcements?
>> Is there a defined test point which is considered valid from which  
>> the
>> routes must be visible? By what objective mechanism and criteria
>> can this actually be measured?
>
>> From my "implementation notes" towards the end of the rationale  
>> section:
>
> Verifying that there's a BGP announcement is trivial: go to any of the
> hundreds of looking glasses. For the four-month rule, staff may want
> to let it be practiced in the breach for now. That is, don't go out
> and look unless someone complains. Writing software that actively
> checks for it can be part of the address recovery strategy after
> depletion.
>
There are lots of reasons that lots of routes are in one looking glass
and not others. Go to any looking glass creates the potential for
lots of controversy as recipients verify against one looking glass
while ARIN verifies against another and the complainer(s) verify
against yet a third view of a routing table.
>
> As for how you'd write the software down the road, getting copies of
> various table views is not particularly hard. A number of researchers
> currently do it. If the route isn't in any of them then whatever the
> registrant is doing, it isn't what the policy intended.
>
So ARIN should spend resources keeping some rolling >4-month
historical view of the routing table and build software to validate
that a particular prefix was/was not there during a given period?

>
>
>> Depending on where you measure this $8,000/year, it also could
>> eliminate folks who connect via exchange points or live in carrier
>> hotels and get inexpensive transit by other perfectly legitimate
>> means. I understand the theory here, but, in my opinion, it is not
>> the role of ARIN policy to dictate economics or business practices.
>
> You can go to Vegas, stay in the discounted rooms in the casino hotels
> and play the quarter slots. You can also sit at the high stakes table,
> but if you do you have to ante up.
>
> BGP on the backbone is the Internet's high stakes table. Arranging for
> your connectivity costs to rise to $8k/year is always trivially done.
> Instead of counting computers, I suggest using your willingness to
> ante up to determine whether you're allowed to sit at the table.
>
> Of course, if you can somehow justify a /22 without spending at least
> $8k per year on connectivity then more power to you.
>
You can justify a /22 by purchasing something north of 500 nodes or
creating a justification for something north of 500 addresses on some
smaller number of nodes.

While I won't enumerate them here, there are lots of ways to justify
multiple addresses per node. Combine that with some creative
subnetting, and, artificially creating the need for a /22 isn't  
particularly
hard.

> Besides, if you live in a carrier hotel, you're paying for cross
> connects or access to the peering switch. That's generally not cheap
> and is very obviously part of the connectivity costs.
>
Depends on the carrier hotel, actually.  All the world is not Equinix
or Core Site.

>
>> Q. Does this proposal affect IPv6 allocations and assignments?
>>
>> A. It does not appear to impact ISP allocations whose criteria is
>> spelled out in NRPM section 6.5.1.1. It does impact end user
>> assignments under NRPM section 6.5.8.1. End users who qualify for
>> addresses under this policy will also be qualified for an IPv6 /48.
>>
>> However, it also precludes a network from qualifying under this
>> policy and deploying IPv6 without IPv4 resources deployed.
>> While this may not be a significant issue today, it does shorten
>> the potential valid lifespan of this policy.
>
> That's not a defect with this policy proposal per se. Rather it's a
> defect with the IPv6 policy for end users which should be addressed
> there. Here it's just a red herring like the spammer issue was for
> proposal 2007-6.
>
I suppose we can agree to disagree here. It does, actually impact
ISP allocations.  As soon as a person qualifies for a /24 under this
policy as an ISP, it would immediately convert them to a known
ISP in the ARIN service region and make them eligible to receive
a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
unnecessary barriers to multi-homing, I think giving an IPv6 /32
to every user that justifies a /24 as an ISP opens up a serious
hole in policy.

Further, it could be construed (although I don't think it likely) that
you need to (under this policy) return your IPv4 resources to get
IPv6 resources within 6 months since it does not make allowance
for IPv6 resources to be treated separately.

> This particular policy proposal need not outlive IPv4.
>
But it will unless it is cancelled exactly at IPv4 runout or before.
The former is unlikely to be possible and the latter is not, in my
opinion, desirable.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/f79aa956/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/f79aa956/attachment.p7s>

From owen at delong.com  Tue Aug  4 11:48:44 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 4 Aug 2009 08:48:44 -0700
Subject: [arin-ppml] Lower End User IPv4 threshold to /24
In-Reply-To: <402EB9414506BC40BB42CD47317FD1B312CCDFD6B5@Maggie.iconnect-corp.com>
References: <98685203-69C4-4409-9A69-7FE956364A22@delong.com>
	<4A774A7B.3010109@arin.net>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD6B5@Maggie.iconnect-corp.com>
Message-ID: <4F2B886B-762F-45BF-B049-3FF4E5454D7A@delong.com>


On Aug 4, 2009, at 7:28 AM, Steven E. Petty wrote:

>
>  While I am very much in favor of this idea, I think there needs to  
> be very stringent/serious language to prevent these microallocations  
> from being abused with respect to the recent 'ip market' discussions.

Any ideas how to do this? I'm open to suggestions.
>
>  I would also expect an explicit statement that there is a return of  
> space requirement if multihoming ceases.  Hmmm..  How do do that  
> without muddying Arin's (non)role in routing...
>
I believe that the policy resulting from proposal 2007-14 which was  
adopted recently actually would cover this.

Owen

>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]  
> On Behalf Of Member Services
> Sent: Monday, August 03, 2009 4:37 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Lower End User IPv4 threshold to /24
>
> ARIN received the following policy proposal and is posting it to the  
> Public Policy Mailing List (PPML) in accordance with Policy  
> Development Process.
>
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff  
> does not evaluate the proposal at this time, their goal is to make  
> sure that they understand the proposal and believe the community  
> will as well.
> Staff will report their results to the ARIN Advisory Council (AC)  
> within 10 days.
>
> The AC will review the proposal at their next regularly scheduled  
> meeting (if the period before the next regularly scheduled meeting  
> is less than 10 days, then the period may be extended to the  
> subsequent regularly scheduled meeting). The AC will decide how to  
> utilize the proposal and announce the decision to the PPML.
>
> In the meantime, the AC invites everyone to comment on the proposal  
> on the PPML, particularly their support or non-support and the  
> reasoning behind their opinion. Such participation contributes to a  
> thorough vetting and provides important guidance to the AC in their  
> deliberations.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
> ## * ##
>
> Owen DeLong wrote:
>> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>>
>> 1.      Policy Proposal Name: /24 End User Minimum Allocation Unit
>> 2.      Proposal Originator: Owen DeLong
>>
>>
>> 3.      Proposal Version: 0.9
>> 4.      Date: 8/3/09
>> 5.      Proposal type: new
>> 6.      Policy term: permanent
>> 7.      Policy statement:
>>
>> Replace section 4.3.2.2 of the NRPM with the following:
>>
>> 4.3.2.2 Multihomed Connection
>>
>> For end-users who demonstrate an intent to announce the requested
>> space in a multihomed fashion to two or more distinct providers, 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 longer
>> than /20, they will be from a block reserved for that purpose so long
>> as that is feasible. End-users may not receive a block smaller than
>> /22 under this policy if they already have resources from ARIN,  
>> except
>> as specified in section 4.3.6.2.
>>
>> Renumber the existing paragraph under the 4.3.6 to
>>
>> 4.3.6.1 Utilization requirements for additional Assignment
>>
>> Add the following paragraph 4.3.6.2
>>
>> 4.3.6.2 Replacement assignments for small multi-homers
>>
>> Any end-user that possesses an assignment smaller than /22 under any
>> part of section 4.3 shall not be able to get an additional assignment
>> unless they agree to return all existing assignments within 12 months
>> of receiving a new assignment.
>> The new assignment shall be sized to accommodate their existing
>> utilization in addition to their justified additional growth space
>> under section 4.3.6.1.
>> The common cases for this are expected to be a /24 returned after
>> receipt of a /23, or a /23 returned after receipt of a /22.
>>
>> 8.      Rationale:
>>
>> This policy attempts to incorporate the recent and historical
>> discussions of policy for multi-home users on PPML. The intent is to
>> provide as fair a process as possible for multi-homed organizations
>> down to the smallest feasible size while still preserving some  
>> control over growth in the routing table.
>>
>> It has been repeatedly noted that /24 multi-homers exist today with  
>> PA
>> space and still occupy a routing table slot, so, it is unlikely that
>> moving this boundary to /24 would significantly impact the routing  
>> table.
>>
>> By requiring smaller assignments to renumber and return, rather than
>> add more small blocks to their assignments, this policy seeks to
>> further reduce the chances of unnecessary growth in the routing table
>> and encourage good aggregation where possible.
>>
>> 9.      Timetable for implementation: Immediate
>>
>> END OF TEMPLATE
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/562f0f1a/attachment.p7s>

From bill at herrin.us  Tue Aug  4 12:15:29 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 12:15:29 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
Message-ID: <3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>

On Tue, Aug 4, 2009 at 11:44 AM, Owen DeLong<owen at delong.com> wrote:
> I suppose we can agree to disagree here. It does, actually impact
> ISP allocations. ?As soon as a person qualifies for a /24 under this
> policy as an ISP, it would immediately convert them to a known
> ISP in the ARIN service region and make them eligible to receive
> a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
> unnecessary barriers to multi-homing, I think giving an IPv6 /32
> to every user that justifies a /24 as an ISP opens up a serious
> hole in policy.

Bullhockey. The 6.5.1.1 requirement is that the organization must "be
an LIR" as defined under 2.4. That requires that they be allocated
(not assigned) addresses from any other IR. Typically that's an RIR
like ARIN but there's not restriction on it being another LIR.

If I convince my local ISP to allocate a /24 to me and I assign some
of those addresses to one of my customers, I already qualify for an
IPv6 /32 under 6.5.1. For that matter, I can ask my ISP to allocate a
/48 of IPv6 addresses and qualify for a /32 without ever using any
IPv4 addresses at all.

IPv6 is a total red herring in this discussion.


> Further, it could be construed (although I don't think it likely) that
> you need to (under this policy) return your IPv4 resources to get
> IPv6 resources within 6 months since it does not make allowance
> for IPv6 resources to be treated separately.

No, you're right about that. I'll correct 4.4.3.5 and 4.4.3.8 to
specify IPv4. Do you see any other clauses where it needs to specify
that a non-IPv4 allocation or assignment doesn't count?

Regards,
Bill

--
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Tue Aug  4 13:01:18 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 13:01:18 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
	<3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
Message-ID: <3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>

On Tue, Aug 4, 2009 at 12:15 PM, William Herrin<bill at herrin.us> wrote:
> On Tue, Aug 4, 2009 at 11:44 AM, Owen DeLong<owen at delong.com> wrote:
>> I suppose we can agree to disagree here. It does, actually impact
>> ISP allocations. ?As soon as a person qualifies for a /24 under this
>> policy as an ISP, it would immediately convert them to a known
>> ISP in the ARIN service region and make them eligible to receive
>> a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
>> unnecessary barriers to multi-homing, I think giving an IPv6 /32
>> to every user that justifies a /24 as an ISP opens up a serious
>> hole in policy.
>
> Bullhockey. The 6.5.1.1 requirement is that the organization must "be
> an LIR" as defined under 2.4. That requires that they be allocated
> (not assigned) addresses from any other IR. Typically that's an RIR
> like ARIN but there's not restriction on it being another LIR.


Come to think of it, under the current IPv6 policy, I can, right now,
today, have my ISP *allocate* me an IPv4 /30 on my single-homed $20
DSL connection *and* delegate rwhois to my server. Next I assign /32's
to my two next-door neighbors and put their names in my rwhois server.
If I now promise to make 200 downstream IPv6 assignments within 60
months, I'm qualified to receive a /32 of IPv6 space... based on that
promise, my use of 4 IP addresses and my payment of the annual ARIN
fee.

One wonders why I ever thought it was hard to get IPv6 addresses from ARIN...

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kkargel at polartel.com  Tue Aug  4 13:19:51 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 4 Aug 2009 12:19:51 -0500
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, August 04, 2009 12:01 PM
> To: Owen DeLong
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Multihomed Microallocations
> 
> On Tue, Aug 4, 2009 at 12:15 PM, William Herrin<bill at herrin.us> wrote:
> > On Tue, Aug 4, 2009 at 11:44 AM, Owen DeLong<owen at delong.com> wrote:
> >> I suppose we can agree to disagree here. It does, actually impact
> >> ISP allocations. ?As soon as a person qualifies for a /24 under this
> >> policy as an ISP, it would immediately convert them to a known
> >> ISP in the ARIN service region and make them eligible to receive
> >> a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
> >> unnecessary barriers to multi-homing, I think giving an IPv6 /32
> >> to every user that justifies a /24 as an ISP opens up a serious
> >> hole in policy.
> >
> > Bullhockey. The 6.5.1.1 requirement is that the organization must "be
> > an LIR" as defined under 2.4. That requires that they be allocated
> > (not assigned) addresses from any other IR. Typically that's an RIR
> > like ARIN but there's not restriction on it being another LIR.
> 
> 
> Come to think of it, under the current IPv6 policy, I can, right now,
> today, have my ISP *allocate* me an IPv4 /30 on my single-homed $20
> DSL connection *and* delegate rwhois to my server. Next I assign /32's
> to my two next-door neighbors and put their names in my rwhois server.
> If I now promise to make 200 downstream IPv6 assignments within 60
> months, I'm qualified to receive a /32 of IPv6 space... based on that
> promise, my use of 4 IP addresses and my payment of the annual ARIN
> fee.
> 
> One wonders why I ever thought it was hard to get IPv6 addresses from
> ARIN...
> 
> Regards,
> Bill Herrin
> 
> 

I do not know if all of the efforts to keep the small guy (multi-DSL) users
off of the backbone are a good thing.  Looking back in the history of the
internet the then little folks using dialup were very instrumental in the
development and R&D that brought about what we enjoy today.

I for one would rather encourage these folks.  I believe the hassle and cost
of obtaining an ASN and going through the hoops to get an allocation are
enough to keep the frivolous users away.  

Working to exclude the experimenters and small users will ultimately prevent
good that could be done for the community.  I believe this outweighs any
small burden or abuse we would see from this sector.  Rather than fostering
an elitist attitude and trying to keep anyone who is not as big as us out,
we should be encouraging the small operator.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/734598ab/attachment.bin>

From tedm at ipinc.net  Tue Aug  4 15:31:41 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 04 Aug 2009 12:31:41 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
Message-ID: <4A788C9D.2050209@ipinc.net>

Kevin Kargel wrote:
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Tuesday, August 04, 2009 12:01 PM
>> To: Owen DeLong
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Multihomed Microallocations
>>
>> On Tue, Aug 4, 2009 at 12:15 PM, William Herrin<bill at herrin.us> wrote:
>>> On Tue, Aug 4, 2009 at 11:44 AM, Owen DeLong<owen at delong.com> wrote:
>>>> I suppose we can agree to disagree here. It does, actually impact
>>>> ISP allocations.  As soon as a person qualifies for a /24 under this
>>>> policy as an ISP, it would immediately convert them to a known
>>>> ISP in the ARIN service region and make them eligible to receive
>>>> a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
>>>> unnecessary barriers to multi-homing, I think giving an IPv6 /32
>>>> to every user that justifies a /24 as an ISP opens up a serious
>>>> hole in policy.
>>> Bullhockey. The 6.5.1.1 requirement is that the organization must "be
>>> an LIR" as defined under 2.4. That requires that they be allocated
>>> (not assigned) addresses from any other IR. Typically that's an RIR
>>> like ARIN but there's not restriction on it being another LIR.
>>
>> Come to think of it, under the current IPv6 policy, I can, right now,
>> today, have my ISP *allocate* me an IPv4 /30 on my single-homed $20
>> DSL connection *and* delegate rwhois to my server. Next I assign /32's
>> to my two next-door neighbors and put their names in my rwhois server.
>> If I now promise to make 200 downstream IPv6 assignments within 60
>> months, I'm qualified to receive a /32 of IPv6 space... based on that
>> promise, my use of 4 IP addresses and my payment of the annual ARIN
>> fee.
>>
>> One wonders why I ever thought it was hard to get IPv6 addresses from
>> ARIN...
>>
>> Regards,
>> Bill Herrin
>>
>>
> 
> I do not know if all of the efforts to keep the small guy (multi-DSL) users
> off of the backbone are a good thing.  Looking back in the history of the
> internet the then little folks using dialup were very instrumental in the
> development and R&D that brought about what we enjoy today.
> 
> I for one would rather encourage these folks.  I believe the hassle and cost
> of obtaining an ASN and going through the hoops to get an allocation are
> enough to keep the frivolous users away.  
> 
> Working to exclude the experimenters and small users will ultimately prevent
> good that could be done for the community.  I believe this outweighs any
> small burden or abuse we would see from this sector.  Rather than fostering
> an elitist attitude and trying to keep anyone who is not as big as us out,
> we should be encouraging the small operator.
> 


Why does the small user and experimenter WANT PI space in the first
place?  Well, their multihoming I hear you say.  Baloney.  You do not 
need PI space to multihome.  You can advertise an assignment from an 
upstream just fine.  So what that there's a covering route out there, 
you still have your redundancy.

When you boil it down it really comes to 2 reasons:

a) The small operator wants to be able to tell an upstream to kiss
off if they get pissy with him, without renumbering.  That's lock-in.

b) The small operator cannot get even a small amount of space (like
a /24) from an upstream because that upstream is severely constrained on IP.


Neither reason is really valid now.  Renumbering a /24 is childs play, 
if an "experimenter" or "small user" cannot manage to renumber a /24
they are incompetent and shouldn't be fooling around in this to begin 
with.  So what it's inconvenient - their desire for less inconvenience 
is at the expense of the entire Internet.  Thus, for a /24, lock-in is
a myth.

As for the upstream being constrained, well I don't see ARIN denying 
IPv4 requests right now.  Sure they will in the future - but there will 
be plenty of small /24's that are currently abandoned that ARIN will end 
up taking back as a result of recovery efforts.  If an upstream is 
claiming they are IP constrained that is a flat out lie.  Send them to 
the RIR for more numbering.

Now, maybe in the future this will change and little allocations won't
be available anymore.  So people are wanting to get their 
microallocations now, before the land rush.  OK, fine, no problem there. 
  But eventually no matter what policy is done, there won't be any
more allocations of any kind.

You might be throwing a lifeline to the small users and experimenters
right now, but only for the next few years crop of 'em.  After all,
what do you think becomes of experimenters when their IPv4 disappears? 
Those that have brains and courage come out all right; those that 
haven't are winnowed out.


Ted



From bill at herrin.us  Tue Aug  4 15:35:02 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 15:35:02 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <4A788C9D.2050209@ipinc.net>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
	<3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
Message-ID: <3c3e3fca0908041235l47581b2i820f6de170554c57@mail.gmail.com>

On Tue, Aug 4, 2009 at 3:31 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> Renumbering a /24 is childs play,

DNS pinning. Courtest of Internet Explorer, Firefox and yes, your
favorite web browser too.



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From kkargel at polartel.com  Tue Aug  4 16:48:13 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 4 Aug 2009 15:48:13 -0500
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <4A788C9D.2050209@ipinc.net>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>

> 
> Why does the small user and experimenter WANT PI space in the first
> place?  Well, their multihoming I hear you say.  Baloney.  You do not
> need PI space to multihome.  You can advertise an assignment from an
> upstream just fine.  So what that there's a covering route out there,
> you still have your redundancy.

Gee, last week when I suggested doing it that way people jumped all over me
telling me how that was broken and next to worthless..  I do agree with them
to a large degree based on what happens if I give IP space to a multi-home
customer, announce his network and the aggregate, another ISP announces only
the small network, and then my connection to the customer goes down.  

The only way (to my understanding and as I was told last week) to get a
fully functional redundancy model without LOTS of silly router tricks is for
the customer to have their own ASN.  When they have their own ASN I could
de-aggregate what I allocate to them, but once they have their own ASN
anyway then the 'might as well have their own netblock' comes in to play. 

> 
> When you boil it down it really comes to 2 reasons:
> 
> a) The small operator wants to be able to tell an upstream to kiss
> off if they get pissy with him, without renumbering.  That's lock-in.

This is not trivial.  Allowing provider independence is a good thing. I
enjoy it and I expect others do also. 
If we are trying to write ARIN policy to support an addictive business plan
I would call that a conflict of interest which should be vigorously avoided.


> 
> b) The small operator cannot get even a small amount of space (like
> a /24) from an upstream because that upstream is severely constrained on
> IP.

While I don't think that is typically the case now, I suspect it is
possible, and in the future will be likely.

c) They are interested, they want to educate themselves, experiment and do
it like the big people.  This is ok in my book and qualifies as a
justification.  Remember that there are costs and red tape hurdles to go
through that will limit this type of exercise.  Everybody has to start some
where, and this looks like a good starting point to me.  

> 
> 
> Neither reason is really valid now.  Renumbering a /24 is childs play,
> if an "experimenter" or "small user" cannot manage to renumber a /24
> they are incompetent and shouldn't be fooling around in this to begin
> with.  So what it's inconvenient - their desire for less inconvenience
> is at the expense of the entire Internet.  Thus, for a /24, lock-in is
> a myth.
> 
> As for the upstream being constrained, well I don't see ARIN denying
> IPv4 requests right now.  Sure they will in the future - but there will
> be plenty of small /24's that are currently abandoned that ARIN will end
> up taking back as a result of recovery efforts.  If an upstream is
> claiming they are IP constrained that is a flat out lie.  Send them to
> the RIR for more numbering.
> 
> Now, maybe in the future this will change and little allocations won't
> be available anymore.  So people are wanting to get their
> microallocations now, before the land rush.  OK, fine, no problem there.
>   But eventually no matter what policy is done, there won't be any
> more allocations of any kind.
> 
> You might be throwing a lifeline to the small users and experimenters
> right now, but only for the next few years crop of 'em.  After all,
> what do you think becomes of experimenters when their IPv4 disappears?
> Those that have brains and courage come out all right; those that
> haven't are winnowed out.

Well, if policy for the remainder of IPv4 life is only the next few years
and doesn't matter then we should all save ourselves a bunch of work and
quit wasting our time discussing IPv4 policy.  I don't buy this line of
thinking.

I really don't see this becoming a big burden on the backbone, and I see no
need to slam the door on the few that may want to do it and will be willing
to pay for it.

Kevin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/2890e2f1/attachment.bin>

From bill at herrin.us  Tue Aug  4 17:05:24 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 4 Aug 2009 17:05:24 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
	<3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
Message-ID: <3c3e3fca0908041405x7ac37862j9fef1146b9e4a59f@mail.gmail.com>

On Tue, Aug 4, 2009 at 4:48 PM, Kevin Kargel<kkargel at polartel.com> wrote:
> The only way (to my understanding and as I was told last week) to get a
> fully functional redundancy model without LOTS of silly router tricks is for
> the customer to have their own ASN. ?When they have their own ASN I could
> de-aggregate what I allocate to them, but once they have their own ASN
> anyway then the 'might as well have their own netblock' comes in to play.

Technically there is one additional way but it has all the
disadvantages of the customer using his own ASN plus an extra couple.
The customer can advertise his route to you using a private ASN. You
then strip the private ASN from the route so that it leaves your
network with your ASN as the origin. He does the same with his other
ISP, so the addresses originate from that network apparently from the
other ISP's ASN. As a result you have a route in the table apparently
from two different ASN's but really from a private ASN sitting behind
both of them.

Not a lot of folks do this. The only real gain from it is that it
preserves the customer's anonymity to limited degree while still
allowing them to multihome. It does not allow aggregation or keep any
routes out of the table.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From tedm at ipinc.net  Tue Aug  4 18:32:07 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 04 Aug 2009 15:32:07 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
Message-ID: <4A78B6E7.9020401@ipinc.net>

Kevin Kargel wrote:
>> Why does the small user and experimenter WANT PI space in the first
>> place?  Well, their multihoming I hear you say.  Baloney.  You do not
>> need PI space to multihome.  You can advertise an assignment from an
>> upstream just fine.  So what that there's a covering route out there,
>> you still have your redundancy.
> 
> Gee, last week when I suggested doing it that way people jumped all over me
> telling me how that was broken and next to worthless..  I do agree with them
> to a large degree based on what happens if I give IP space to a multi-home
> customer, announce his network and the aggregate, another ISP announces only
> the small network, and then my connection to the customer goes down.  
> 
> The only way (to my understanding and as I was told last week) to get a
> fully functional redundancy model without LOTS of silly router tricks is for
> the customer to have their own ASN.

Agreed.  I assumed an org (or person) would have their own ASN when
they were advertising a block allocated to them from their upstream.

That is how we did it for 8 years and it worked fine for us.

>  When they have their own ASN I could
> de-aggregate what I allocate to them, but once they have their own ASN
> anyway then the 'might as well have their own netblock' comes in to play. 
> 

No it doesn't.  As I said, we did it this way for 8 years before getting
portable space from ARIN.  If your a new ISP starting out how on earth
can you predict if your business will be a success or failure?  How
can you predict your future customer base until you go out and get
those customers?  You need to sell your services first, then worry about
getting portable numbers later, once you know what your customer base
will be.

The same things apply to PI space that's not reassignable.  If your
an org that starts out multihoming or some such, then how are you
going to know that the multihoming is even going to do what you think
it will do or help your org out at all, until you do it?   How do
you know your going to want to pay the extra money for it on an
ongoing basis?  Maybe your a small org with a connection that goes
down 20% of the time so you multihome, and discover that the new
connection goes down 1% of the time, while the original is still going
down 20% of the time.  Maybe you decide later that paying double
for multiple connections is stupid when you can save the money and
just keep the connection with 1% outage.

There's good reasons to start out with space assigned from an upstream.

There's also good reasons for getting your own space once the
provider-assigned space has proven itself and you know that you
have a need for the portable space.

>> When you boil it down it really comes to 2 reasons:
>>
>> a) The small operator wants to be able to tell an upstream to kiss
>> off if they get pissy with him, without renumbering.  That's lock-in.
> 
> This is not trivial.  Allowing provider independence is a good thing. I
> enjoy it and I expect others do also. 
> If we are trying to write ARIN policy to support an addictive business plan
> I would call that a conflict of interest which should be vigorously avoided.
> 

I wouldn't tell people to do things I wouldn't do myself.  We ran for
EIGHT YEARS with upstream-assigned space.  Don't lecture me with scare
stories about how terrible this is, I know most of that is hogwash.  It
seriously is just not that big of a deal as made out to be for small
allocations.  And we had a LOT of space, much more than a few /24's,
tied up this way.

Most of the gasoline consumed in US cars comes from the MidEast and
if that's not an addictive business plan with numerous conflicts of
interest I don't know what is.  Yet it's tolerated and even pushed in
some quarters.  Even today there's still people who would rather see
more oil wells than solar-power development.

"addictive resources" are present in many industries, the Internet is
not special at all in this regard.

> 
>> b) The small operator cannot get even a small amount of space (like
>> a /24) from an upstream because that upstream is severely constrained on
>> IP.
> 
> While I don't think that is typically the case now, I suspect it is
> possible, and in the future will be likely.
> 

I agree that it will be an issue in the future.  It will be an issue for
everyone, of course.  Some sooner than later.  Likely, the small orgs
will be affected earlier.

> c) They are interested, they want to educate themselves, experiment and do
> it like the big people.  This is ok in my book and qualifies as a
> justification.  Remember that there are costs and red tape hurdles to go
> through that will limit this type of exercise.  Everybody has to start some
> where, and this looks like a good starting point to me.  
> 

What about the people who want to educate themselves 5 years from now
when the only way to get more IPv4 is by buying it for lots of money in
large chunks?  Sooner or later the Internet is going to have to fish or
cut bait with IPv6.

>>
>> Neither reason is really valid now.  Renumbering a /24 is childs play,
>> if an "experimenter" or "small user" cannot manage to renumber a /24
>> they are incompetent and shouldn't be fooling around in this to begin
>> with.  So what it's inconvenient - their desire for less inconvenience
>> is at the expense of the entire Internet.  Thus, for a /24, lock-in is
>> a myth.
>>
>> As for the upstream being constrained, well I don't see ARIN denying
>> IPv4 requests right now.  Sure they will in the future - but there will
>> be plenty of small /24's that are currently abandoned that ARIN will end
>> up taking back as a result of recovery efforts.  If an upstream is
>> claiming they are IP constrained that is a flat out lie.  Send them to
>> the RIR for more numbering.
>>
>> Now, maybe in the future this will change and little allocations won't
>> be available anymore.  So people are wanting to get their
>> microallocations now, before the land rush.  OK, fine, no problem there.
>>   But eventually no matter what policy is done, there won't be any
>> more allocations of any kind.
>>
>> You might be throwing a lifeline to the small users and experimenters
>> right now, but only for the next few years crop of 'em.  After all,
>> what do you think becomes of experimenters when their IPv4 disappears?
>> Those that have brains and courage come out all right; those that
>> haven't are winnowed out.
> 
> Well, if policy for the remainder of IPv4 life is only the next few years
> and doesn't matter then we should all save ourselves a bunch of work and
> quit wasting our time discussing IPv4 policy.  I don't buy this line of
> thinking.
> 

Neither do I, I do not agree that once IPv4 runs out that there will be
no need of IPv4 policy, in fact, I think the reverse will be the case.

> I really don't see this becoming a big burden on the backbone, and I see no
> need to slam the door on the few that may want to do it and will be willing
> to pay for it.
> 

I don't either, but you keep flipping back and forth on your point, Kevin.

This terminology for example:

"...Working to exclude the experimenters and small users will ultimately 
prevent good that could be done for the community....Rather than 
fostering an elitist attitude and trying to keep anyone who is not as 
big as us out..."

contrasts with this:

"...slam the door on the few that may want to do it..."


The FEW.  Kevin, you said few, not me.  Your assuming, perhaps 
unconsciously, that there's only a small number that want to do this. 
Yet many times you make claims about the large number of people and orgs 
that want to do this.

I know your trying to be fair but I think that you have already
unconsciously accepted the premise that there needs to be a limit,
a "speedbump" as it were to just handing out small allocations
to anyone who asks.  You know, in your heart, that there is logic
there.

I am just saying here that there's good reasons that it has been
made difficult to get this space.  Now perhaps some of those are
not as valid anymore - routers today are more powerful and can hold
more routes, that kind of thing.  As well as the upcoming end of
IPv4.  Those are changed premises.  But, not ALL of the premises
originally used as reason to make that entry difficult have disappeared.
I would therefore go very, very cautiously here.

Ted


From kkargel at polartel.com  Tue Aug  4 19:00:39 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 4 Aug 2009 18:00:39 -0500
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <4A78B6E7.9020401@ipinc.net>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
	<4A78B6E7.9020401@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E73@mail>

> 
> "addictive resources" are present in many industries, the Internet is
> not special at all in this regard.
> 
The Internet is only special (as regards this focused topic) in that it
doesn't have to be that way.  It will only be that way if WE decide to make
it that way.  WE don't have a lot of say in those other industries, but we
do here.  WE can do it better than THEY did.

> >
> >> b) The small operator cannot get even a small amount of space (like
> >> a /24) from an upstream because that upstream is severely constrained
> on
> >> IP.
> >
> > While I don't think that is typically the case now, I suspect it is
> > possible, and in the future will be likely.
> >
> 
> I agree that it will be an issue in the future.  It will be an issue for
> everyone, of course.  Some sooner than later.  Likely, the small orgs
> will be affected earlier.
> 
> > c) They are interested, they want to educate themselves, experiment and
> do
> > it like the big people.  This is ok in my book and qualifies as a
> > justification.  Remember that there are costs and red tape hurdles to go
> > through that will limit this type of exercise.  Everybody has to start
> some
> > where, and this looks like a good starting point to me.
> >
> 
> What about the people who want to educate themselves 5 years from now
> when the only way to get more IPv4 is by buying it for lots of money in
> large chunks?  Sooner or later the Internet is going to have to fish or
> cut bait with IPv6.

The future people will have to contend with the future rules.  They may even
have to do it with IPv6.  

> 
> >>
> >> Neither reason is really valid now.  Renumbering a /24 is childs play,
> >> if an "experimenter" or "small user" cannot manage to renumber a /24
> >> they are incompetent and shouldn't be fooling around in this to begin
> >> with.  So what it's inconvenient - their desire for less inconvenience
> >> is at the expense of the entire Internet.  Thus, for a /24, lock-in is
> >> a myth.
> >>
> >> As for the upstream being constrained, well I don't see ARIN denying
> >> IPv4 requests right now.  Sure they will in the future - but there will
> >> be plenty of small /24's that are currently abandoned that ARIN will
> end
> >> up taking back as a result of recovery efforts.  If an upstream is
> >> claiming they are IP constrained that is a flat out lie.  Send them to
> >> the RIR for more numbering.
> >>
> >> Now, maybe in the future this will change and little allocations won't
> >> be available anymore.  So people are wanting to get their
> >> microallocations now, before the land rush.  OK, fine, no problem
> there.
> >>   But eventually no matter what policy is done, there won't be any
> >> more allocations of any kind.
> >>
> >> You might be throwing a lifeline to the small users and experimenters
> >> right now, but only for the next few years crop of 'em.  After all,
> >> what do you think becomes of experimenters when their IPv4 disappears?
> >> Those that have brains and courage come out all right; those that
> >> haven't are winnowed out.
> >
> > Well, if policy for the remainder of IPv4 life is only the next few
> years
> > and doesn't matter then we should all save ourselves a bunch of work and
> > quit wasting our time discussing IPv4 policy.  I don't buy this line of
> > thinking.
> >
> 
> Neither do I, I do not agree that once IPv4 runs out that there will be
> no need of IPv4 policy, in fact, I think the reverse will be the case.
> 
> > I really don't see this becoming a big burden on the backbone, and I see
> no
> > need to slam the door on the few that may want to do it and will be
> willing
> > to pay for it.
> >
> 
> I don't either, but you keep flipping back and forth on your point, Kevin.
> 
> This terminology for example:
> 
> "...Working to exclude the experimenters and small users will ultimately
> prevent good that could be done for the community....Rather than
> fostering an elitist attitude and trying to keep anyone who is not as
> big as us out..."
> 
> contrasts with this:
> 
> "...slam the door on the few that may want to do it..."
> 
> 

There are people and orgs doing this, not wanting to.  I don't think they
are creating a large problem.


> The FEW.  Kevin, you said few, not me.  Your assuming, perhaps
> unconsciously, that there's only a small number that want to do this.
> Yet many times you make claims about the large number of people and orgs
> that want to do this.
> 
> I know your trying to be fair but I think that you have already
> unconsciously accepted the premise that there needs to be a limit,
> a "speedbump" as it were to just handing out small allocations
> to anyone who asks.  You know, in your heart, that there is logic
> there.

The speedbump should be proportional to the problem.  I think that the
speedbump of requiring an ASN and the costs and admin load that goes with it
is plenty of limiting for this issue.

> 
> I am just saying here that there's good reasons that it has been
> made difficult to get this space.  Now perhaps some of those are
> not as valid anymore - routers today are more powerful and can hold
> more routes, that kind of thing.  As well as the upcoming end of
> IPv4.  Those are changed premises.  But, not ALL of the premises
> originally used as reason to make that entry difficult have disappeared.
> I would therefore go very, very cautiously here.

I am not even saying we need to do anything special to facilitate this.  All
I am suggesting is lets not draft new rules to proscribe it.  The system to
manage small user entry into ARIN space is there today.  If it ain't broke
don't fix it.


Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/af9500a5/attachment.bin>

From tedm at ipinc.net  Tue Aug  4 19:46:57 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 04 Aug 2009 16:46:57 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49E73@mail>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E67@mail>
	<4A788C9D.2050209@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E6E@mail>
	<4A78B6E7.9020401@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49E73@mail>
Message-ID: <4A78C871.80109@ipinc.net>

Kevin Kargel wrote:
>> "addictive resources" are present in many industries, the Internet is
>> not special at all in this regard.
>>
> The Internet is only special (as regards this focused topic) in that it
> doesn't have to be that way.  It will only be that way if WE decide to make
> it that way.  WE don't have a lot of say in those other industries, but we
> do here.  WE can do it better than THEY did.
> 

I think the issue under discussion is what constitutes "better"

> 
> The future people will have to contend with the future rules.

Is having those future rule changes something that your expecting
to have as a result of changing the current rules?

>>
> 
> There are people and orgs doing this, not wanting to.  I don't think they
> are creating a large problem.
>

If they are doing it now, and not causing a problem, why is there a
need to change the rules, to make it easier?


> 
> I am not even saying we need to do anything special to facilitate this.  All
> I am suggesting is lets not draft new rules to proscribe it.  The system to
> manage small user entry into ARIN space is there today. 

No it's not, "small user entry" is defined as a /22 in section 4.3.2.2,
the proposal under discussion essentially strips out the "critical
infrastructure provider" requirement from section 4.4 and replaces
it with a bunch of other requirements, because section 4.4 already
permits /24 allocations.

The existing section 4.4 does not in any way encompass what I think
your talking about with "small user" entry.

If you want to allow sub-/22 entrants you have to do it by making
policy changes, there's no way to avoid it.  That's why I submitted
"Last Minute Assistance for Small ISPs"  It is aimed at 4.2.2, a
different section entirely, and has a much more limited scope as the 
changes proposed in the other sections, but there is some overlap
in the arguments.

Ted


From farmer at umn.edu  Tue Aug  4 22:51:21 2009
From: farmer at umn.edu (David Farmer)
Date: 04 Aug 2009 21:51:21 -0500
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <4A78C871.80109@ipinc.net>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com><97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com><3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com><E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com><3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<4A78C871.80109@ipinc.net>
Message-ID: <Gophermail.2.0.0908042151210.27976@vs-w.tc.umn.edu>

On Aug 4 2009, Ted Mittelstaedt wrote:

>The existing section 4.4 does not in any way encompass what I think
>your talking about with "small user" entry.

Ted, 

I'm glad you mentioned this, I kind of missed that. 

Bill,

Is the intent that this actually replace section 4.4 Micro-allocation, 
which is about critical infrastructure micro-allocations. I think it is 
very important for critical infrastructure micro-allocations to be 
retained. They are for very different purposes, and the need for critical 
infrastructure micro-allocations is independent of this proposed policy. I 
don't support eliminating critical infrastructure micro-allocations at all.

David Farmer




From bill at herrin.us  Wed Aug  5 07:06:34 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 5 Aug 2009 07:06:34 -0400
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <Gophermail.2.0.0908042151210.27976@vs-w.tc.umn.edu>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>
	<3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>
	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>
	<4A78C871.80109@ipinc.net>
	<Gophermail.2.0.0908042151210.27976@vs-w.tc.umn.edu>
Message-ID: <3c3e3fca0908050406u4759ddabi84a7af31b748186b@mail.gmail.com>

On Tue, Aug 4, 2009 at 10:51 PM, David Farmer<farmer at umn.edu> wrote:
> On Aug 4 2009, Ted Mittelstaedt wrote:
>
>> The existing section 4.4 does not in any way encompass what I think
>> your talking about with "small user" entry.
>
> Ted,
> I'm glad you mentioned this, I kind of missed that.
> Bill,
>
> Is the intent that this actually replace section 4.4 Micro-allocation, which
> is about critical infrastructure micro-allocations. I think it is very
> important for critical infrastructure micro-allocations to be retained. They
> are for very different purposes, and the need for critical infrastructure
> micro-allocations is independent of this proposed policy. I don't support
> eliminating critical infrastructure micro-allocations at all.

This is an "I can't read a table of contents" error. 'doh! Make mine
4.11 instead of 4.4.

Though 4.4 and 4.9 could be reasonably replaced by the proposed
policy, that action should be taken separately *after* the proposed
policy proves out in practice.

-Bill




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From tedm at ipinc.net  Wed Aug  5 15:55:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 05 Aug 2009 12:55:05 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908050406u4759ddabi84a7af31b748186b@mail.gmail.com>
References: <3c3e3fca0908031556y1d0ba367kc92761a23b8b0fcb@mail.gmail.com>	
	<97F3D4FE-ABD1-4A42-8396-9BF7ED7AB2EE@delong.com>	
	<3c3e3fca0908040556o6334c02q6015c97f408e9fe0@mail.gmail.com>	
	<E745CA62-A2D4-4B35-ABB9-DBF6C86856E9@delong.com>	
	<3c3e3fca0908040915p40e1775clfa595bfa9e795de4@mail.gmail.com>	
	<3c3e3fca0908041001p59944a44ic30c61bd0b0fca61@mail.gmail.com>	
	<4A78C871.80109@ipinc.net>	
	<Gophermail.2.0.0908042151210.27976@vs-w.tc.umn.edu>
	<3c3e3fca0908050406u4759ddabi84a7af31b748186b@mail.gmail.com>
Message-ID: <4A79E399.8070409@ipinc.net>

William Herrin wrote:
> On Tue, Aug 4, 2009 at 10:51 PM, David Farmer<farmer at umn.edu> wrote:
>> On Aug 4 2009, Ted Mittelstaedt wrote:
>>
>>> The existing section 4.4 does not in any way encompass what I think
>>> your talking about with "small user" entry.
>> Ted,
>> I'm glad you mentioned this, I kind of missed that.
>> Bill,
>>
>> Is the intent that this actually replace section 4.4 Micro-allocation, which
>> is about critical infrastructure micro-allocations. I think it is very
>> important for critical infrastructure micro-allocations to be retained. They
>> are for very different purposes, and the need for critical infrastructure
>> micro-allocations is independent of this proposed policy. I don't support
>> eliminating critical infrastructure micro-allocations at all.
> 
> This is an "I can't read a table of contents" error. 'doh! Make mine
> 4.11 instead of 4.4.
> 
> Though 4.4 and 4.9 could be reasonably replaced by the proposed
> policy, that action should be taken separately *after* the proposed
> policy proves out in practice.
> 

We all need to do some typo/logic overview revising of our proposals I 
think.

Ted


From owen at delong.com  Tue Aug 11 20:04:11 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Aug 2009 17:04:11 -0700
Subject: [arin-ppml] New version of Proposal 99
Message-ID: <24BFD428-23BC-404C-AC67-7554EFE7D547@delong.com>

The proposal below is intended to clarify some things and address the  
comments and
questions from staff in their clarity and understanding document.

Comments, suggestions, and feedback are welcome.

Owen


TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1. Policy Proposal Name: /24 End User Minimum Allocation Unit 2.  
Proposal Originator
        a.      name: Owen DeLong
        b.      email: owen at delong.com
        c.      telephone: 408-890-7992
        d.      organization: Hurricane Electric

3. Proposal Version: 1.0
4. Date: 8/11/09
5. Proposal type: new
6. Policy term: permanent
7. Policy statement:

Replace section 4.3.2.2 of the NRPM with the following:

4.3.2.2 Multihomed Connection

For multi-homed 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 longer than /20, they will be  
from a block reserved for that purpose so long as that is feasible.  
End-users may not receive a block smaller than /22 under this policy  
if they already have IPv4 resources from ARIN, except as specified in  
section 4.3.6.2.

Renumber the existing paragraph under the 4.3.6 to

4.3.6.1 Utilization requirements for additional Assignment

Add the following paragraph 4.3.6.2

4.3.6.2 Replacement assignments for small multi-homers

Any end-user that possesses an assignment smaller than /22 under any  
part of section 4.3 shall not be able to get an additional assignment  
unless they agree to return all existing assignments within 12 months  
of receiving a new assignment. The new assignment shall be sized to  
accommodate their existing utilization in addition to their justified  
additional growth space under section 4.3.6.1. The common cases for  
this are expected to be a /24 returned after receipt of a /23, or a / 
23 returned after receipt of a /22.

8. Rationale:

This policy attempts to incorporate the recent and historical  
discussions of policy for multi-home users on PPML. The intent is to  
provide as fair a process as possible for multi-homed organizations  
down to the smallest feasible size while still preserving some control  
over growth in the routing table.

It has been repeatedly noted that /24 multi-homers exist today with PA  
space and still occupy a routing table slot, so, it is unlikely that  
moving this boundary to /24 would significantly impact the routing  
table.

By requiring smaller assignments to renumber and return, rather than  
add more small blocks to their assignments, this policy seeks to  
further reduce the chances of unnecessary growth in the routing table  
and encourage good aggregation where possible.

FAQs and responses to Staff Questions

Does this apply only to end users? Yes, this policy applies only to  
end users. This policy does not represent a good solution for  
organizations that are delegating space to other entities. If a case  
can be made that such a policy is needed for ISPs, then, the author is  
happy to work with interested parties to craft such a policy, but,  
this policy would be unnecessarily onerous on ISPs, and, as an ISP  
policy could be somewhat onerous to their peers and/or upstream  
providers.

What about resources obtained from policies other than 4.3 or outside  
of ARIN? Such resources would not be counted for excluding an  
organization from this policy. The intent is to limit IPv4 micro- 
allocations for multi-homed end-user organizations under this policy  
to a single assignment unless each such assignment is /22 or larger.  
This is to prevent unnecessary routing table growth. This is a  
tradeoff, and, not the ideal solution for smaller end-user  
organizations, however, author believes that this is the best policy  
likely to gain consensus at this time and believes that it is  
incrementally far better for such organizations than current policy.

If I grow, I have to renumber? Not necessarily... If you have a /24  
under this policy, and you want to grow that, then, you will likely  
need to renumber. Depending on ARIN resource management and timing,  
ARIN may simply be able to give you the /23 that includes your /24.  
More likely, you will get a new /23, have 1 year to renumber into that  
and return your /24. At most, you would be subject to two such  
renumbering cycles under this policy (24->23 and 23->22) before you  
meet the criteria for other policies which do not require renumbering.

Other policies don't include renumbering provisions, why this one? The  
policy which allows multi-homed organizations to get a /22 was  
originally written at /24. That policy was shouted down and /22 was  
the compromise achieved to gain community consensus for anything  
smaller than /20. Author hopes that this compromise will allow many  
organizations to get resources they need with minimal impact while  
assuring the community that doing so will not cause an explosion in  
the routing table.

9. Timetable for implementation: Immediate

END OF TEMPLATE


From info at arin.net  Wed Aug 12 08:18:19 2009
From: info at arin.net (Member Services)
Date: Wed, 12 Aug 2009 08:18:19 -0400
Subject: [arin-ppml] New version of Proposal 99
In-Reply-To: <24BFD428-23BC-404C-AC67-7554EFE7D547@delong.com>
References: <24BFD428-23BC-404C-AC67-7554EFE7D547@delong.com>
Message-ID: <4A82B30B.5050704@arin.net>

Policy Proposal 99
/24 End User Minimum Allocation Unit

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

Owen DeLong wrote:
> The proposal below is intended to clarify some things and address the 
> comments and
> questions from staff in their clarity and understanding document.
>
> Comments, suggestions, and feedback are welcome.
>
> Owen
>
>
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>
> 1. Policy Proposal Name: /24 End User Minimum Allocation Unit 2. 
> Proposal Originator
>        a.      name: Owen DeLong
>        b.      email: owen at delong.com
>        c.      telephone: 408-890-7992
>        d.      organization: Hurricane Electric
>
> 3. Proposal Version: 1.0
> 4. Date: 8/11/09
> 5. Proposal type: new
> 6. Policy term: permanent
> 7. Policy statement:
>
> Replace section 4.3.2.2 of the NRPM with the following:
>
> 4.3.2.2 Multihomed Connection
>
> For multi-homed 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 longer than /20, they will be 
> from a block reserved for that purpose so long as that is feasible. 
> End-users may not receive a block smaller than /22 under this policy 
> if they already have IPv4 resources from ARIN, except as specified in 
> section 4.3.6.2.
>
> Renumber the existing paragraph under the 4.3.6 to
>
> 4.3.6.1 Utilization requirements for additional Assignment
>
> Add the following paragraph 4.3.6.2
>
> 4.3.6.2 Replacement assignments for small multi-homers
>
> Any end-user that possesses an assignment smaller than /22 under any 
> part of section 4.3 shall not be able to get an additional assignment 
> unless they agree to return all existing assignments within 12 months 
> of receiving a new assignment. The new assignment shall be sized to 
> accommodate their existing utilization in addition to their justified 
> additional growth space under section 4.3.6.1. The common cases for 
> this are expected to be a /24 returned after receipt of a /23, or a 
> /23 returned after receipt of a /22.
>
> 8. Rationale:
>
> This policy attempts to incorporate the recent and historical 
> discussions of policy for multi-home users on PPML. The intent is to 
> provide as fair a process as possible for multi-homed organizations 
> down to the smallest feasible size while still preserving some control 
> over growth in the routing table.
>
> It has been repeatedly noted that /24 multi-homers exist today with PA 
> space and still occupy a routing table slot, so, it is unlikely that 
> moving this boundary to /24 would significantly impact the routing table.
>
> By requiring smaller assignments to renumber and return, rather than 
> add more small blocks to their assignments, this policy seeks to 
> further reduce the chances of unnecessary growth in the routing table 
> and encourage good aggregation where possible.
>
> FAQs and responses to Staff Questions
>
> Does this apply only to end users? Yes, this policy applies only to 
> end users. This policy does not represent a good solution for 
> organizations that are delegating space to other entities. If a case 
> can be made that such a policy is needed for ISPs, then, the author is 
> happy to work with interested parties to craft such a policy, but, 
> this policy would be unnecessarily onerous on ISPs, and, as an ISP 
> policy could be somewhat onerous to their peers and/or upstream 
> providers.
>
> What about resources obtained from policies other than 4.3 or outside 
> of ARIN? Such resources would not be counted for excluding an 
> organization from this policy. The intent is to limit IPv4 
> micro-allocations for multi-homed end-user organizations under this 
> policy to a single assignment unless each such assignment is /22 or 
> larger. This is to prevent unnecessary routing table growth. This is a 
> tradeoff, and, not the ideal solution for smaller end-user 
> organizations, however, author believes that this is the best policy 
> likely to gain consensus at this time and believes that it is 
> incrementally far better for such organizations than current policy.
>
> If I grow, I have to renumber? Not necessarily... If you have a /24 
> under this policy, and you want to grow that, then, you will likely 
> need to renumber. Depending on ARIN resource management and timing, 
> ARIN may simply be able to give you the /23 that includes your /24. 
> More likely, you will get a new /23, have 1 year to renumber into that 
> and return your /24. At most, you would be subject to two such 
> renumbering cycles under this policy (24->23 and 23->22) before you 
> meet the criteria for other policies which do not require renumbering.
>
> Other policies don't include renumbering provisions, why this one? The 
> policy which allows multi-homed organizations to get a /22 was 
> originally written at /24. That policy was shouted down and /22 was 
> the compromise achieved to gain community consensus for anything 
> smaller than /20. Author hopes that this compromise will allow many 
> organizations to get resources they need with minimal impact while 
> assuring the community that doing so will not cause an explosion in 
> the routing table.
>
> 9. Timetable for implementation: Immediate
>
> END OF TEMPLATE
> _______________________________________________
> 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 Aug 17 14:38:47 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 17 Aug 2009 11:38:47 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
 of IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
Message-ID: <4A89A3B7.9090009@gmail.com>

All,

Having reviewed all the discussion to date on 2009-3, I'd like to get a 
bit more feedback on changing this:

Each RIR through their respective chosen policies and strategies may 
recover IPv4 address space which is under their administration and 
designate any such space for return to the IANA.

to Bill Herrin's suggested text:

> Where authorized by their respective chosen policies and strategies,
> each RIR shall designate IPv4 address space recovered from its
> registrants for return to the IANA.

before submitting it for staff and legal review in preparation for Dearborn.

Any further comments, objections, or support?

Thanks,
Scott


From owen at delong.com  Mon Aug 17 14:52:27 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Aug 2009 11:52:27 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <4A89A3B7.9090009@gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
	<4A89A3B7.9090009@gmail.com>
Message-ID: <3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>

Bill's language sounds like all resources recovered under our policies  
should
be returned to IANA.  I am not comfortable with that wording.

Owen

On Aug 17, 2009, at 11:38 AM, Scott Leibrand wrote:

> All,
>
> Having reviewed all the discussion to date on 2009-3, I'd like to  
> get a bit more feedback on changing this:
>
> Each RIR through their respective chosen policies and strategies may  
> recover IPv4 address space which is under their administration and  
> designate any such space for return to the IANA.
>
> to Bill Herrin's suggested text:
>
>> Where authorized by their respective chosen policies and strategies,
>> each RIR shall designate IPv4 address space recovered from its
>> registrants for return to the IANA.
>
> before submitting it for staff and legal review in preparation for  
> Dearborn.
>
> Any further comments, objections, or support?
>
> 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.



From kkargel at polartel.com  Mon Aug 17 15:40:24 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Aug 2009 14:40:24 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F33@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Monday, August 17, 2009 1:52 PM
> To: Scott Leibrand
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> 
> Bill's language sounds like all resources recovered under our policies
> should
> be returned to IANA.  I am not comfortable with that wording.
> 
> Owen

I agree with Owen on this one.
Kevin


> 
> On Aug 17, 2009, at 11:38 AM, Scott Leibrand wrote:
> 
> > All,
> >
> > Having reviewed all the discussion to date on 2009-3, I'd like to
> > get a bit more feedback on changing this:
> >
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration and
> > designate any such space for return to the IANA.
> >
> > to Bill Herrin's suggested text:
> >
> >> Where authorized by their respective chosen policies and strategies,
> >> each RIR shall designate IPv4 address space recovered from its
> >> registrants for return to the IANA.
> >
> > before submitting it for staff and legal review in preparation for
> > Dearborn.
> >
> > Any further comments, objections, or support?
> >
> > 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/323f8a63/attachment.bin>

From bill at herrin.us  Mon Aug 17 15:59:56 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 17 Aug 2009 15:59:56 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
Message-ID: <3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>

On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
>>> Where authorized by their respective chosen policies and strategies,
>>> each RIR shall designate IPv4 address space recovered from its
>>> registrants for return to the IANA.

> Bill's language sounds like all resources recovered under our policies
> should be returned to IANA. ?I am not comfortable with that wording.

Would you be happier with "where permitted" or "where allowed" instead
of "where authorized?" Perhaps, "To the extent permitted by".

Fill in the blank man: _______, each RIR shall designate IPv4 address
space recovered from its registrants for return to the IANA.

Regards,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From leo.vegoda at icann.org  Mon Aug 17 16:14:14 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 17 Aug 2009 13:14:14 -0700
Subject: [arin-ppml] Multihomed Microallocations
In-Reply-To: <3c3e3fca0908040753w4ae7d4acw9071bbf1242e5d7f@mail.gmail.com>
Message-ID: <C6AF0826.2797C%leo.vegoda@icann.org>

On 04/08/2009 7:53, "William Herrin" <bill at herrin.us> wrote:

[...]

> Still, if the /22 minimum is demonstrated harmful and pay-enough has
> no finesse, what's a third alternative for controlling access to the
> BGP system so that we aren't overwhelmed by router expense? If there's
> a better way, I'm all for it.

You are right to suggest that the current policy is just as blunt but in
another way. But I don't think I have any magic answers to the problem. No
matter how you organize things, it hurts.

Regards,

Leo



From kkargel at polartel.com  Mon Aug 17 16:16:08 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Aug 2009 15:16:08 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F37@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Monday, August 17, 2009 3:00 PM
> To: Owen DeLong
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> 
> On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
> >>> Where authorized by their respective chosen policies and strategies,
> >>> each RIR shall designate IPv4 address space recovered from its
> >>> registrants for return to the IANA.
> 
> > Bill's language sounds like all resources recovered under our policies
> > should be returned to IANA. ?I am not comfortable with that wording.
> 
> Would you be happier with "where permitted" or "where allowed" instead
> of "where authorized?" Perhaps, "To the extent permitted by".
> 
> Fill in the blank man: _______, each RIR shall designate IPv4 address
> space recovered from its registrants for return to the IANA.
> 
> Regards,
> Bill

If we are going to leave it up to the discretion of the RIR whether or not
or how they do it then the entire clause is meaningless and should be
omitted.

Are we going to tell everyone they have to return the space or are we just
going to suggest it would be nice?  If it is the latter then it has no place
in policy.  There is no point in telling young Johnnie that he has to be
home no later than 10:00 unless he decides he wants to stay out later.  I
see no carrot, stick, or even enforceable limit emplaced here.

If we make this conditional on local policy then the RIR can do an end run
with a simple policy change.  With that in place the entire exercise is
meaningless.  

Let's not make policy rules that have no teeth, cannot be policed or are
unenforceable.  

> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/3dc32fed/attachment.bin>

From lea.roberts at stanford.edu  Mon Aug 17 16:21:10 2009
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Mon, 17 Aug 2009 13:21:10 -0700 (PDT)
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
Message-ID: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>

dear PPML community -

at the last meeting, ARIN XXIII, my perception was that the majority of
the opposition to Policy Proposal 2008-3 seemed to be a concern that the
inclusion of paid staff and a large budgetary number for network
operations could lead to its misuse as a "secret business plan" or other
abuse.

in an attempt to address these concerns, I would like to offer this latest
text for discussion on the PPML.  in this version, the definition has been
changed to limit this policy to all-volunteer staffed community networks.

from the original definition, the text:
"the community network staff is at least 50% volunteer and that the annual
budget for community network activities is less than $250,000."

has been replaced with:
"the community network staff is 100% volunteers."

hopefully this should mostly address the concerns for abuse...  I will
restate here at the beginning that it is not expected for these
assignments to be globally routed, since that was also a concern.

so, I would be most interested in PPML comments regarding the following:

if you support this proposal, please say so!!

from people opposed to the previous text, how well does this address your
concern(s)?  (after struggling with various formulae for budget numbers,
it seemed that making it just simpler was the best...)

do members of this community feel that this is a "significant" enough
change that Policy Proposal 2008-3 must be put on the agenda again, and
discussed further, at the ARIN XXIV meeting in Dearborn?

thanks in advance for your feedback!

Lea Roberts
AC shepherd for 2008-3

---------------------------------------------

the full text for the revised 2008-3 follows:

Policy Proposal 2008-3 Community Networks IPv6 Assignment

Author: Advisory Council

Date: 31 July 2009

Proposal type: new

Policy term: permanent

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is any network organized and operated by a
volunteer group operating as or under the fiscal support of a
non-profit organization or university for the purpose of providing
free or low-cost connectivity to the residents of their local service
area. To be treated as a community network under ARIN policy, the
applicant must certify to ARIN that the community network staff is
100% volunteers.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the
IPv4 policy currently in effect or be a qualifying Community Network
as defined in Section 2.8, with assignment criteria defined in section
6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Assignments

6.5.9.1 Qualification Criteria

To qualify for a direct assignment, a community network must
demonstrate it will immediately provide sustained service to at least
100 simultaneous users and must demonstrate a plan to provide
sustained service to at least 200 simultaneous users within one
year. For community networks located in rural regions or in the
Caribbean and North Atlantic Islands Sector, the numbers in these
qualification criteria may be relaxed at ARIN's discretion.

6.5.9.2. Initial assignment size

The minimum size of the assignment is /48. Organizations requesting a
larger assignment must provide documentation of the characteristics of
the Community Network's size and architecture that require the use of
additional subnets. An HD-Ratio of .94 with respect to subnet
utilization within the network must be met for all assignments larger
than a /48. These assignments shall be made from a distinctly
identified prefix and shall be made with a reservation for growth of
at least a /44. This reservation may be assigned to other
organizations later, at ARIN's discretion.

6.5.9.3. Subsequent assignment size

Additional assignments may be made when the need for additional
subnets is justified. Justification will be determined based on a
detailed plan of the network's architecture and the .94 HD-Ratio
metric. When possible, assignments will be made from an aggregatable
adjacent address block.


Rationale:

this policy was originally proposed by community network operators to
provide them with the ability to receive a direct assignment of IPv6
address resources from ARIN. the operators of such networks have
expressed their need to have a stable and globally unique address
assignment with which to number their network infrastructure. many
such networks are not able to meet the current criteria for a PI IPv6
assignment from ARIN. in an environment where connections to outside
networks may come and go, a stable internal address structure would be
very valuable. additionally, the ability to exchange routes with
others, whether locally or tunneled, and thereby have native IPv6
connectivity, would be quite beneficial. these operators were also
hopeful that, once this new class of address assignments was created,
they could pursue lower annual fees for community networks through the
ARIN Consultation and Suggestion Process (ACSP).

there could also be a number of potential benefits to allowing
community network participants to begin using IPv6 addressing. some of
these networks have many technically capable and adventurous members
who would be motivated to begin developing and/or experimenting with
the software extensions which will be needed to support IPv6 prefix
selection among multiple IPv6 prefixes when establishing remote
connections. also, participants in networks receiving such assignments
will have the necessary global-ID to experiment with the various
proposals currently being developed for separating network locater
from network ID.

also, during the more than one year timeframe that this policy has
been under consideration, other people have suggested other scenarios
where community networks would provide a valuable resource. one such
proposal was discussed at one of the Caribbean Sector meetings where
some participants pointed out the efforts were being made in remote or
sparsely populated areas to establish community networks which would
serve as connections back to educational resources for distant
learning capabilities. there are also many still wild areas of North
America where such community networks could provide improved
connectivity over telephone modems.

Timetable for implementation: Immediate.




From owen at delong.com  Mon Aug 17 16:19:52 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Aug 2009 13:19:52 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
Message-ID: <FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>


On Aug 17, 2009, at 12:59 PM, William Herrin wrote:

> On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
>>>> Where authorized by their respective chosen policies and  
>>>> strategies,
>>>> each RIR shall designate IPv4 address space recovered from its
>>>> registrants for return to the IANA.
>
>> Bill's language sounds like all resources recovered under our  
>> policies
>> should be returned to IANA.  I am not comfortable with that wording.
>
> Would you be happier with "where permitted" or "where allowed" instead
> of "where authorized?" Perhaps, "To the extent permitted by".
>
> Fill in the blank man: _______, each RIR shall designate IPv4 address
> space recovered from its registrants for return to the IANA.
>
The problem is SHALL.

s/shall/may/ and most of the preceding words work.

Owen



From kkargel at polartel.com  Mon Aug 17 16:27:41 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Aug 2009 15:27:41 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Monday, August 17, 2009 3:20 PM
> To: William Herrin
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> 
> 
> On Aug 17, 2009, at 12:59 PM, William Herrin wrote:
> 
> > On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
> >>>> Where authorized by their respective chosen policies and
> >>>> strategies,
> >>>> each RIR shall designate IPv4 address space recovered from its
> >>>> registrants for return to the IANA.
> >
> >> Bill's language sounds like all resources recovered under our
> >> policies
> >> should be returned to IANA.  I am not comfortable with that wording.
> >
> > Would you be happier with "where permitted" or "where allowed" instead
> > of "where authorized?" Perhaps, "To the extent permitted by".
> >
> > Fill in the blank man: _______, each RIR shall designate IPv4 address
> > space recovered from its registrants for return to the IANA.
> >
> The problem is SHALL.
> 
> s/shall/may/ and most of the preceding words work.

The problem with "may" in the absence of "may not" is that then the entire
clause is no longer policy but only a suggestion.  There are better venues
for suggestions than in policy.

> 
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/f037c3ea/attachment.bin>

From scottleibrand at gmail.com  Mon Aug 17 16:38:28 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 17 Aug 2009 13:38:28 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
Message-ID: <4A89BFC4.60902@gmail.com>

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Owen DeLong
>>
>> On Aug 17, 2009, at 12:59 PM, William Herrin wrote:
>>
>>     
>>> On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
>>>       
>>>>>> Where authorized by their respective chosen policies and
>>>>>> strategies,
>>>>>> each RIR shall designate IPv4 address space recovered from its
>>>>>> registrants for return to the IANA.
>>>>>>             
>>>> Bill's language sounds like all resources recovered under our
>>>> policies
>>>> should be returned to IANA.  I am not comfortable with that wording.
>>>>         
>>> Would you be happier with "where permitted" or "where allowed" instead
>>> of "where authorized?" Perhaps, "To the extent permitted by".
>>>
>>> Fill in the blank man: _______, each RIR shall designate IPv4 address
>>> space recovered from its registrants for return to the IANA.
>>>
>>>       
>> The problem is SHALL.
>>
>> s/shall/may/ and most of the preceding words work.
>>     
>
> The problem with "may" in the absence of "may not" is that then the entire
> clause is no longer policy but only a suggestion.  There are better venues
> for suggestions than in policy.
>   

This sentence is more than a suggestion, because it is needed to define 
"designated address space" for use in the subsequent sentence: "Each RIR 
shall at quarterly intervals return any such designated address space to 
the IANA in aggregated blocks of /24 or larger, for inclusion in the 
recovered IPv4 pool."

While turning onto the freeway on-ramp may be optional, once you've done 
so you MUST continue to the next exit.

All of the options under discussion basically do the same thing, 
AFAICT.  We're just trying to come up with the best language to express it.

-Scott


From kkargel at polartel.com  Mon Aug 17 16:45:26 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 17 Aug 2009 15:45:26 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A89BFC4.60902@gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
	<4A89BFC4.60902@gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>



> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Monday, August 17, 2009 3:38 PM
> To: Kevin Kargel
> Cc: Owen DeLong; William Herrin; ppml at arin.net
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
> Allocationof IPv4 Blocks to RIRs
> 
> Kevin Kargel wrote:
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> >> Behalf Of Owen DeLong
> >>
> >> On Aug 17, 2009, at 12:59 PM, William Herrin wrote:
> >>
> >>
> >>> On Mon, Aug 17, 2009 at 2:52 PM, Owen DeLong<owen at delong.com> wrote:
> >>>
> >>>>>> Where authorized by their respective chosen policies and
> >>>>>> strategies,
> >>>>>> each RIR shall designate IPv4 address space recovered from its
> >>>>>> registrants for return to the IANA.
> >>>>>>
> >>>> Bill's language sounds like all resources recovered under our
> >>>> policies
> >>>> should be returned to IANA.  I am not comfortable with that wording.
> >>>>
> >>> Would you be happier with "where permitted" or "where allowed" instead
> >>> of "where authorized?" Perhaps, "To the extent permitted by".
> >>>
> >>> Fill in the blank man: _______, each RIR shall designate IPv4 address
> >>> space recovered from its registrants for return to the IANA.
> >>>
> >>>
> >> The problem is SHALL.
> >>
> >> s/shall/may/ and most of the preceding words work.
> >>
> >
> > The problem with "may" in the absence of "may not" is that then the
> entire
> > clause is no longer policy but only a suggestion.  There are better
> venues
> > for suggestions than in policy.
> >
> 
> This sentence is more than a suggestion, because it is needed to define
> "designated address space" for use in the subsequent sentence: "Each RIR
> shall at quarterly intervals return any such designated address space to
> the IANA in aggregated blocks of /24 or larger, for inclusion in the
> recovered IPv4 pool."
> 
> While turning onto the freeway on-ramp may be optional, once you've done
> so you MUST continue to the next exit.
> 
> All of the options under discussion basically do the same thing,
> AFAICT.  We're just trying to come up with the best language to express
> it.
> 
> -Scott

I guess my point is that if everything is optional then it is not policy.
Perhaps someone who understands the intended process and goal could produce
a flowchart, and from that we could develop policy language.

If there are many options then perhaps we need a complex If/Then matrix that
would preclude a bypass option and would require one of many defined paths.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/1a3530c3/attachment.bin>

From bill at herrin.us  Mon Aug 17 17:01:14 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 17 Aug 2009 17:01:14 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
Message-ID: <3c3e3fca0908171401l4698580cifa80cf858f0cb6f0@mail.gmail.com>

On Mon, Aug 17, 2009 at 4:45 PM, Kevin Kargel<kkargel at polartel.com> wrote:
>> -----Original Message-----
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>> This sentence is more than a suggestion, because it is needed to define
>> "designated address space" for use in the subsequent sentence: "Each RIR
>> shall at quarterly intervals return any such designated address space to
>> the IANA in aggregated blocks of /24 or larger, for inclusion in the
>> recovered IPv4 pool."
>>
>> While turning onto the freeway on-ramp may be optional, once you've done
>> so you MUST continue to the next exit.
>>
>> All of the options under discussion basically do the same thing,
>> AFAICT. ?We're just trying to come up with the best language to express
>> it.
>
> I guess my point is that if everything is optional then it is not policy.

Kevin,

I think you and Scott had basically said the same thing here, which
I'm going to echo: there is no "maybe" in policy. Policy either does
or it does not.

Which means our choices here boil down to:

1. Set the terms under which we will return addresses to IANA.

2. Explain how we will set the terms under which we will return
addresses to IANA. (By enacting or failing to enact ARIN-region policy
that specifies which addresses are to be returned. Default: none.)

3. Abandon this global policy proposal and be the only region who
wouldn't let it move forward.

Unless someone wants to reopen that particular wound, we've already
determined that we're not ready to do #1 just yet. And #3 would make
us look bad.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Mon Aug 17 16:57:12 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Aug 2009 13:57:12 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F37@mail>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F37@mail>
Message-ID: <EF0349B3-A23C-4190-95E7-7FD08527A629@delong.com>

>
> If we are going to leave it up to the discretion of the RIR whether  
> or not
> or how they do it then the entire clause is meaningless and should be
> omitted.
>
Not entirely.

Without policy (globally coordinated policy), I'm not sure IANA has a
way to accept and/or re-issue space returned by RIRs, at least not
in chunks smaller than /8.

> Are we going to tell everyone they have to return the space or are  
> we just
> going to suggest it would be nice?  If it is the latter then it has  
> no place
> in policy.  There is no point in telling young Johnnie that he has  
> to be
> home no later than 10:00 unless he decides he wants to stay out  
> later.  I
> see no carrot, stick, or even enforceable limit emplaced here.
>
That's the big question.  I, for one, feel that it is inappropriate  
for an RIR to
return space to IANA if there is a justified need for that space to be  
issued
to other organizations within the RIR's region.  However, I do feel that
it is good for excess space in any region to be returned to IANA to be
redistributed to other regions.

> If we make this conditional on local policy then the RIR can do an  
> end run
> with a simple policy change.  With that in place the entire exercise  
> is
> meaningless.
>
Well... Said RIR can, essentially opt-out of returning the space to  
IANA,
but, the rest of the policy would still stand.  However, with a simple
policy change, an RIR can make it impossible to return space to the
RIR, so, I'm not sure there's much of a difference there.

I think it is reasonable to make enabling policy without necessarily
making it a forced issue. RIRs certainly should be able to return excess
space to IANA and certainly should be encouraged to do so. However,
I have an issue with RIRs being forced to return space which may not
be excess within their region, so much as in need of redistribution
within the region.

Owen

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

From scottleibrand at gmail.com  Mon Aug 17 17:06:05 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 17 Aug 2009 14:06:05 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
Message-ID: <4A89C63D.1000404@gmail.com>

Kevin Kargel wrote:
>   
>> This sentence is more than a suggestion, because it is needed to define
>> "designated address space" for use in the subsequent sentence: "Each RIR
>> shall at quarterly intervals return any such designated address space to
>> the IANA in aggregated blocks of /24 or larger, for inclusion in the
>> recovered IPv4 pool."
>>
>> While turning onto the freeway on-ramp may be optional, once you've done
>> so you MUST continue to the next exit.
>>
>> All of the options under discussion basically do the same thing,
>> AFAICT.  We're just trying to come up with the best language to express
>> it.
>>
>> -Scott
>>     
>
> I guess my point is that if everything is optional then it is not policy.
> Perhaps someone who understands the intended process and goal could produce
> a flowchart, and from that we could develop policy language.
>
> If there are many options then perhaps we need a complex If/Then matrix that
> would preclude a bypass option and would require one of many defined paths.
>   

I'm not sure it makes sense to re-write the global policy any more than 
we've already done, but let me see if I can explain the possibilities.  
As a background point, remember that global policies are supposed to 
define the RIRs' interactions with IANA, while local policies define the 
interactions between RIRs and the organizations in their region.

 - RIRs develop their own local policies and procedures  as to 
whether/how they want to reclaim IPv4 space.  If nothing is returned, do 
nothing here.
 - RIRs develop their own local strategies and policies for deciding 
what space goes back to IANA.  If nothing is designated, do nothing 
(until someone complains, and a policy/procedure to return space is 
adopted).
 - RIRs return any such designated space to IANA at quarterly intervals 
in aggregated blocks of /24.
 - IANA creates a returned address space pool.
 - When the IANA free pool is exhausted, and RIRs need more space, they 
can request space from the returned pool.
 - IANA gives out space to requesting RIRs, as defined in this global 
policy.

-Scott


From owen at delong.com  Mon Aug 17 17:10:40 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 17 Aug 2009 14:10:40 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0908171401l4698580cifa80cf858f0cb6f0@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
	<3c3e3fca0908171401l4698580cifa80cf858f0cb6f0@mail.gmail.com>
Message-ID: <294A5A55-8277-4156-9840-4880166AE84E@delong.com>

> Kevin,
>
> I think you and Scott had basically said the same thing here, which
> I'm going to echo: there is no "maybe" in policy. Policy either does
> or it does not.
>
> Which means our choices here boil down to:
>
> 1. Set the terms under which we will return addresses to IANA.
>
ARIN Should, in its process, set the policy by which it WILL return  
addresses
to IANA.

The Globally coordinated policy, OTOH, should be configured so that  
each RIR MAY set
such policy within their region.

If it is desirable, the Global policy COULD include a default policy  
that each
RIR MUST follow absent an RIR specific policy.

> 2. Explain how we will set the terms under which we will return
> addresses to IANA. (By enacting or failing to enact ARIN-region policy
> that specifies which addresses are to be returned. Default: none.)
>
Right... This is what should be done.  The globally coordinated  
policy, OTOH, is a
separate issue and is what is being discussed here.  I don't think a  
globally
coordinated policy which is forcing to the RIRs is likely to get passed.

If we put MAY in the globally coordinate policy, then, it allows for  
this
possibility to move forward.  If we leave it as SHALL, then, it is  
open to the
errant interpretation that any policy by which we reclaim resources  
requires
us to return those resources to IANA.

While I realize there are some who feel that is the correct answer, I do
not believe that any RIR should return addresses to IANA if those
addresses are immediately needed within the given RIR's service
region.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/41522ff7/attachment.p7s>

From stephen at sprunk.org  Mon Aug 17 18:08:50 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 17 Aug 2009 17:08:50 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A89C63D.1000404@gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
	<4A89C63D.1000404@gmail.com>
Message-ID: <4A89D4F2.4050303@sprunk.org>

Scott Leibrand wrote:
> I'm not sure it makes sense to re-write the global policy any more
> than we've already done, but let me see if I can explain the
> possibilities.  As a background point, remember that global policies
> are supposed to define the RIRs' interactions with IANA, while local
> policies define the interactions between RIRs and the organizations in
> their region.
>
> - RIRs develop their own local policies and procedures  as to
> whether/how they want to reclaim IPv4 space.  If nothing is returned,
> do nothing here.
> - RIRs develop their own local strategies and policies for deciding
> what space goes back to IANA.  If nothing is designated, do nothing
> (until someone complains, and a policy/procedure to return space is
> adopted).
> - RIRs return any such designated space to IANA at quarterly intervals
> in aggregated blocks of /24.
> - IANA creates a returned address space pool.
> - When the IANA free pool is exhausted, and RIRs need more space, they
> can request space from the returned pool.
> - IANA gives out space to requesting RIRs, as defined in this global
> policy.

This makes sense, except that it directly leads to fragmentation across
RIRs.

I oppose any policy that allows an RIR to return space to IANA in any
smaller unit than IANA originally allocated that particular space to an
RIR or directly assigned it to an end-user org (e.g. class B/C legacy
blocks in the "Various Registries" /8s) or does not require IANA to, to
the extent technically feasible, aggregate such returned blocks before
reallocating them to the most logical RIR.

For instance, imagine x.y.0.0/16 is currently APNIC and x.z/16 is
currently RIPE, and the two prefixes could by aggregated into a single
/15; if the former is returned, it should be offered to RIPE first, and
if the latter is returned, it should be offered to APNIC.  Neither
should be allowed to return a fraction of their block but should instead
reuse the remainder -- or encourage the remaining users to renumber out
so that the entire block can be returned.

Frankly, though, I don't see much point in this policy.  When we hit the
wall, everyone is going to be wanting more space and there will be none
in IANA's return pool.  When we finally come to our senses and switch to
IPv6, there will be loads of returns that nobody will want and that the
RIRs might as well hold on to in case of future stupidity in their
region.  Why make extra work for IANA just because one region might be
dumber than the others?  It'd be one thing if we were moving entire /8s,
but mere /24s?  That's nuts.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090817/af466cc1/attachment.bin>

From scottleibrand at gmail.com  Mon Aug 17 18:16:32 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 17 Aug 2009 15:16:32 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A89D4F2.4050303@sprunk.org>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com><3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com><4A89A3B7.9090009@gmail.com><3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com><3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>
Message-ID: <4A89D6C0.9000708@gmail.com>

Stephen Sprunk wrote:
> Scott Leibrand wrote:
>   
>> I'm not sure it makes sense to re-write the global policy any more
>> than we've already done, but let me see if I can explain the
>> possibilities.  As a background point, remember that global policies
>> are supposed to define the RIRs' interactions with IANA, while local
>> policies define the interactions between RIRs and the organizations in
>> their region.
>>
>> - RIRs develop their own local policies and procedures  as to
>> whether/how they want to reclaim IPv4 space.  If nothing is returned,
>> do nothing here.
>> - RIRs develop their own local strategies and policies for deciding
>> what space goes back to IANA.  If nothing is designated, do nothing
>> (until someone complains, and a policy/procedure to return space is
>> adopted).
>> - RIRs return any such designated space to IANA at quarterly intervals
>> in aggregated blocks of /24.
>> - IANA creates a returned address space pool.
>> - When the IANA free pool is exhausted, and RIRs need more space, they
>> can request space from the returned pool.
>> - IANA gives out space to requesting RIRs, as defined in this global
>> policy.
>>     
>
> This makes sense, except that it directly leads to fragmentation across
> RIRs.
>
> I oppose any policy that allows an RIR to return space to IANA in any
> smaller unit than IANA originally allocated that particular space to an
> RIR or directly assigned it to an end-user org (e.g. class B/C legacy
> blocks in the "Various Registries" /8s) or does not require IANA to, to
> the extent technically feasible, aggregate such returned blocks before
> reallocating them to the most logical RIR.
>
> For instance, imagine x.y.0.0/16 is currently APNIC and x.z/16 is
> currently RIPE, and the two prefixes could by aggregated into a single
> /15; if the former is returned, it should be offered to RIPE first, and
> if the latter is returned, it should be offered to APNIC.  Neither
> should be allowed to return a fraction of their block but should instead
> reuse the remainder -- or encourage the remaining users to renumber out
> so that the entire block can be returned.
>
> Frankly, though, I don't see much point in this policy.  When we hit the
> wall, everyone is going to be wanting more space and there will be none
> in IANA's return pool.  When we finally come to our senses and switch to
> IPv6, there will be loads of returns that nobody will want and that the
> RIRs might as well hold on to in case of future stupidity in their
> region.  Why make extra work for IANA just because one region might be
> dumber than the others?  It'd be one thing if we were moving entire /8s,
> but mere /24s?  That's nuts.

This is part of the reason for making the designation of space to return 
to IANA a matter of local policy.  All five RIRs need not agree in 
advance on how big a block must be to be "of global significance" and 
worth returning.  And in fact, that size is likely to shift over time.  
Instead, that can be defined in local policy at each RIR.

I think everyone, including the authors of the global policy, 
acknowledges that the actual impact may turn out to be small.  However, 
the risks of not setting up a structure for redistributing reclaimed 
space, in the event it is needed, are much higher than the risk of 
setting up such a structure, and then not using it (much).

-Scott


From michael.dillon at bt.com  Tue Aug 18 04:21:33 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 18 Aug 2009 09:21:33 +0100
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A89D4F2.4050303@sprunk.org>
Message-ID: <28E139F46D45AF49A31950F88C49745802B23F73@E03MVZ2-UKDY.domain1.systemhost.net>

> Frankly, though, I don't see much point in this policy.  When 
> we hit the wall, everyone is going to be wanting more space 
> and there will be none in IANA's return pool.  When we 
> finally come to our senses and switch to IPv6, there will be 
> loads of returns that nobody will want and that the RIRs 
> might as well hold on to in case of future stupidity in their 
> region.  Why make extra work for IANA just because one region 
> might be dumber than the others?  It'd be one thing if we 
> were moving entire /8s, but mere /24s?  That's nuts.

Well said!

I totally agree with this analysis of the proposal. There is no
point in returning IPv4 addresses to IANA.

The only thing that IANA can do with addresses is to give them 
to another RIR. Another reasonable way to address this is to
wait until a needy RIR approaches ARIN and deal with it at that
time.

--Michael Dillon


From owen at delong.com  Tue Aug 18 17:03:04 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 18 Aug 2009 14:03:04 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <28E139F46D45AF49A31950F88C49745802B23F73@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745802B23F73@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <C20C5DEC-FD86-48D9-9C9C-63913FC191A2@delong.com>


On Aug 18, 2009, at 1:21 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:

>> Frankly, though, I don't see much point in this policy.  When
>> we hit the wall, everyone is going to be wanting more space
>> and there will be none in IANA's return pool.  When we
>> finally come to our senses and switch to IPv6, there will be
>> loads of returns that nobody will want and that the RIRs
>> might as well hold on to in case of future stupidity in their
>> region.  Why make extra work for IANA just because one region
>> might be dumber than the others?  It'd be one thing if we
>> were moving entire /8s, but mere /24s?  That's nuts.
>
> Well said!
>
> I totally agree with this analysis of the proposal. There is no
> point in returning IPv4 addresses to IANA.
>
> The only thing that IANA can do with addresses is to give them
> to another RIR. Another reasonable way to address this is to
> wait until a needy RIR approaches ARIN and deal with it at that
> time.
>
Deal with it how? I believe there is not a policy in place to support
transfers between RIRs.

Most likely the way that would be accomplished would be for there
to be some policy (such as the one proposed) that pushes addresses
back to IANA for reissue to other RIRs.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090818/208abcf6/attachment.p7s>

From Wesley.E.George at sprint.com  Tue Aug 18 17:53:18 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Tue, 18 Aug 2009 16:53:18 -0500
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
In-Reply-To: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>
References: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A827B23B10@PLSWM01C.ad.sprint.com>

Comments inline

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lea Roberts
Sent: Monday, August 17, 2009 4:21 PM
To: ppml at arin.net
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)

dear PPML community -

at the last meeting, ARIN XXIII, my perception was that the majority of
the opposition to Policy Proposal 2008-3 seemed to be a concern that the
inclusion of paid staff and a large budgetary number for network
operations could lead to its misuse as a "secret business plan" or other
abuse.

from the original definition, the text:
"the community network staff is at least 50% volunteer and that the annual
budget for community network activities is less than $250,000."

has been replaced with:
"the community network staff is 100% volunteers."
<snip>
I think that this perhaps swings too far the other way. We're now requiring that any org like this have essentially no paid staff, which is probably not realistic. Even non-profits pay a few people to keep the trains running on time and coordinate the volunteer efforts. However, I'm not overly worried about abuse. My problem with this proposal comes in the sections I've snipped out below. I still do not see a strong justification for PI space to be available for networks such as these.


I will restate here at the beginning that it is not expected for these
assignments to be globally routed, since that was also a concern.
<snip>
If the intent is to have these not be globally routed, why would ULA not suffice as a stable address assignment?


6.5.9.1 Qualification Criteria

To qualify for a direct assignment, a community network must
demonstrate it will immediately provide sustained service to at least
100 simultaneous users and must demonstrate a plan to provide
sustained service to at least 200 simultaneous users within one
year.
6.5.9.2. Initial assignment size

The minimum size of the assignment is /48.
<snip>
I'm having trouble with the rationale of allocating a /48 for 100-200 users. Since this is not going to be globally routed, the concerns about blowing up the routing table should not figure into the discussion, so why not allocate something more appropriate for this size of network, even a /64?


Rationale:
this policy was originally proposed by community network operators to
provide them with the ability to receive a direct assignment of IPv6
address resources from ARIN. the operators of such networks have
expressed their need to have a stable and globally unique address
assignment with which to number their network infrastructure. many
such networks are not able to meet the current criteria for a PI IPv6
assignment from ARIN. in an environment where connections to outside
networks may come and go, a stable internal address structure would be
very valuable. additionally, the ability to exchange routes with
others, whether locally or tunneled, and thereby have native IPv6
connectivity, would be quite beneficial.
<snip>
As to the globally unique requirement - if it's not globally routed, what would be the need for this? This proposal wouldn't cover the so-called Grey nets, which are large (mainly "black helicopter"/Gov't) networks that must be unique because they talk to each other but don't talk to the Internet, so I'm struggling to understand global uniqueness as a requirement. Yes, it would need to be unique among any interconnected networks, but I think that the likelihood of multiple community networks interconnected without some intermediary that would not be able to loosely organize the allocation of space to ensure uniqueness between the networks' gateways is pretty low. Alternatively, PA space could be used for the interconnection.
It would be extremely helpful for one or more of the operators of such networks to come forward with a presentation at ARIN explaining the specific problem that having PI space would solve for them that PA or ULA space would not, rather than simply being cited in this way. Case studies are very helpful for those of us who are skeptical as to the application of this policy.


there could also be a number of potential benefits to allowing
community network participants to begin using IPv6 addressing. some of
these networks have many technically capable and adventurous members
who would be motivated to begin developing and/or experimenting with
the software extensions which will be needed to support IPv6 prefix
selection among multiple IPv6 prefixes when establishing remote
connections. also, participants in networks receiving such assignments
will have the necessary global-ID to experiment with the various
proposals currently being developed for separating network locater
from network ID.
<snip>
This is more like a justification for a Class E style "experimental" address reservation in IPv6, but perhaps without the behavior of being utterly useless because it can't be configured on any standard router, host, or network element. ;-)
I'd support a reservation of this type if it was explicitly defined as not to be treated any differently than normal IPv6 addresses, but simply a special block for research and other limited uses, perhaps still allocated via ARIN with explicit requirements around experimentation as the justification to qualify. However, I don't think that it helps to justify community network allocations as "community networks" are defined within this proposal. I think that it would be possible to write a proposal/RFC reserving space for experimental use that could be broad enough to cover a number of possible community network uses, but I don't think that trying to justify it in the opposite direction is realistic.

Thanks,

Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From martin.hannigan at batelnet.bs  Tue Aug 18 18:30:41 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 18 Aug 2009 18:30:41 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <28E139F46D45AF49A31950F88C49745802B23F73@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4A89D4F2.4050303@sprunk.org>
	<28E139F46D45AF49A31950F88C49745802B23F73@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4607e1d50908181530l1da7105h8891d5f1b0db7861@mail.gmail.com>

On Tue, Aug 18, 2009 at 4:21 AM, <michael.dillon at bt.com> wrote:
>> Frankly, though, I don't see much point in this policy. ?When
>> we hit the wall, everyone is going to be wanting more space
>> and there will be none in IANA's return pool. ?When we
>> finally come to our senses and switch to IPv6, there will be
>> loads of returns that nobody will want and that the RIRs
>> might as well hold on to in case of future stupidity in their
>> region. ?Why make extra work for IANA just because one region
>> might be dumber than the others? ?It'd be one thing if we
>> were moving entire /8s, but mere /24s? ?That's nuts.
>
> Well said!
>
> I totally agree with this analysis of the proposal. There is no
> point in returning IPv4 addresses to IANA.
>
> The only thing that IANA can do with addresses is to give them
> to another RIR. Another reasonable way to address this is to
> wait until a needy RIR approaches ARIN and deal with it at that
> time.
>


I've brought that approach up previously suggesting that while we
abandon this global policy we think about creating a process allowing
out-of-ARIN-region entities to apply directly to ARIN, subject to our
rules and the will of the members, for any excess space that "might"
become available. Sure, the IANA issued it before it became ICANN and
the RIR's existed, but noone could have foreseen that we would be here
today. The same social arguments can not apply (too many lawyers) and
I think that stewardship means that we serve the interest of our own
region first and foremost and then do the best that we can to assist
others. I think that this kind of approach does that.

1. Strictly subject inventory relased to "others" to some version of the ARIN RS
2. Insure that the same v4 is unable to be sold or transferred to any
other entity in any region for any reason
3. Subject to the BoT's emergency powers in case of abuse/failure

As far as this "policy" is concerned, I can't think of a good reason
to write local hooks into global policy. They are not only policy
hooks, but possible legal hooks (litigation magnets); they set
expectations. I would suggest a whole new policy that focused on ICANN
and a specific function of accepting returned IPv4 and V6 blocks
without any language geared towards "if RIR's" or "when RIR's" or
"RIR's may". Perhaps trying to correct this problem prior to v6
exhaustion in 2199 may be useful.

That, and the litany of arguments underlining the overall unfairness
of any sort of coerced for forced repatriation of v4 space to ICANN
should, IMHO, cause this policy to be abandoned. IMHO, of course.

Best,

Martin


From martin.hannigan at batelnet.bs  Tue Aug 18 18:34:20 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 18 Aug 2009 18:34:20 -0400
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
In-Reply-To: <4607e1d50908181518gc4d186es56669af966c1cc1@mail.gmail.com>
References: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>
	<4607e1d50908181518gc4d186es56669af966c1cc1@mail.gmail.com>
Message-ID: <4607e1d50908181534r53ad678bocdf8c28d910155ca@mail.gmail.com>

On Tue, Aug 18, 2009 at 6:18 PM, Martin
Hannigan<martin.hannigan at batelnet.bs> wrote:
> On Mon, Aug 17, 2009 at 4:21 PM, Lea Roberts<lea.roberts at stanford.edu> wrote:
>> dear PPML community -
>>
>> at the last meeting, ARIN XXIII, my perception was that the majority of
>> the opposition to Policy Proposal 2008-3 seemed to be a concern that the
>> inclusion of paid staff and a large budgetary number for network
>> operations could lead to its misuse as a "secret business plan" or other
>> abuse.
>>
>> in an attempt to address these concerns, I would like to offer this latest
>> text for discussion on the PPML. ?in this version, the definition has been
>> changed to limit this policy to all-volunteer staffed community networks.
>>
>> from the original definition, the text:
>> "the community network staff is at least 50% volunteer and that the annual
>> budget for community network activities is less than $250,000."
>>
>> has been replaced with:
>> "the community network staff is 100% volunteers."
>
> I think that we are trying to put lipstick on a pig. In doing some
> research on this policy and the apparent intent, my general feeling is
> that we ought to write a new policy (abandon this one to the scrap
> heap) and focus it on NGO's.
>
> Best,
>
> Martin
>


That was fast. Off list question:

1. Definition of NGO

http://en.wikipedia.org/wiki/Non-governmental_organization


-M<


From martin.hannigan at batelnet.bs  Tue Aug 18 18:18:44 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 18 Aug 2009 18:18:44 -0400
Subject: [arin-ppml] Community Networks IPv6 Assignment (2008-3 update)
In-Reply-To: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>
References: <Pine.LNX.4.44.0908171252180.14069-100000@networking.stanford.edu>
Message-ID: <4607e1d50908181518gc4d186es56669af966c1cc1@mail.gmail.com>

On Mon, Aug 17, 2009 at 4:21 PM, Lea Roberts<lea.roberts at stanford.edu> wrote:
> dear PPML community -
>
> at the last meeting, ARIN XXIII, my perception was that the majority of
> the opposition to Policy Proposal 2008-3 seemed to be a concern that the
> inclusion of paid staff and a large budgetary number for network
> operations could lead to its misuse as a "secret business plan" or other
> abuse.
>
> in an attempt to address these concerns, I would like to offer this latest
> text for discussion on the PPML. ?in this version, the definition has been
> changed to limit this policy to all-volunteer staffed community networks.
>
> from the original definition, the text:
> "the community network staff is at least 50% volunteer and that the annual
> budget for community network activities is less than $250,000."
>
> has been replaced with:
> "the community network staff is 100% volunteers."

I think that we are trying to put lipstick on a pig. In doing some
research on this policy and the apparent intent, my general feeling is
that we ought to write a new policy (abandon this one to the scrap
heap) and focus it on NGO's.

Best,

Martin


From owen at delong.com  Tue Aug 18 18:59:41 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 18 Aug 2009 15:59:41 -0700
Subject: [arin-ppml] 2008-3 Community WIreless Networks
Message-ID: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>

While I would agree that 100% volunteer is probably too far, I think  
it's better
than not getting any policy.

The AC was not able to agree on any course of action for this policy  
after the
last public policy meeting.

Personally, I feel that this policy is needed, and, that there are  
good reasons
for community networks to get provider independent space.

Community networks provide a useful service to a variety of populations,
many of whom would not otherwise have access to the internet. They also
tend to be in a position to provide communications resources in times  
when
more traditional means of communication may not be as readily available,
such as in times of disaster.

Many of these networks depend on the good will and support of local
or nearby providers and receive donated connectivity. In those cases,
having portable addresses and the ability to exchange routes with one
or more such providers and the ability to readily accept connections and
disconnections as they come is a very useful thing.

I think that claiming these networks would not be advertised on the  
global
internet was a mistake.  However, there are cases where community  
networks
need to interact with multiple organizations in a way that isn't  
entirely compatible
with ULA while still not being globally advertised.

One person suggested that a /64 would be adequate for 100-200 users.   
This
makes no allowance for the fact that each of those 100-200 users may,  
themselves
need a subnet.  In IPv6, a subnet is supposed to be a /64, so, that's  
at least a /56
in any case and still doesn't allow for the networks necessary to  
number the
infrastructure of the community network itself.

Many of these networks are not a single router sitting in a closet  
somewhere,
but, have significant metro-area infrastructure, often involving  
multiple
wireless links, VPNs, tunnels, and other diverse topologies.

One example of a community network that might put this in some
perspective can be found here: http://www.svwux.org

There are many, many more examples available, and, they are very diverse
in their designs, users served, and organizational structures.  About  
the only
thing most of them have in common is a need for portable stable  
addressing.

I can understand resistance to this idea in the IPv4 world, but, in  
the IPv6
world, it just doesn't make sense to prevent these organizations from  
getting
the addressing they need.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090818/65f2b8bc/attachment.p7s>

From tedm at ipinc.net  Tue Aug 18 20:38:29 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 18 Aug 2009 17:38:29 -0700
Subject: [arin-ppml] 2008-3 Community WIreless Networks
In-Reply-To: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
References: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
Message-ID: <4A8B4985.5010401@ipinc.net>

Owen DeLong wrote:
> While I would agree that 100% volunteer is probably too far, I think 
> it's better
> than not getting any policy.
> 
> The AC was not able to agree on any course of action for this policy 
> after the
> last public policy meeting.
> 
> Personally, I feel that this policy is needed, and, that there are good 
> reasons
> for community networks to get provider independent space.
> 

Owen,

   I've tried to figure out how to say the following without appearing
like Mr. Scrooge but I'll admit I just can't.  So I'll just go ahead
and say it and I'm sure I'll get some raspberries back.

I may just be a curmudgeon, but I've never understood this idea that
there's such a thing as charitable Internet service.  Charity to me is
when I throw some money to the local soup kitchen who uses it to buy
food to feed a hungry child who's jobless parents can't afford to buy
food.

But it seems to me that in urban areas, charitable Internet service 
should be handled through access through the local library, as it is in 
the towns around where I live, or through the usual organizations 
(Salvation Army or whatnot) that run centers for the poor to get 
resources.  It's not charity Internet service to run high speed
wireless connectivity to the poor.

As for rural areas, at least around here the rural dwellers are
either farmers who in bad times are getting tens of thousands of dollars
from the federal government in crop failure bailouts, or in good
times are making money hand over fist - or they are city dwellers
with remote getaway second homes.  Both of these knew what they
were getting into when they decided to live out in the sticks.
And all of them that want it can pick up their phone and call
hughesnet.com and for $60 a month get a megabit/sec down on a
DSS dish.

You cited http://www.svwux.org as an example but the front page
of svwux isn't talking about all the poor people they are giving
Internet to.  Add as for emergency services over wireless, give me
a break.  In a natural disaster, cellular data services is what
people will be using, not 802.11b stuff - but the biggest need
is for voice anyway, not data, and the ham radio community already
has that covered.  (or commercial satellite phones)

Anyway, with that said, the Rationale makes it pretty clear what the 
real goal of the proposal is:

"...these operators were also hopeful that, once this new class of 
address assignments was created, they could pursue lower annual fees for 
community networks through the ARIN Consultation and Suggestion Process 
(ACSP)...."


If a community network volunteer drives his car out to a
remote wireless router to fix it, his cost for gasoline is the same as 
our cost.  His cost for a roll of duct tape to fix the transmitter
(or solder, or whatever he uses) is the same as our cost.
If he pays for parking to park his car his cost is the same as our cost.
His cell phone he carries is charged the same as ours.  The food he
eats, the milk he drinks, is all the same as ours.

His org, even though volunteer-driven, wants to be treated the same
(from a routing perspective) as all of the rest of us.

So, why exactly should his org get a break on the fee?  If his org gets 
the break, all of the rest of us are going to pay for the difference -
perhaps a microscopic amount if it's just one org - but there won't be
just one org or this policy would have never been proposed.

To me it just stretches the definition of believability that Internet
service is so gosh darn critical that everyone who doesn't have it
at reduced cost or free right to their homes is at a severe disadvantage.

Ted


From bill at herrin.us  Tue Aug 18 21:22:13 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 18 Aug 2009 21:22:13 -0400
Subject: [arin-ppml] 2008-3 Community WIreless Networks
In-Reply-To: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
References: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
Message-ID: <3c3e3fca0908181822n7a9478a4qe056008da431f7dc@mail.gmail.com>

On Tue, Aug 18, 2009 at 6:59 PM, Owen DeLong<owen at delong.com> wrote:
> Personally, I feel that this policy is needed, and, that there are good
> reasons for community networks to get provider independent space.

Hi Owen,

Two comments:

1. If we pass one of the generalized proposals to extend ARIN IPv4
allocations to /24 for multihomed users or fix the general brokenness
in IPv6 policy for multihomed users as I previously suggested then
most of the issues raised in proposal 2008-3 become moot.

The only remaining community networks ineligible for ARIN IPv6
addresses would be single-homed and unconnected entities trying to
escape later renumbering pain, a justification ARIN's participants
have repeatedly shot down as inappropriate.

2. I'm not convinced that it's ARIN's proper place to intentionally,
directly and specifically engage in the noble redistribution of wealth
from the haves (companies which pay a lot for their BGP-capable
routers) to the have-nots (volunteer networks). 2008-3 smacks of Robin
Hood.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Tue Aug 18 21:45:54 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 18 Aug 2009 21:45:54 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A89D4F2.4050303@sprunk.org>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>
	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>
Message-ID: <3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>

On Mon, Aug 17, 2009 at 6:08 PM, Stephen Sprunk<stephen at sprunk.org> wrote:
> Frankly, though, I don't see much point in this policy.

Stephen,

My read on this (which could well be wrong; I'm not in the thick of
it) is that the point of this policy proposal is basically political.

The other four RIRs (who have already passed it) want us to
demonstrate a complete unwillingness to play ball with them following
free pool exhaustion so that they can come back and justify demanding
that the legacy registration pools (established before ARIN's
existance) be moved to a region-neutral 6th registrar since ARIN won't
play nice. There won't be any sixth registrar of course, but in the
process of arguing the case ARIN will be forced to concede control of
recovered addresses from the legacy areas that are only administered
by ARIN versus allocated to ARIN by IANA.

We really ought to move 2009-3 forward. Participating in the
establishment of a formal mechanism for redistributing addresses
between regions is the act of good faith that we need to derail the
politics here. After making it quite clear that just as with the UN,
we have no intention of giving up control over which of our resources
get sent to the rest of the world.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From Wesley.E.George at sprint.com  Wed Aug 19 09:55:29 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Wed, 19 Aug 2009 08:55:29 -0500
Subject: [arin-ppml] 2008-3 Community WIreless Networks
In-Reply-To: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
References: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A827B23D7C@PLSWM01C.ad.sprint.com>

Owen, thanks for the clarifications.

I was the one that suggested the /64. However, I didn't say that they should *only* be eligible for a /64, only that under the pretense that they were not globally routed, we should start with a /64, with justification allowing larger allocations as necessary. Needing to delegate blocks to users is a valid justification for needing more than a /64. If you agree that assuming these will never show up on the Internet is a stretch, then a /48 probably makes sense as the minimum. I'll dispense with rehashing the obvious concern about routing table growth for now.

However, this confusion illustrates my problem with this proposal - no one can seem to even define what is and is not a community network, what purpose they might serve, what addresses and scope they might or might not need, and how to make the definition narrow enough to prevent abuse, while still being wide enough to be useful to a critical mass of the intended group. Therefore no one can come up with a universal justification for why globally unique PI space (and/or a reduced fee) is a requirement for all (or even most) of these applications and more importantly, what makes them unique compared with other ARIN members who are expected to qualify under the existing rules.

Most of the examples you cite are community networks of the rural ISP variety. This means that in order to provide service, they upstream connectivity to the Internet. Whether they get it for free/cheap or pay full price, I have trouble believing that they can provide a usable service (even when viewed through the "you get what you pay for" filter) if they don't have a stable connection to one or more providers that would be willing to give them address space. If this is just about trying to prevent unnecessary renumbers, I'm failing to understand why this would be different from any other small ISP that doesn't qualify for ARIN PI, pays full price for their upstream, and has to renumber out of their current PA space if they change providers. We don't tend to make exceptions for non-profits in other sectors, so is this about ARIN trying to advance the cause of universal Internet service by making it easier for these would-be ISPs? Seems awfully far into the political realm for an org like ARIN for my taste.

I agree with Martin that we should probably abandon this proposal and try again.
Please don't misinterpret this as me being against any proposal of this type, as I can see genuine value in having address space available for the hobbyists/experimenters/innovators out there. As I said in my previous mail, I think that we'd be better off with a proposal that allows for direct PI allocations for experimental networks, and then make the requirements such that some subset of community networks, especially the ones that don't necessarily count "ISP" among their primary objectives, would qualify to get space that way.
It's semantics, but I think it addresses an important concern that keeps coming up in this debate - not being so stingy with the very large address space that is IPv6 that we stifle innovation, while not being wasteful or opening up a loophole to provide everyone with a router and a non-profit business plan a /48 to announce to the global Internet.
Perhaps an update to NRPM section 11 with a slightly broader definition of experimental? Specifically, I'm thinking about allowing for open-ended experimental plans, with some provision to revisit the progress and justification for the experiment periodically to see if the allocation is still justified.

If we are genuinely concerned about the cost of the ARIN fees for small/experimental/hobby/community networks, perhaps we also need a separate policy that covers some manner of need-based exceptions to allow for reduction in fees for worthwhile causes.

Thanks,
Wes George
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Tuesday, August 18, 2009 7:00 PM
To: ARIN PPML
Subject: [arin-ppml] 2008-3 Community WIreless Networks

While I would agree that 100% volunteer is probably too far, I think
it's better
than not getting any policy.

The AC was not able to agree on any course of action for this policy
after the
last public policy meeting.

Personally, I feel that this policy is needed, and, that there are
good reasons
for community networks to get provider independent space.

Community networks provide a useful service to a variety of populations,
many of whom would not otherwise have access to the internet. They also
tend to be in a position to provide communications resources in times
when
more traditional means of communication may not be as readily available,
such as in times of disaster.

Many of these networks depend on the good will and support of local
or nearby providers and receive donated connectivity. In those cases,
having portable addresses and the ability to exchange routes with one
or more such providers and the ability to readily accept connections and
disconnections as they come is a very useful thing.

I think that claiming these networks would not be advertised on the
global
internet was a mistake.  However, there are cases where community
networks
need to interact with multiple organizations in a way that isn't
entirely compatible
with ULA while still not being globally advertised.

One person suggested that a /64 would be adequate for 100-200 users.
This
makes no allowance for the fact that each of those 100-200 users may,
themselves
need a subnet.  In IPv6, a subnet is supposed to be a /64, so, that's
at least a /56
in any case and still doesn't allow for the networks necessary to
number the
infrastructure of the community network itself.

Many of these networks are not a single router sitting in a closet
somewhere,
but, have significant metro-area infrastructure, often involving
multiple
wireless links, VPNs, tunnels, and other diverse topologies.

One example of a community network that might put this in some
perspective can be found here: http://www.svwux.org

There are many, many more examples available, and, they are very diverse
in their designs, users served, and organizational structures.  About
the only
thing most of them have in common is a need for portable stable
addressing.

I can understand resistance to this idea in the IPv4 world, but, in
the IPv6
world, it just doesn't make sense to prevent these organizations from
getting
the addressing they need.

Owen


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From plzakr at gmail.com  Wed Aug 19 10:19:54 2009
From: plzakr at gmail.com (Ray Plzak)
Date: Wed, 19 Aug 2009 10:19:54 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for
	the	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	<4A89A3B7.9090009@gmail.com>	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	<4A89C63D.1000404@gmail.com>
	<4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
Message-ID: <005401ca20d8$20dc1740$629445c0$@com>

BTW - there is an entity that is perfectly willing to step in and be that
neutral 6th registry. They have proposed that they be so designated. That
entity is the ITU.

Ray

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of William Herrin
Sent: Tuesday, August 18, 2009 21:46
To: Stephen Sprunk
Cc: ARIN PPML
Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
Allocationof IPv4 Blocks to RIRs

On Mon, Aug 17, 2009 at 6:08 PM, Stephen Sprunk<stephen at sprunk.org> wrote:
> Frankly, though, I don't see much point in this policy.

Stephen,

My read on this (which could well be wrong; I'm not in the thick of
it) is that the point of this policy proposal is basically political.

The other four RIRs (who have already passed it) want us to
demonstrate a complete unwillingness to play ball with them following
free pool exhaustion so that they can come back and justify demanding
that the legacy registration pools (established before ARIN's
existance) be moved to a region-neutral 6th registrar since ARIN won't
play nice. There won't be any sixth registrar of course, but in the
process of arguing the case ARIN will be forced to concede control of
recovered addresses from the legacy areas that are only administered
by ARIN versus allocated to ARIN by IANA.

We really ought to move 2009-3 forward. Participating in the
establishment of a formal mechanism for redistributing addresses
between regions is the act of good faith that we need to derail the
politics here. After making it quite clear that just as with the UN,
we have no intention of giving up control over which of our resources
get sent to the rest of the world.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
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 martin.hannigan at batelnet.bs  Wed Aug 19 14:43:21 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 19 Aug 2009 14:43:21 -0400
Subject: [arin-ppml] 2008-3 Community WIreless Networks
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A827B23D7C@PLSWM01C.ad.sprint.com>
References: <D03C05AB-9F22-45F0-9DE1-53098D4B758A@delong.com>
	<F7EB0A7C707E39409A73CD0353242551A827B23D7C@PLSWM01C.ad.sprint.com>
Message-ID: <4607e1d50908191143g39d09592o44bdcfc3f290cc85@mail.gmail.com>

On Wed, Aug 19, 2009 at 9:55 AM, George, Wes E
[NTK]<Wesley.E.George at sprint.com> wrote:
> Owen, thanks for the clarifications.
>

[ snip ]

> I agree with Martin that we should probably abandon this proposal and try again.
> Please don't misinterpret this as me being against any proposal of this type, as I can see genuine value in having address space available for the hobbyists/experimenters/innovators out there. As I said in my previous mail, I think that we'd be better off with a proposal that allows for direct PI allocations for experimental networks, and then make the requirements such that some subset of community networks, especially the ones that don't necessarily count "ISP" among their primary objectives, would qualify to get space that way.

Perhaps elaborating on the NGO idea may be helpful. NGO's are usually
non-profit organizations that are dedicated to "doing good" for people
that "need to have some good done" for them. We could use the intent
of this policy and instead of direct allocations to end users we can
allocate to NGO's to support funded projects to "bring the net" to the
masses. This solves a few problems. I would expect that funded
organizations would be able to meet ARIN standards as far as the RSA
goes and be point for law enforcement inquiries; we wouldn't have
allocation islands hanging in the wind with no apparent responsibility
party. The NGO would be the party entering into the agreement with
ARIN and hopefully their plan to allocate to 200 networks would be
written to state that anyone applying for the allocations would be
allocated regardless of being islands or stubs. Defining NGO is a
challenge because we are likely to have every non profit on the planet
claim that they are an NGO -- which may not be such a bad thing.

This may allow more experienced entities to determine non-technical
delegation need (social need since this seems to be the intent of the
policy) and do the work more effectively than "we " can. At least in
theory. People who have need get space, we get our agreement signed by
responsible parties, our fees are paid, people that want whois
contacts get their contacts, and people who want to do good get to do
good.

> It's semantics, but I think it addresses an important concern that keeps coming up in this debate - not being so stingy with the very large address space that is IPv6 that we stifle innovation, while not being wasteful or opening up a loophole to provide everyone with a router and a non-profit business plan a /48 to announce to the global Internet.
> Perhaps an update to NRPM section 11 with a slightly broader definition of experimental? Specifically, I'm thinking about allowing for open-ended experimental plans, with some provision to revisit the progress and justification for the experiment periodically to see if the allocation is still justified.

I think we should consider the NGO approach before we widen the
definition of experimental to be honest. I fear that we would see far
more exploitation of the latter.

Best Regards,

Marty


From tedm at ipinc.net  Wed Aug 19 18:31:19 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 19 Aug 2009 15:31:19 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for
 the	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	<4A89A3B7.9090009@gmail.com>	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	<4A89C63D.1000404@gmail.com>
	<4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
Message-ID: <4A8C7D37.1040808@ipinc.net>

William Herrin wrote:
> On Mon, Aug 17, 2009 at 6:08 PM, Stephen Sprunk<stephen at sprunk.org> wrote:
>> Frankly, though, I don't see much point in this policy.
> 
> Stephen,
> 
> My read on this (which could well be wrong; I'm not in the thick of
> it) is that the point of this policy proposal is basically political.
> 
> The other four RIRs (who have already passed it) want us to
> demonstrate a complete unwillingness to play ball with them following
> free pool exhaustion so that they can come back and justify demanding
> that the legacy registration pools (established before ARIN's
> existance) be moved to a region-neutral 6th registrar since ARIN won't
> play nice. There won't be any sixth registrar of course, but in the
> process of arguing the case ARIN will be forced to concede control of
> recovered addresses from the legacy areas that are only administered
> by ARIN versus allocated to ARIN by IANA.
> 

And this would be a problem...why, exactly?

> We really ought to move 2009-3 forward. Participating in the
> establishment of a formal mechanism for redistributing addresses
> between regions is the act of good faith that we need to derail the
> politics here. After making it quite clear that just as with the UN,
> we have no intention of giving up control over which of our resources
> get sent to the rest of the world.
> 

They ain't -our- resources.  They are IANA's, who just gave them to
ARIN to administer.

How can ARIN go to an address hog and claim with a straight face that
the hog must give up their unused addresses, or clean up their act,
and quit hoarding them - and then turn around and do exactly the same
thing?

Ted


From scottleibrand at gmail.com  Wed Aug 19 18:42:54 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Aug 2009 15:42:54 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for
 the	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A8C7D37.1040808@ipinc.net>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	<4A89A3B7.9090009@gmail.com>	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	<4A89C63D.1000404@gmail.com>	<4A89D4F2.4050303@sprunk.org>	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net>
Message-ID: <4A8C7FEE.7010805@gmail.com>

Ted Mittelstaedt wrote:
> William Herrin wrote:
>
>> We really ought to move 2009-3 forward. Participating in the
>> establishment of a formal mechanism for redistributing addresses
>> between regions is the act of good faith that we need to derail the
>> politics here. After making it quite clear that just as with the UN,
>> we have no intention of giving up control over which of our resources
>> get sent to the rest of the world.
>>
>
> They ain't -our- resources.  They are IANA's, who just gave them to
> ARIN to administer.
>
> How can ARIN go to an address hog and claim with a straight face that
> the hog must give up their unused addresses, or clean up their act,
> and quit hoarding them - and then turn around and do exactly the same
> thing?

So are you in favor of 2009-3, along with a local policy to return 
unused addresses to IANA?  Or are you advocating something else?

Thanks,
Scott


From tedm at ipinc.net  Wed Aug 19 19:55:00 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 19 Aug 2009 16:55:00 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for
 the	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A8C7FEE.7010805@gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	<4A89A3B7.9090009@gmail.com>	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	<4A89C63D.1000404@gmail.com>	<4A89D4F2.4050303@sprunk.org>	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
Message-ID: <4A8C90D4.9090200@ipinc.net>

Scott Leibrand wrote:
> Ted Mittelstaedt wrote:
>> William Herrin wrote:
>>
>>> We really ought to move 2009-3 forward. Participating in the
>>> establishment of a formal mechanism for redistributing addresses
>>> between regions is the act of good faith that we need to derail the
>>> politics here. After making it quite clear that just as with the UN,
>>> we have no intention of giving up control over which of our resources
>>> get sent to the rest of the world.
>>>
>>
>> They ain't -our- resources.  They are IANA's, who just gave them to
>> ARIN to administer.
>>
>> How can ARIN go to an address hog and claim with a straight face that
>> the hog must give up their unused addresses, or clean up their act,
>> and quit hoarding them - and then turn around and do exactly the same
>> thing?
> 
> So are you in favor of 2009-3, along with a local policy to return 
> unused addresses to IANA? 

Yes and no.  I am not really in favor of 2009-3 as written but I would
like to see aggregation occur.  2009-3 seems to take the approach that
all recovered legacy space goes to IANA who then aggregates it and
then doles out the aggregated blocks.  Well, that's one way to do it.

Another way would be for the RIR's to periodically engage in trading
where say a RIR has a chunk that has adjacent blocks in use managed
by another RIR (or that should be managed by another RIR) well why
can't they just horse trade among each other to say well I have this
block that you could aggregate with some of your stuff and I'll give it
to you, with the expectation that you will give me some blocks you
have that are best managed by me.  Why formalize the interaction between
RIRs, after all isn't this kind of work what we pay them to do?  I
guess I have reservations in keeping IANA involved in the day to day
operations work.  I'd rather see IANA come in only when it's clear that
RIR's aren't cooperating with each other and someone has to make the
Solomon decision of cutting the baby in half.

Ultimately if push comes to shove IANA supersedes.  So if there's no
other way to do it than by this sort of global policy, I would be
convinced to support it.  I just wonder if we shouldn't just try
RIR-to-RIR cooperation first, and only bring in IANA if that doesn't work.

Ted


From mueller at syr.edu  Thu Aug 20 18:10:16 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 20 Aug 2009 18:10:16 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for
	the	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A8C90D4.9090200@ipinc.net>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89A3B7.9090009@gmail.com>
	<3E453731-6CEB-4EEB-AD2A-68F108766758@delong.com>
	<3c3e3fca0908171259g2c7d67acxf1ab86e564ea488d@mail.gmail.com>
	<FBDF7A41-5163-42E1-9B5A-33C0BE5F0A79@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F39@mail>	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	<4A89C63D.1000404@gmail.com>
	<4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
	<4A8C90D4.9090200@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>

> by another RIR (or that should be managed by another RIR) well why
> can't they just horse trade among each other to say well I have this
> block that you could aggregate with some of your stuff and 
> I'll give it to you, with the expectation that you will give me some blocks you
> have that are best managed by me.  

This strikes me as a pretty good idea. (Details need to be worked out, obviously) 
While one might want to keep voluntary return to IANA as an option, why not also authorize direct trades among RIRs (just in-kind trades, not purchases). 

Why centralize a function and introduce an intermediary if you don't have to? 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 
 

From martin.hannigan at batelnet.bs  Fri Aug 21 12:24:18 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 21 Aug 2009 12:24:18 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89BFC4.60902@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
	<4A8C90D4.9090200@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>

On Thu, Aug 20, 2009 at 6:10 PM, Milton L Mueller<mueller at syr.edu> wrote:
>> by another RIR (or that should be managed by another RIR) well why
>> can't they just horse trade among each other to say well I have this
>> block that you could aggregate with some of your stuff and
>> I'll give it to you, with the expectation that you will give me some blocks you
>> have that are best managed by me.
>
> This strikes me as a pretty good idea. (Details need to be worked out, obviously)
> While one might want to keep voluntary return to IANA as an option, why not also authorize direct trades among RIRs (just in-kind trades, not purchases).
>
> Why centralize a function and introduce an intermediary if you don't have to?
>


It is a decent  idea. I'm skeptical that the other RIR's would sign up
for such a system since a) they may want it to apply to legacy space
only since none are likely to hand over their inventories at the end
(at least greater than 1 x /8) and b) that means that ARIN would be
the heaviest outflow by default. How about if AfriNIC and LACNIC stop
taking /8's and start taking fragments from APNIC, RIPE, and ARIN
instead? That might promote better utilization. (Details..routing
table slots, etc...but they are going to get used one way or
another....)

FWIW, voluntary return of address space to ICANN (IANA) has always
been an option regardless of there being a policy in existence to
specifically state it. It's not like ICANN would say "no", I think we
just can't be sure what they'd do with it if we didn't have it
codified. Modifying the existing ratified policy with a sentence like
"All returned IPv4 space regardless of it's class will be remanded to
the free pool and allocated on a needs basis". That change would
likely fly through the RIR PDP's and accomplish exactly what we are
"trying" to accomplish here without all of the politics and
appearances of land-grabs.

Best,

Martin


From tedm at ipinc.net  Fri Aug 21 15:35:20 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 21 Aug 2009 12:35:20 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	
	<4A89BFC4.60902@gmail.com>	
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49F3D@mail>	
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>	
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>	
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>	
	<4A8C90D4.9090200@ipinc.net>	
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
	<4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>
Message-ID: <4A8EF6F8.9070904@ipinc.net>

Martin Hannigan wrote:
> On Thu, Aug 20, 2009 at 6:10 PM, Milton L Mueller<mueller at syr.edu> wrote:
>>> by another RIR (or that should be managed by another RIR) well why
>>> can't they just horse trade among each other to say well I have this
>>> block that you could aggregate with some of your stuff and
>>> I'll give it to you, with the expectation that you will give me some blocks you
>>> have that are best managed by me.
>> This strikes me as a pretty good idea. (Details need to be worked out, obviously)
>> While one might want to keep voluntary return to IANA as an option, why not also authorize direct trades among RIRs (just in-kind trades, not purchases).
>>
>> Why centralize a function and introduce an intermediary if you don't have to?
>>
> 
> 
> It is a decent  idea. I'm skeptical that the other RIR's would sign up
> for such a system

Right there I think we already have the beginnings of a problem, with 
your term of "system"

This implies a formal system, I was speaking of an INFORMAL "system".

Ideally the hostmaster of ARIN should be able to send an e-mail to the
hostmaster of, for example, RIPE and say  "I noticed that we got block
W.X.Y.Z/24 given back to us from Wonkulating Gronkulators, and I
also noticed that your managing the 2 adjacent /24's that surround it
and it seems to make more sense for you to take W.X.Y.Z/24 so why
don't you take it over?"

In short they should be able to just do these things without having to
go through all the rackafratz of handing it back to IANA for IANA to
hand back out to RIPE.

Or am I assuming too much about the hostmasters of the RIR's?  I had
always thought the ARIN hostmaster we worked with seemed to be a
pretty competent fellow, but maybe I'm wrong and we need Grandma Iana
to supervise this?


  since a) they may want it to apply to legacy space
> only since none are likely to hand over their inventories at the end
> (at least greater than 1 x /8) and b) that means that ARIN would be
> the heaviest outflow by default.

So what?  The point here is to get the IPv4 in service, right, isn't
that the whole point of reclamation?  Who cares if the people that
use it are in North America or elsewhere?  The sooner we get the
bits and pieces assigned out the sooner all the scrap IPv4 will
be put in service and then people won't have an excuse any longer
to think that there really is some sort of future with IPv4 and
will have to get serious about IPv6.

  How about if AfriNIC and LACNIC stop
> taking /8's and start taking fragments from APNIC, RIPE, and ARIN
> instead? That might promote better utilization. (Details..routing
> table slots, etc...but they are going to get used one way or
> another....)
> 
> FWIW, voluntary return of address space to ICANN (IANA) has always
> been an option regardless of there being a policy in existence to
> specifically state it. It's not like ICANN would say "no", I think we
> just can't be sure what they'd do with it if we didn't have it
> codified. Modifying the existing ratified policy with a sentence like
> "All returned IPv4 space regardless of it's class will be remanded to
> the free pool and allocated on a needs basis". That change would
> likely fly through the RIR PDP's and accomplish exactly what we are
> "trying" to accomplish here without all of the politics and
> appearances of land-grabs.
> 

"land-grabs" the very word assumes that IPv4 property will have
indefinite future value.

Anyone taking IPv4 right now is a speculator, pure and simple.  When
an ISP gets IPv4 they are doing so because they are gambling that
they will need it for the future.  Years ago that was a very safe bet,
today with IPv4 running out, it is a question of how many more years
are you going to need it.

If I could tell you that in exactly 2 years, IPv4 will be regarded as
worthless because everyone will be on IPv6, would you spend the time now
to apply for IPv4?  What if I told you that in 6 months it will be
worthless?  We all agree it's going to be worthless someday, the 
question is when.

The situation is akin to the community that has a old bridge in the 
middle of it that's falling apart.  The community knows that sooner or
later the bridge will fall, but they spend lots of time debating how
much more time they have left before the bridge collapses.  Then one
day the bridge unexpectedly does collapse, and everyone then says
"gee, I was sure it was going to collapse but I didn't think it would
be TODAY!!!"

Ted


From martin.hannigan at batelnet.bs  Fri Aug 21 16:59:19 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 21 Aug 2009 16:59:19 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A8EF6F8.9070904@ipinc.net>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
	<4A8C90D4.9090200@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
	<4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>
	<4A8EF6F8.9070904@ipinc.net>
Message-ID: <4607e1d50908211359v7fb79628gf2ad462b02422a85@mail.gmail.com>

On Fri, Aug 21, 2009 at 3:35 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> Martin Hannigan wrote:
>>
>> On Thu, Aug 20, 2009 at 6:10 PM, Milton L Mueller<mueller at syr.edu> wrote:
>>>>
>>>> by another RIR (or that should be managed by another RIR) well why
>>>> can't they just horse trade among each other to say well I have this
>>>> block that you could aggregate with some of your stuff and
>>>> I'll give it to you, with the expectation that you will give me some
>>>> blocks you
>>>> have that are best managed by me.
>>>
>>> This strikes me as a pretty good idea. (Details need to be worked out,
>>> obviously)
>>> While one might want to keep voluntary return to IANA as an option, why
>>> not also authorize direct trades among RIRs (just in-kind trades, not
>>> purchases).
>>>
>>> Why centralize a function and introduce an intermediary if you don't have
>>> to?
>>>
>>
>>
>> It is a decent ?idea. I'm skeptical that the other RIR's would sign up
>> for such a system
>
> Right there I think we already have the beginnings of a problem, with your
> term of "system"
>
> This implies a formal system, I was speaking of an INFORMAL "system".
>
> Ideally the hostmaster of ARIN should be able to send an e-mail to the
> hostmaster of, for example, RIPE and say ?"I noticed that we got block
> W.X.Y.Z/24 given back to us from Wonkulating Gronkulators, and I
> also noticed that your managing the 2 adjacent /24's that surround it
> and it seems to make more sense for you to take W.X.Y.Z/24 so why
> don't you take it over?"
>
> In short they should be able to just do these things without having to
> go through all the rackafratz of handing it back to IANA for IANA to
> hand back out to RIPE.

Sounds like an idea to me. Anything is better than what is currently
on the table, IMHO. As long as any ARIN ipv4 address space won't be
transferred away or provided to someone that is not subject to the
ARIN RSA I would support that kind of proposal.

> Or am I assuming too much about the hostmasters of the RIR's? ?I had
> always thought the ARIN hostmaster we worked with seemed to be a
> pretty competent fellow

They certainly are good fellas. And ladies too!


Best,

Martin


From martin.hannigan at batelnet.bs  Fri Aug 21 17:03:40 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 21 Aug 2009 17:03:40 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4A8EF6F8.9070904@ipinc.net>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
	<4A8C90D4.9090200@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
	<4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>
	<4A8EF6F8.9070904@ipinc.net>
Message-ID: <4607e1d50908211403j54a40a55ke64618729e3746d1@mail.gmail.com>

On Fri, Aug 21, 2009 at 3:35 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> Martin Hannigan wrote:
>>

> This implies a formal system, I was speaking of an INFORMAL "system".
>
> Ideally the hostmaster of ARIN should be able to send an e-mail to the
> hostmaster of, for example, RIPE and say ?"I noticed that we got block
> W.X.Y.Z/24 given back to us from Wonkulating Gronkulators, and I
> also noticed that your managing the 2 adjacent /24's that surround it
> and it seems to make more sense for you to take W.X.Y.Z/24 so why
> don't you take it over?"
>
> In short they should be able to just do these things without having to
> go through all the rackafratz of handing it back to IANA for IANA to
> hand back out to RIPE.


Ted,

You can always write a global proposal to try and move such an idea
forward. If you would like some advice or assistance in conducting
such an activity, please let myself or one of the others members of
the ASO AC (Louis Lee and Jason Schiller) we can point you in the
right direction.

That goes for anyone else as well. Anyone can submit a global policy
much like anyone can submit a local policy.


Best Regards,

Martin Hannigan
ASO AC/NRO NC


From martin.hannigan at batelnet.bs  Fri Aug 21 17:08:45 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 21 Aug 2009 17:08:45 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4607e1d50908211403j54a40a55ke64618729e3746d1@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
	<4A89D4F2.4050303@sprunk.org>
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>
	<4A8C90D4.9090200@ipinc.net>
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>
	<4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>
	<4A8EF6F8.9070904@ipinc.net>
	<4607e1d50908211403j54a40a55ke64618729e3746d1@mail.gmail.com>
Message-ID: <4607e1d50908211408o7df2a95atdfc9f5a4da77c95d@mail.gmail.com>

Ted, sorry! I'm typing a tad too fast today. :-) Correction inserted.


>
> Ted,
>
> You can always write a global proposal to try and move such an idea
> forward. If you would like some advice or assistance in conducting
> such an activity, please let myself or one of the other members of
> the ASO AC (Louis Lee and Jason Schiller) know so that we can point you in the
> right direction.
>
> That goes for anyone else as well. Anyone can submit a global policy
> much like anyone can submit a local policy.
>
>
> Best Regards,
>
> Martin Hannigan
> ASO AC/NRO NC
>


From tedm at ipinc.net  Fri Aug 21 17:59:41 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 21 Aug 2009 14:59:41 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
 Allocationof IPv4 Blocks to RIRs
In-Reply-To: <4607e1d50908211403j54a40a55ke64618729e3746d1@mail.gmail.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>	
	<4A89C63D.1000404@gmail.com> <4A89D4F2.4050303@sprunk.org>	
	<3c3e3fca0908181845l48c33465ga34efdf80748956b@mail.gmail.com>	
	<4A8C7D37.1040808@ipinc.net> <4A8C7FEE.7010805@gmail.com>	
	<4A8C90D4.9090200@ipinc.net>	
	<75822E125BCB994F8446858C4B19F0D78FFC6D28@SUEX07-MBX-04.ad.syr.edu>	
	<4607e1d50908210924j7fde93b2j358b1e9e04fd6442@mail.gmail.com>	
	<4A8EF6F8.9070904@ipinc.net>
	<4607e1d50908211403j54a40a55ke64618729e3746d1@mail.gmail.com>
Message-ID: <4A8F18CD.9080500@ipinc.net>

Martin Hannigan wrote:
> On Fri, Aug 21, 2009 at 3:35 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> Martin Hannigan wrote:
> 
>> This implies a formal system, I was speaking of an INFORMAL "system".
>>
>> Ideally the hostmaster of ARIN should be able to send an e-mail to the
>> hostmaster of, for example, RIPE and say  "I noticed that we got block
>> W.X.Y.Z/24 given back to us from Wonkulating Gronkulators, and I
>> also noticed that your managing the 2 adjacent /24's that surround it
>> and it seems to make more sense for you to take W.X.Y.Z/24 so why
>> don't you take it over?"
>>
>> In short they should be able to just do these things without having to
>> go through all the rackafratz of handing it back to IANA for IANA to
>> hand back out to RIPE.
> 
> 
> Ted,
> 
> You can always write a global proposal to try and move such an idea
> forward. If you would like some advice or assistance in conducting
> such an activity, please let myself or one of the others members of
> the ASO AC (Louis Lee and Jason Schiller) we can point you in the
> right direction.
> 
> That goes for anyone else as well. Anyone can submit a global policy
> much like anyone can submit a local policy.
> 

Thanks, Martin.

I think probably it would be good to see how 2009-3 fares, first.

I feel it's important for 2009-3 to get it's chance for an "up/down" vote.

I think many in the community feel that once the last IPv4 is handed
out that we should get all hands on board to get to IPv6 and leave
IPv4 in the dust, that efforts on IPv4 recovery are ultimately just
prolonging the supply of IPv4 for a short time, and serve as a
distraction to IPv6 adoption.  I suspect this feeling drives much of
the uncertainty around 2009-3

My feeling is the community needs to reach consensus on the value of
IPv4 recovery.  I feel this will happen quicker if it is shown that
IPv4 recovery efforts have value, ie: that they are actually working.
This is why we put in the clause:

"...ARIN will maintain, and make readily available to the community, a 
current list of number resources with no valid POC..."

into proposal 2008-7, as once ARIN starts supplying this data it will
be easy to draw conclusions as to whether IPv4 recovery will produce
significant IPv4, in the ARIN region at any rate, as well as alter the
timeline as to when IPv4 exhaustion is "really going to happen"


Ted




  on consensus on 2009-3

> 
> Best Regards,
> 
> Martin Hannigan
> ASO AC/NRO NC
> 



From info at arin.net  Wed Aug 26 13:44:30 2009
From: info at arin.net (Member Services)
Date: Wed, 26 Aug 2009 13:44:30 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - August 2009
Message-ID: <4A95747E.1090204@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 20 August 2009 and made decisions about
several policy proposals and draft policies.

I. The AC selected the following proposals and changed them into draft
policies for adoption discussion online and at the upcoming Public
Policy Meeting. The draft policies will be posted shortly to the PPML.

Policy Proposal 89 (Global): Internet Assigned Numbers Authority (IANA)
Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries

Policy Proposal 90: Open Access To IPv6

Policy Proposal 93: Equitable IPv4 Run Out

II. The AC selected the following draft policy for adoption discussion
online and at the upcoming Public Policy Meeting. It will be posted
shortly to the PPML.

Draft Policy 2009-3: (Global): Allocation of IPv4 Blocks to Regional
Internet Registries

III. The AC used portions of ?Policy Proposal 94: Predictable IPv4 Run
Out by Allocation Window? to help with the creation of the ?Equitable
IPv4 Run Out.? The AC considers proposal 94 to be closed.

IV. The AC abandoned ?Policy Proposal 96: Transfer Listing Service.? The
AC suggested that the President direct this matter through the ARIN
Consultation and Suggestion Process.

V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting
List for Unmet IPv4 Requests? until after the October Public Policy Meeting.

VI. The AC accepted the following proposals on to the AC's docket for
development and evaluation. There is not an adequate amount of time to
create and publish draft policies in time for the October Public Policy
Meeting.

Policy Proposal 98: Last Minute Assistance for Small ISPs

Policy Proposal 99: /24 End User Minimum Allocation Unit

VII. The AC abandoned ?Policy Proposal 100: Multihomed Microallocations.?

VIII. The AC sent a revised ?2008-3: Community Networks IPv6 Assignment?
to an extended last call. The text will be posted shortly to the PPML.

The PDP states, ?Any member of the community, including a proposal
originator, may initiate a Discussion Petition if they are dissatisfied
with the action taken by the Advisory Council regarding any specific
policy proposal.? Several of the AC?s decisions above resulted in
proposals not being selected for adoption discussion. The purpose of a
petition would be to change a proposal into a draft policy for
discussion on the Public Policy Mailing List and at the October meeting.
The deadline to begin a petition is 2 September 2009.

The following can be petitioned (status in parens):

Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window
(merged and closed)

Policy Proposal 96: Transfer Listing Service (abandoned)

Policy Proposal 97: Waiting List for Unmet IPv4 Requests (delayed)

Policy Proposal 98: Last Minute Assistance for Small ISPs (added to AC?s
docket)

Policy Proposal 99: /24 End User Minimum Allocation Unit (added to AC?s
docket)

Policy Proposal 100: Multihomed Microallocations (abandoned)

For more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.html

Draft Policy and Policy Proposal texts under discussion 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,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Wed Aug 26 13:48:52 2009
From: info at arin.net (Member Services)
Date: Wed, 26 Aug 2009 13:48:52 -0400
Subject: [arin-ppml] =?windows-1252?q?Draft_Policy_2008-3=3A_Community_Net?=
 =?windows-1252?q?works_IPv6_Assignment_=96_Last_Call?=
Message-ID: <4A957584.4040608@arin.net>

Draft Policy 2008-3
Community Networks IPv6 Assignment

On 20 August 2009 the ARIN Advisory Council (AC) decided to send an
updated version of Draft Policy 2008-3 to a 21-day last call.

?The ARIN Advisory Council, based on comments from stakeholders
expressed at the last three ARIN Public Policy Meetings (ARIN XXI, ARIN
XXII and ARIN XXIII) and on the ARIN Public Policy Mailing List, having
reviewed the comments collected, as well as the latest ARIN staff and
legal reviews; and, updated the policy accordingly, and noting that the
Policy Development Process has been followed, finds Advisory Council and
Community support for Draft Policy 2008-3: Community Networks IPv6
Assignment, and moves to it to a 21-day extended Last Call.?

Feedback is encouraged during this last call period. All comments must
be provided to the Public Policy Mailing List. This last call will
expire at 2:00 PM EDT, 17 September 2009.

The policy proposal text is provided below and is also available at:
https://www.arin.net/policy/proposals/2008_3.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2008-3
Community Networks IPv6 Assignment

Date: 19 August 2009

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network

A community network is any network organized and operated by a volunteer
group operating as or under the fiscal support of a non-profit
organization or university for the purpose of providing free or low-cost
connectivity to the residents of their local service area. To be treated
as a community network under ARIN policy, the applicant must certify to
ARIN that the community network staff is 100% volunteers.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect, or demonstrate efficient utilization of all
direct IPv4 assignments and allocations, each of which must be covered
by any current ARIN RSA, or be a qualifying Community Network as defined
in Section 2.8, with assignment criteria defined in section 6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Assignments

6.5.9.1 Qualification Criteria

To qualify for a direct assignment, a community network must demonstrate
it will immediately provide sustained service to at least 100
simultaneous users and must demonstrate a plan to provide sustained
service to at least 200 simultaneous users within one year. For
community networks located in rural regions (population less than 2,500)
or in the Caribbean and North Atlantic Islands Sector, the numbers in
these qualification criteria may be relaxed at ARIN's discretion.

6.5.9.2. Initial assignment size

The minimum size of the assignment is /48. Organizations requesting a
larger assignment must provide documentation of the characteristics of
the Community Network's size and architecture that require the use of
additional subnets. An HD-Ratio of .94 with respect to subnet
utilization within the network must be met for all assignments larger
than a /48. These assignments shall be made from a distinctly identified
prefix and shall be made with a reservation for growth of at least a
/44. This reservation may be assigned to other organizations later, at
ARIN's discretion.

6.5.9.3. Subsequent assignment size

Additional assignments may be made when the need for additional subnets
is justified. Justification will be determined based on a detailed plan
of the network's architecture and the .94 HD-Ratio metric. When
possible, assignments will be made from an aggregatable adjacent address
block.

Rationale:

This policy was originally proposed by community network operators to
provide them with the ability to receive a direct assignment of IPv6
address resources from ARIN. The operators of such networks have
expressed their need to have a stable and globally unique address
assignment with which to number their network infrastructure. Many such
networks are not able to meet the current criteria for a PI IPv6
assignment from ARIN. in an environment where connections to outside
networks may come and go, a stable internal address structure would be
very valuable. Additionally, the ability to exchange routes with others,
whether locally or tunneled, and thereby have native IPv6 connectivity,
would be quite beneficial. These operators were also hopeful that, once
this new class of address assignments was created, they could pursue
lower annual fees for community networks through the ARIN Consultation
and Suggestion Process (ACSP).

There could also be a number of potential benefits to allowing community
network participants to begin using IPv6 addressing. Some of these
networks have many technically capable and adventurous members who would
be motivated to begin developing and/or experimenting with the software
extensions which will be needed to support IPv6 prefix selection among
multiple IPv6 prefixes when establishing remote connections. Also,
participants in networks receiving such assignments will have the
necessary global-ID to experiment with the various proposals currently
being developed for separating network locater from network ID.

Also, during the more than one year timeframe that this policy has been
under consideration, other people have suggested other scenarios where
community networks would provide a valuable resource. One such proposal
was discussed at one of the Caribbean Sector meetings where some
participants pointed out the efforts were being made in remote or
sparsely populated areas to establish community networks which would
serve as connections back to educational resources for distant learning
capabilities. There are also many still wild areas of North America
where such community networks could provide improved connectivity over
telephone modems.

Timetable for implementation: Immediate.



From info at arin.net  Thu Aug 27 14:08:17 2009
From: info at arin.net (Member Services)
Date: Thu, 27 Aug 2009 14:08:17 -0400
Subject: [arin-ppml] Policy Proposal 97: Waiting List for Unmet IPv4
	Requests - Deferred
In-Reply-To: <4A95747E.1090204@arin.net>
References: <4A95747E.1090204@arin.net>
Message-ID: <4A96CB91.4080201@arin.net>

Policy Proposal 97
Waiting List for Unmet IPv4 Requests

Member Services wrote:
> V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting
> List for Unmet IPv4 Requests? until after the October Public Policy 
> Meeting.

The AC deferred Policy Proposal 97 based in part on feedback the AC
received from the ARIN staff and legal assessment. The AC asked that
staff post the assessment (below) to PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Staff Assessment

Proposal: Waiting List for Unmet IPv4 Requests

Proposal Version (Date): 28 July 2009

Date of Assessment: 14 Aug 2009

1. Proposal Summary (Staff Understanding)

Staff understands that this proposal would alter ARIN's current address
issuing procedures and instead require the issuing of a single,
contiguous address prefix for each approved IPv4 request. It would
create a waiting list for requesters whose IPv4 address needs cannot be
fulfilled by ARIN at the time of the request approval and includes
policy text to prevent requesters from gaming the policy's intent by
forbidding requesters from making multiple requests of a small size.

2. Comments

A. ARIN Staff Comments

    * 4.1.6 - As written, this would significantly change ARIN?s current
      system of inventory management. Currently, allocations are issued
      to ISPs, and where relevant, space is reserved to account for the
      ISP's one-year need. This maximizes aggregation possibilities in
      keeping with ARIN's primary mission of promoting both address
      conservation and route aggregation. The text, as written, would
      force staff to stop this practice, and likely cause more
      de-aggregation (not less) in the immediate future.

In addition, the proposal would preclude utilization (where suitable) of
multiple smaller address blocks to meet a request, even if the requester
knows that such addresses will not be routed to the Internet. The hard
requirement for satisfying requests via a single, contiguous address
prefix can therefore result in a less efficient utilization of IPv4
address space than otherwise possible.

    * 4.1.8 ? The term "repeated requests" will need to be defined and
      business procedures developed accordingly. The expected behavior
      upon request denial would be for an ISP to submit a revised
      request for smaller block, and this would naturally result in
      having to apply again at a future date for the remainder of the
      space. It is not clear under the present draft if this would be
      considered ?circumvention of 4.1.6? or not.

B. ARIN General Counsel

At the current time counsel cannot complete evaluation of this policy.

While avoiding de-aggregation can be an important value to the
community, from a legal standpoint it remains unclear whether this
policy inappropriately elevates that single virtue, i.e., preserving the
efficiency of routing while failing to address other simultaneous
aspects of run-out. This policy may create significant and serious
implementation problems that could lead to ?gaming? activity and a
multiplicity of requests designed to circumvent this policy at a time
when litigation may result from any real or perceived unfairness in
management of scarce IPv4 resources.

An alternative way of restating this concern is to focus on the
following statement at the end of the policy: ?This policy does not
attempt to ration addresses, define maximum allocations, or otherwise
manage how much address space any given organization may request. As
such, it is completely independent of any "Predictable IPv4 Run Out"
proposals.?

Counsel wishes to understand whether it is operationally and legally
necessary to integrate multiple policy concerns and community needs
simultaneously in an integrated proposal, i.e. it may not be possible to
create equitable policy for a waiting list which includes a single-block
assignment requirement without also considering these other policy
concerns.

3. Resource Impact

This policy would have moderate resource impact. It is estimated that
implementation would occur within 6 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:

    * Software developed to monitor allocations, and modifications to
      the management web application
    * Changes to current business processes
    * Updated guidelines
    * Staff training

4. Proposal Text

Waiting list for unmet IPv4 requests

Version: 28 July 2009

Replace 4.1.6 with:

4.1.6. Aggregation

In order to preserve aggregation, ARIN issues blocks of addresses on
appropriate "CIDR-supported" bit boundaries. ARIN will make all
allocations and assignments as a single continuous range of addresses.

Add new section 4.1.8:

4.1.8 Unmet requests

In the event that ARIN does not have a contiguous block of addresses of
sufficient size to fulfill a qualified request, ARIN will provide the
requesting organization with the option to either modify their request
and request a smaller size block, or be placed on a waiting list of
pre-qualified recipients. Repeated requests, in a manner that would
circumvent 4.1.6, are not allowed. Qualified requesters whose request
cannot be immediately met will also be advised of the availability of
the transfer mechanism in section 8.3 as an alternative mechanism to
obtain IPv4 addresses.

4.1.8.1 Waiting list

The position of each qualified request on the waiting list will be
determined by the date it was approved. Each organization may have one
approved request on the waiting list at a time.

4.1.8.2 Fulfilling unmet needs

As address blocks become available for allocation, ARIN will fulfill
requests on a first-approved basis, subject to the size of each
available address block and a re-validation of the original request.
Requests will not be partially filled. Any requests met through a
transfer will be considered fulfilled and removed from the waiting list.

Rationale:

ARIN will soon be unable to meet all approved requests for IPv4 address
space. In the absence of a policy like this, it is unclear what ARIN
should do with subsequent requests.

This policy would allocate reclaimed address blocks (and the last of the
ARIN free pool) on a first-come-first-served basis, while preserving
aggregation to the degree possible. As the free pool shrinks, requests
larger than the largest block left would be placed on a waiting list,
while smaller requests would use up the rest of it, until all requests
have to go on the waiting list. As additional reclaimed addresses become
available, the requests that have been waiting the longest would be met
first. If a requester gets the addresses they need via transfer, then
they would be removed from the waiting list and would need to wait and
submit a new request for additional address space, either directly or
via transfer.

This policy does not attempt to ration addresses, define maximum
allocations, or otherwise manage how much address space any given
organization may request. As such, it is completely independent of any
"Predictable IPv4 Run Out" proposals.



Member Services wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 20 August 2009 and made decisions about
> several policy proposals and draft policies.
>
> I. The AC selected the following proposals and changed them into draft
> policies for adoption discussion online and at the upcoming Public
> Policy Meeting. The draft policies will be posted shortly to the PPML.
>
> Policy Proposal 89 (Global): Internet Assigned Numbers Authority (IANA)
> Policy for Allocation of ASN Blocks (ASNs) to Regional Internet 
> Registries
>
> Policy Proposal 90: Open Access To IPv6
>
> Policy Proposal 93: Equitable IPv4 Run Out
>
> II. The AC selected the following draft policy for adoption discussion
> online and at the upcoming Public Policy Meeting. It will be posted
> shortly to the PPML.
>
> Draft Policy 2009-3: (Global): Allocation of IPv4 Blocks to Regional
> Internet Registries
>
> III. The AC used portions of ?Policy Proposal 94: Predictable IPv4 Run
> Out by Allocation Window? to help with the creation of the ?Equitable
> IPv4 Run Out.? The AC considers proposal 94 to be closed.
>
> IV. The AC abandoned ?Policy Proposal 96: Transfer Listing Service.? The
> AC suggested that the President direct this matter through the ARIN
> Consultation and Suggestion Process.
>
> V. The AC decided to defer discussion of ?Policy Proposal 97: Waiting
> List for Unmet IPv4 Requests? until after the October Public Policy 
> Meeting.
>
> VI. The AC accepted the following proposals on to the AC's docket for
> development and evaluation. There is not an adequate amount of time to
> create and publish draft policies in time for the October Public Policy
> Meeting.
>
> Policy Proposal 98: Last Minute Assistance for Small ISPs
>
> Policy Proposal 99: /24 End User Minimum Allocation Unit
>
> VII. The AC abandoned ?Policy Proposal 100: Multihomed Microallocations.?
>
> VIII. The AC sent a revised ?2008-3: Community Networks IPv6 Assignment?
> to an extended last call. The text will be posted shortly to the PPML.
>
> The PDP states, ?Any member of the community, including a proposal
> originator, may initiate a Discussion Petition if they are dissatisfied
> with the action taken by the Advisory Council regarding any specific
> policy proposal.? Several of the AC?s decisions above resulted in
> proposals not being selected for adoption discussion. The purpose of a
> petition would be to change a proposal into a draft policy for
> discussion on the Public Policy Mailing List and at the October meeting.
> The deadline to begin a petition is 2 September 2009.
>
> The following can be petitioned (status in parens):
>
> Policy Proposal 94: Predictable IPv4 Run Out by Allocation Window
> (merged and closed)
>
> Policy Proposal 96: Transfer Listing Service (abandoned)
>
> Policy Proposal 97: Waiting List for Unmet IPv4 Requests (delayed)
>
> Policy Proposal 98: Last Minute Assistance for Small ISPs (added to AC?s
> docket)
>
> Policy Proposal 99: /24 End User Minimum Allocation Unit (added to AC?s
> docket)
>
> Policy Proposal 100: Multihomed Microallocations (abandoned)
>
> For more information on starting and participating in petitions, see PDP
> Petitions at: https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Policy Proposal texts under discussion 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,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> _______________________________________________
> 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  Thu Aug 27 14:08:48 2009
From: info at arin.net (Member Services)
Date: Thu, 27 Aug 2009 14:08:48 -0400
Subject: [arin-ppml]
 =?windows-1252?q?Draft_Policy_2008-3=3A_Community_Net?=
 =?windows-1252?q?works_IPv6_Assignment_=96_Last_Call?=
In-Reply-To: <4A957584.4040608@arin.net>
References: <4A957584.4040608@arin.net>
Message-ID: <4A96CBB0.3040005@arin.net>

Draft Policy 2008-3
Community Networks IPv6 Assignment

2008-3 (version dated 19 August 2009) is in last call. Prior to moving
it to last call the AC asked for a staff assessment. Staff provided the
assessment to the AC. The AC reviewed the assessment and made several
revisions to the text. The AC moved the revised text to last call.

The AC asked staff to post the assessment (below) to PPML to help with
discussion.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####

Staff Assessment

2008-3
Community Networks IPv6 Assignment

Proposal Version (Date): 31 July 2009

Date of Assessment:   08-18-09

1. Proposal Summary (Staff Understanding)

Staff understand this policy defines a community network as providing
free or low-cost connectivity, operating as or under the fiscal support
of a non-profit or university, and run entirely by volunteers. This
policy would allow community network operators to request an IPv6
assignment of /48 or larger by demonstrating that they would service at
least 100 users immediately and 200 users within one year. In addition,
this policy directs ARIN staff to use discretion when reviewing requests
from rural regions, the Caribbean and North Atlantic Sector.

2. Comments

A.  ARIN Staff Comments

  The policy can be implemented as written.

  NRPM section 6.5.8.1.b was revised on 5 August 2008 by an unrelated
proposal (2007-21). The proposed text for 6.5.8.1.b needs to be updated
to reflect the current version of the NRPM (otherwise it would revoke
2007-21).

  ARIN staff would prefer criteria over discretion. Instead of
discretion, the policy could give clear criteria for requests from rural
regions, the Caribbean and North Atlantic Sector. For example, 50 users
now and 100 in a year (or 25/50, 10/20, etc).

  The policy would add the term ?rural? to the NRPM. We suggest putting
?(population less than 2,500)? after the word ?rural regions?. The US
Census Bureau definition:  ?All persons living in [urban areas] and in
places (cities, towns, villages, etc.) with a population of 2,500
or more outside of [urban areas] are considered the urban population.
All others are considered rural.?

  B. ARIN General Counsel

  Counsel sees no material legal or litigation issues related to this
policy.

3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:
  Updated guidelines
  Staff training

4. Proposal Text

2008-3 Community Networks IPv6 Assignment

Date: 31 July 2009

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network
A community network is any network organized and operated by a volunteer
group operating as
or under the fiscal support of a non-profit organization or university
for the purpose of providing
free or low-cost connectivity to the residents of their local service
area. To be treated as a
community network under ARIN policy, the applicant must certify to ARIN
that the community
network staff is 100% volunteers.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in
effect or be a qualifying Community Network as defined in Section 2.8,
with assignment criteria
defined in section 6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Assignments

6.5.9.1 Qualification Criteria
To qualify for a direct assignment, a community network must demonstrate
it will immediately
provide sustained service to at least 100 simultaneous users and must
demonstrate a plan to
provide sustained service to at least 200 simultaneous users within one
year. For community
networks located in rural regions or in the Caribbean and North Atlantic
Islands Sector, the
numbers in these qualification criteria may be relaxed at ARIN's
discretion.

6.5.9.2. Initial assignment size
The minimum size of the assignment is /48. Organizations requesting a
larger assignment must
provide documentation of the characteristics of the Community Network's
size and architecture
that require the use of additional subnets. An HD-Ratio of .94 with
respect to subnet utilization
within the network must be met for all assignments larger than a /48.
These assignments shall be
made from a distinctly identified prefix and shall be made with a
reservation for growth of at
least a /44. This reservation may be assigned to other organizations
later, at ARIN's discretion.

6.5.9.3. Subsequent assignment size Additional assignments may be made
when the need for additional subnets is justified.
Justification will be determined based on a detailed plan of the
network's architecture and the .94
HD-Ratio metric. When possible, assignments will be made from an
aggregatable adjacent
address block.

Rationale:

this policy was originally proposed by community network operators to
provide them with the
ability to receive a direct assignment of IPv6 address resources from
ARIN. the operators of such
networks have expressed their need to have a stable and globally unique
address assignment with
which to number their network infrastructure. many such networks are not
able to meet the
current criteria for a PI IPv6 assignment from ARIN. in an environment
where connections to
outside networks may come and go, a stable internal address structure
would be very valuable.
additionally, the ability to exchange routes with others, whether
locally or tunneled, and thereby
have native IPv6 connectivity, would be quite beneficial. these
operators were also hopeful that,
once this new class of address assignments was created, they could
pursue lower annual fees for
community networks through the ARIN Consultation and Suggestion Process
(ACSP).

there could also be a number of potential benefits to allowing community
network participants to
begin using IPv6 addressing. some of these networks have many
technically capable and
adventurous members who would be motivated to begin developing and/or
experimenting with
the software extensions which will be needed to support IPv6 prefix
selection among multiple
IPv6 prefixes when establishing remote connections. also, participants
in networks receiving
such assignments will have the necessary global-ID to experiment with
the various proposals
currently being developed for separating network locater from network ID.

also, during the more than one year timeframe that this policy has been
under consideration,
other people have suggested other scenarios where community networks
would provide a
valuable resource. one such proposal was discussed at one of the
Caribbean Sector meetings
where some participants pointed out the efforts were being made in
remote or sparsely populated
areas to establish community networks which would serve as connections
back to educational
resources for distant learning capabilities. there are also many still
wild areas of North America
where such community networks could provide improved connectivity over
telephone modems.

Timetable for implementation: Immediate.



Member Services wrote:
> Draft Policy 2008-3
> Community Networks IPv6 Assignment
>
> On 20 August 2009 the ARIN Advisory Council (AC) decided to send an
> updated version of Draft Policy 2008-3 to a 21-day last call.
>
> ?The ARIN Advisory Council, based on comments from stakeholders
> expressed at the last three ARIN Public Policy Meetings (ARIN XXI, ARIN
> XXII and ARIN XXIII) and on the ARIN Public Policy Mailing List, having
> reviewed the comments collected, as well as the latest ARIN staff and
> legal reviews; and, updated the policy accordingly, and noting that the
> Policy Development Process has been followed, finds Advisory Council and
> Community support for Draft Policy 2008-3: Community Networks IPv6
> Assignment, and moves to it to a 21-day extended Last Call.?
>
> Feedback is encouraged during this last call period. All comments must
> be provided to the Public Policy Mailing List. This last call will
> expire at 2:00 PM EDT, 17 September 2009.
>
> The policy proposal text is provided below and is also available at:
> https://www.arin.net/policy/proposals/2008_3.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2008-3
> Community Networks IPv6 Assignment
>
> Date: 19 August 2009
>
> Policy statement:
>
> [Add Section 2.8 to the NRPM.]
>
> 2.8 Community Network
>
> A community network is any network organized and operated by a volunteer
> group operating as or under the fiscal support of a non-profit
> organization or university for the purpose of providing free or low-cost
> connectivity to the residents of their local service area. To be treated
> as a community network under ARIN policy, the applicant must certify to
> ARIN that the community network staff is 100% volunteers.
>
> [Modify 6.5.8.1b as follows.]
>
> b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
> policy currently in effect, or demonstrate efficient utilization of all
> direct IPv4 assignments and allocations, each of which must be covered
> by any current ARIN RSA, or be a qualifying Community Network as defined
> in Section 2.8, with assignment criteria defined in section 6.5.9.
>
> [Add Section 6.5.9 to the NRPM.]
>
> 6.5.9 Community Network Assignments
>
> 6.5.9.1 Qualification Criteria
>
> To qualify for a direct assignment, a community network must demonstrate
> it will immediately provide sustained service to at least 100
> simultaneous users and must demonstrate a plan to provide sustained
> service to at least 200 simultaneous users within one year. For
> community networks located in rural regions (population less than 2,500)
> or in the Caribbean and North Atlantic Islands Sector, the numbers in
> these qualification criteria may be relaxed at ARIN's discretion.
>
> 6.5.9.2. Initial assignment size
>
> The minimum size of the assignment is /48. Organizations requesting a
> larger assignment must provide documentation of the characteristics of
> the Community Network's size and architecture that require the use of
> additional subnets. An HD-Ratio of .94 with respect to subnet
> utilization within the network must be met for all assignments larger
> than a /48. These assignments shall be made from a distinctly identified
> prefix and shall be made with a reservation for growth of at least a
> /44. This reservation may be assigned to other organizations later, at
> ARIN's discretion.
>
> 6.5.9.3. Subsequent assignment size
>
> Additional assignments may be made when the need for additional subnets
> is justified. Justification will be determined based on a detailed plan
> of the network's architecture and the .94 HD-Ratio metric. When
> possible, assignments will be made from an aggregatable adjacent address
> block.
>
> Rationale:
>
> This policy was originally proposed by community network operators to
> provide them with the ability to receive a direct assignment of IPv6
> address resources from ARIN. The operators of such networks have
> expressed their need to have a stable and globally unique address
> assignment with which to number their network infrastructure. Many such
> networks are not able to meet the current criteria for a PI IPv6
> assignment from ARIN. in an environment where connections to outside
> networks may come and go, a stable internal address structure would be
> very valuable. Additionally, the ability to exchange routes with others,
> whether locally or tunneled, and thereby have native IPv6 connectivity,
> would be quite beneficial. These operators were also hopeful that, once
> this new class of address assignments was created, they could pursue
> lower annual fees for community networks through the ARIN Consultation
> and Suggestion Process (ACSP).
>
> There could also be a number of potential benefits to allowing community
> network participants to begin using IPv6 addressing. Some of these
> networks have many technically capable and adventurous members who would
> be motivated to begin developing and/or experimenting with the software
> extensions which will be needed to support IPv6 prefix selection among
> multiple IPv6 prefixes when establishing remote connections. Also,
> participants in networks receiving such assignments will have the
> necessary global-ID to experiment with the various proposals currently
> being developed for separating network locater from network ID.
>
> Also, during the more than one year timeframe that this policy has been
> under consideration, other people have suggested other scenarios where
> community networks would provide a valuable resource. One such proposal
> was discussed at one of the Caribbean Sector meetings where some
> participants pointed out the efforts were being made in remote or
> sparsely populated areas to establish community networks which would
> serve as connections back to educational resources for distant learning
> capabilities. There are also many still wild areas of North America
> where such community networks could provide improved connectivity over
> telephone modems.
>
> Timetable for implementation: Immediate.
>
> _______________________________________________
> 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 martin.hannigan at batelnet.bs  Fri Aug 28 08:04:05 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 28 Aug 2009 08:04:05 -0400
Subject: [arin-ppml]
	=?windows-1252?q?Draft_Policy_2008-3=3A_Community_Net?=
	=?windows-1252?q?works_IPv6_Assignment_=96_Last_Call?=
In-Reply-To: <4A96CBB0.3040005@arin.net>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
Message-ID: <4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>

On Thu, Aug 27, 2009 at 2:08 PM, Member Services<info at arin.net> wrote:

[ clip ]

> 1. Proposal Summary (Staff Understanding)
>
> Staff understand this policy defines a community network as providing
> free or low-cost connectivity, operating as or under the fiscal support
> of a non-profit or university, and run entirely by volunteers.
>

At least the staff got the intent. Kudos.

[  clip ]

> ?The policy would add the term ?rural? to the NRPM. We suggest putting
> ?(population less than 2,500)? after the word ?rural regions?. The US
> Census Bureau definition: ??All persons living in [urban areas] and in
> places (cities, towns, villages, etc.) with a population of 2,500
> or more outside of [urban areas] are considered the urban population.
> All others are considered rural.?

Rural isn't the word you are looking for. Rural implies something
different than destitute remoteness. I think that the intent of this
policy was originally an economic one and I think that the staff, in
reading this, got it.


[ clip ]

> 2.8 Community Network
> A community network is any network organized and operated by a volunteer
> group operating as or under the fiscal support of a non-profit organization or university
> for the purpose of providing free or low-cost connectivity to the residents of their local service
> area.


The problematic language for me is "as or under". How do you operate
"under" the fiscal support of a non profit organization? Aren't
Universities non-profits? Diving clubs? Cub Scouts? What constitutes
operating "under" the fiscal support of a non-profit or university? It
looks like this proposal simply grabbed on to hot-button issues to
justify it's creation along with a few loopholes. I'm fairly certain
that while the abuse of this one may be limited, it will be abused.

Best,

Martin


From farmer at umn.edu  Fri Aug 28 09:48:05 2009
From: farmer at umn.edu (David Farmer)
Date: Fri, 28 Aug 2009 08:48:05 -0500
Subject: [arin-ppml]
	=?utf-8?q?Draft_Policy_2008-3=3A_Community_Networks_I?=
	=?utf-8?q?Pv6_Assignment_=E2=80=93_Last_Call?=
In-Reply-To: <4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
References: <4A957584.4040608@arin.net>, <4A96CBB0.3040005@arin.net>,
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
Message-ID: <4A9799C5.24405.832697B@farmer.umn.edu>

On 28 Aug 2009 Martin Hannigan wrote:

> On Thu, Aug 27, 2009 at 2:08 PM, Member Services<info at arin.net> wrote:
> 
> [ clip ]

[clipped more]

> > 2.8 Community Network
> > A community network is any network organized and operated by a volunteer
> > group operating as or under the fiscal support of a non-profit organization or university
> > for the purpose of providing free or low-cost connectivity to the residents of their local service
> > area.
> 
> 
> The problematic language for me is "as or under". How do you operate
> "under" the fiscal support of a non profit organization? Aren't
> Universities non-profits? Diving clubs? Cub Scouts? What constitutes
> operating "under" the fiscal support of a non-profit or university? It
> looks like this proposal simply grabbed on to hot-button issues to
> justify it's creation along with a few loopholes. I'm fairly certain
> that while the abuse of this one may be limited, it will be abused.

Using one of the examples you provided;

A Diving Club associated with a university frequently is not a separate 
organization.  It is frequently chartered as a student organization within the 
university and from a legal stand point is part of the university and operates 
under the fiscal management and support of the university.  The university is 
legally responsible for the debts and actions of such a Diving Club.  Other 
Diving Clubs may be sponsored by the YMCA or another non-profit parent 
organization, and then other Diving Clubs may be separately incorporated 
independent non-profit organizations.  

Substitute "Community Network" for "Diving Club" and you have the intent of 
the phrase "as or under the fiscal support of a non-profit organization or 
university".  Would "as or under the fiscal management and support of a 
non-profit organization or university" be better?  Do you have a better 
suggestion on how to phrase this?

Given the historical significance that universities have had in the creation of 
the Internet, and the fact that many universities are not necessarily regular 
non-profit organizations, it seems proper to explicitly include them in this 
policy.  Most everyone in the Internet industry today had their first exposure 
to the Internet at or through a university.  It is only those who have entered 
the Internet industry in the past 5 years or less that are likely to have had 
their first Internet experience not associated with a university.



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



From rudi.daniel at gmail.com  Sat Aug 29 20:32:01 2009
From: rudi.daniel at gmail.com (RudOlph Daniel)
Date: Sat, 29 Aug 2009 20:32:01 -0400
Subject: [arin-ppml] Draft Policy 2008-3
Message-ID: <8aeeaff60908291732sda89aa9q186e68353eaa4ac8@mail.gmail.com>

Dear List
I would also prefer to see a clear criteria instead of the word
"discretion"...as suggested by ARIN staff. The Caribbean region I would
suggest may well fall into the 25 now and 50 in a year. Also bearing in mind
that the network is entirely staffed by volunteers and could form the basis
of a development model for native v6 too.

In addition, using the US Census bureau's definition of rural and urban may
be a little high for the Caribbean region if set to 2500. Would 1000 not be
more appropriate for the north Atlantic sector and the Caribbean? I am
currently checking to see if we have a local standard.
Rudi Daniel




>
>  ARIN staff would prefer criteria over discretion. Instead of
> discretion, the policy could give clear criteria for requests from rural
> regions, the Caribbean and North Atlantic Sector. For example, 50 users
> now and 100 in a year (or 25/50, 10/20, etc).
>
>  The policy would add the term ?rural? to the NRPM. We suggest putting
> ?(population less than 2,500)? after the word ?rural regions?. The US
> Census Bureau definition:  ?All persons living in [urban areas] and in
> places (cities, towns, villages, etc.) with a population of 2,500
> or more outside of [urban areas] are considered the urban population.
> All others are considered rural.?
>
>  B. ARIN General Counsel
>
>  Counsel sees no material legal or litigation issues related to this
> policy.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090829/c70d07dd/attachment.htm>

From lea.roberts at stanford.edu  Sun Aug 30 01:36:56 2009
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Sat, 29 Aug 2009 22:36:56 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2008-3
In-Reply-To: <8aeeaff60908291732sda89aa9q186e68353eaa4ac8@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.0908292134100.17540-100000@networking.stanford.edu>

dear Rudi -

thank you for your comment(s)

On Sat, 29 Aug 2009, RudOlph Daniel wrote:

> Dear List
> I would also prefer to see a clear criteria instead of the word
> "discretion"...as suggested by ARIN staff. The Caribbean region I would
> suggest may well fall into the 25 now and 50 in a year. Also bearing in mind
> that the network is entirely staffed by volunteers and could form the basis
> of a development model for native v6 too.

unfortunately this staff comment came too late in the process for moving
2008-3 forward to last call.  my personal feeling is that specific number
criteria for lower population areas may not really belong in policy, i.e.
in the NRPM.  rather I believe the purpose of this policy language is to
allow ARIN to further define these criteria in operational procedures,
which should certainly be publicly stated and available to the ASCP
suggestion process.

if you still feel there should be more specific criteria in the NRPM, it
would certainly be possible for you (or anyone) to submit another policy
proposal to add to the definition if 2008-3 does make it into the NRPM.

> In addition, using the US Census bureau's definition of rural and urban may
> be a little high for the Caribbean region if set to 2500. Would 1000 not be
> more appropriate for the north Atlantic sector and the Caribbean? I am
> currently checking to see if we have a local standard.

I believe the intent of the policy language which was added in response to
the staff comment is only to apply the "less than 2500" number to define
rural regions outside of the Carribean and North Altantic sector.  the
basic intent of this remains simply to make sure that the "100 to start,
200 within one year" numbers are not necessarily applied to applicants
from areas where such numbers would be unrealistic.

Lea Roberts
ARIN AC, shepherd for 2008-3

> >
> >  ARIN staff would prefer criteria over discretion. Instead of
> > discretion, the policy could give clear criteria for requests from rural
> > regions, the Caribbean and North Atlantic Sector. For example, 50 users
> > now and 100 in a year (or 25/50, 10/20, etc).
> >
> >  The policy would add the term ?rural? to the NRPM. We suggest putting
> > ?(population less than 2,500)? after the word ?rural regions?. The US
> > Census Bureau definition:  ?All persons living in [urban areas] and in
> > places (cities, towns, villages, etc.) with a population of 2,500
> > or more outside of [urban areas] are considered the urban population.
> > All others are considered rural.?
> >
> >  B. ARIN General Counsel
> >
?> >  Counsel sees no material legal or litigation issues related to this
> > policy.
> >




From martin.hannigan at batelnet.bs  Sun Aug 30 12:46:20 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Sun, 30 Aug 2009 12:46:20 -0400
Subject: [arin-ppml]
	=?windows-1252?q?Draft_Policy_2008-3=3A_Community_Net?=
	=?windows-1252?q?works_IPv6_Assignment_=96_Last_Call?=
In-Reply-To: <4A9799C5.24405.832697B@farmer.umn.edu>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
	<4A9799C5.24405.832697B@farmer.umn.edu>
Message-ID: <4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>

On Fri, Aug 28, 2009 at 9:48 AM, David Farmer<farmer at umn.edu> wrote:
> On 28 Aug 2009 Martin Hannigan wrote:
>
>> On Thu, Aug 27, 2009 at 2:08 PM, Member Services<info at arin.net> wrote:
>>
>> [ clip ]
>
> [clipped more]
>
>> > 2.8 Community Network
>> > A community network is any network organized and operated by a volunteer
>> > group operating as or under the fiscal support of a non-profit organization or university
>> > for the purpose of providing free or low-cost connectivity to the residents of their local service
>> > area.
>>
>>
>> The problematic language for me is "as or under". How do you operate
>> "under" the fiscal support of a non profit organization? Aren't
>> Universities non-profits? Diving clubs? Cub Scouts? What constitutes
>> operating "under" the fiscal support of a non-profit or university? It
>> looks like this proposal simply grabbed on to hot-button issues to
>> justify it's creation along with a few loopholes. I'm fairly certain
>> that while the abuse of this one may be limited, it will be abused.
>
> Using one of the examples you provided;
>


[ snip ]


>
> Substitute "Community Network" for "Diving Club" and you have the intent of
> the phrase "as or under the fiscal support of a non-profit organization or
> university". ?Would "as or under the fiscal management and support of a
> non-profit organization or university" be better? ?Do you have a better
> suggestion on how to phrase this?

One way that this proposal could have been improved would have been to
specify that accredited educational institutions and UN recognized
NGO's may allocate v6 address space to groups that they deem deserving
as defined by their internal processes after they themselves qualify
under the existing criteria. That may have addressed the staff
discretion comment, it certainly addresses the weak use cases and it
eliminates the [possibly hundreds of] thousands of others who this
proposal was not intended to benefit.

I will leave this in your capable and adventurous hands.

Best,

-M<


From rudi.daniel at gmail.com  Sun Aug 30 13:06:09 2009
From: rudi.daniel at gmail.com (RudOlph Daniel)
Date: Sun, 30 Aug 2009 13:06:09 -0400
Subject: [arin-ppml] 2008-3
Message-ID: <8aeeaff60908301006y659b839cxd38b46c0b9796765@mail.gmail.com>

Ref: Lee RobertsYou are actually correct, must be too long a day...we would
*not* want to exclude larger rural populations.. So my 1000 instead of 2500
is inappropriate..Thank you for the correction.

Rudi Daniel


> Dear List
> I would also prefer to see a clear criteria instead of the word
> "discretion"...as suggested by ARIN staff. The Caribbean region I would
> suggest may well fall into the 25 now and 50 in a year. Also bearing in
> mind
> that the network is entirely staffed by volunteers and could form the basis
> of a development model for native v6 too.
>
> In addition, using the US Census bureau's definition of rural and urban may
> be a little high for the Caribbean region if set to 2500. Would 1000 not be
> more appropriate for the north Atlantic sector and the Caribbean? I am
> currently checking to see if we have a local standard.
> Rudi Daniel
>
>
>
>
> >
> >  ARIN staff would prefer criteria over discretion. Instead of
> > discretion, the policy could give clear criteria for requests from rural
> > regions, the Caribbean and North Atlantic Sector. For example, 50 users
> > now and 100 in a year (or 25/50, 10/20, etc).
> >
> >  The policy would add the term ?rural? to the NRPM. We suggest putting
> > ?(population less than 2,500)? after the word ?rural regions?. The US
> > Census Bureau definition:  ?All persons living in [urban areas] and in
> > places (cities, towns, villages, etc.) with a population of 2,500
> > or more outside of [urban areas] are considered the urban population.
> > All others are considered rural.?
> >
> >  B. ARIN General Counsel
> >
> >  Counsel sees no material legal or litigation issues related to this
> > policy.
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20090829/c70d07dd/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 29 Aug 2009 22:36:56 -0700 (PDT)
> From: Lea Roberts <lea.roberts at stanford.edu>
> To: RudOlph Daniel <rudi.daniel at gmail.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-3
> Message-ID:
>        <Pine.LNX.4.44.0908292134100.17540-100000 at networking.stanford.edu>
> Content-Type: TEXT/PLAIN; charset=ISO-8859-1
>
> dear Rudi -
>
> thank you for your comment(s)
>
> On Sat, 29 Aug 2009, RudOlph Daniel wrote:
>
> > Dear List
> > I would also prefer to see a clear criteria instead of the word
> > "discretion"...as suggested by ARIN staff. The Caribbean region I would
> > suggest may well fall into the 25 now and 50 in a year. Also bearing in
> mind
> > that the network is entirely staffed by volunteers and could form the
> basis
> > of a development model for native v6 too.
>
> unfortunately this staff comment came too late in the process for moving
> 2008-3 forward to last call.  my personal feeling is that specific number
> criteria for lower population areas may not really belong in policy, i.e.
> in the NRPM.  rather I believe the purpose of this policy language is to
> allow ARIN to further define these criteria in operational procedures,
> which should certainly be publicly stated and available to the ASCP
> suggestion process.
>
> if you still feel there should be more specific criteria in the NRPM, it
> would certainly be possible for you (or anyone) to submit another policy
> proposal to add to the definition if 2008-3 does make it into the NRPM.
>
> > In addition, using the US Census bureau's definition of rural and urban
> may
> > be a little high for the Caribbean region if set to 2500. Would 1000 not
> be
> > more appropriate for the north Atlantic sector and the Caribbean? I am
> > currently checking to see if we have a local standard.
>
> I believe the intent of the policy language which was added in response to
> the staff comment is only to apply the "less than 2500" number to define
> rural regions outside of the Carribean and North Altantic sector.  the
> basic intent of this remains simply to make sure that the "100 to start,
> 200 within one year" numbers are not necessarily applied to applicants
> from areas where such numbers would be unrealistic.
>
> Lea Roberts
> ARIN AC, shepherd for 2008-3
>
> > >
> > >  ARIN staff would prefer criteria over discretion. Instead of
> > > discretion, the policy could give clear criteria for requests from
> rural
> > > regions, the Caribbean and North Atlantic Sector. For example, 50 users
> > > now and 100 in a year (or 25/50, 10/20, etc).
> > >
> > >  The policy would add the term ?rural? to the NRPM. We suggest putting
> > > ?(population less than 2,500)? after the word ?rural regions?. The US
> > > Census Bureau definition:  ?All persons living in [urban areas] and in
> > > places (cities, towns, villages, etc.) with a population of 2,500
> > > or more outside of [urban areas] are considered the urban population.
> > > All others are considered rural.?
> > >
> > >  B. ARIN General Counsel
> > >
> ?> >  Counsel sees no material legal or litigation issues related to this
> > > policy.
> > >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 50, Issue 32
> *****************************************
>



-- 
Rudi Daniel
Independent Consultants
e Business Implementation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090830/1915f0bd/attachment.htm>

From mueller at syr.edu  Sun Aug 30 16:24:22 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 30 Aug 2009 16:24:22 -0400
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
 Assignment - Last Call
In-Reply-To: <4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
	<4A9799C5.24405.832697B@farmer.umn.edu>
	<4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>

Please do not restrict this to "UN recognized NGOs." Only a handful of the world's NGO have the time or inclination to be recognized by the UN; many engaged in political speech would be knocked down by hostile govts if they sought recognition. --MM

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Martin Hannigan
> Sent: Sunday, August 30, 2009 12:46 PM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
> Assignment - Last Call
> 
> On Fri, Aug 28, 2009 at 9:48 AM, David Farmer<farmer at umn.edu> wrote:
> > On 28 Aug 2009 Martin Hannigan wrote:
> >
> >> On Thu, Aug 27, 2009 at 2:08 PM, Member Services<info at arin.net> wrote:
> >>
> >> [ clip ]
> >
> > [clipped more]
> >
> >> > 2.8 Community Network
> >> > A community network is any network organized and operated by a
> volunteer
> >> > group operating as or under the fiscal support of a non-profit
> organization or university
> >> > for the purpose of providing free or low-cost connectivity to the
> residents of their local service
> >> > area.
> >>
> >>
> >> The problematic language for me is "as or under". How do you operate
> >> "under" the fiscal support of a non profit organization? Aren't
> >> Universities non-profits? Diving clubs? Cub Scouts? What constitutes
> >> operating "under" the fiscal support of a non-profit or university? It
> >> looks like this proposal simply grabbed on to hot-button issues to
> >> justify it's creation along with a few loopholes. I'm fairly certain
> >> that while the abuse of this one may be limited, it will be abused.
> >
> > Using one of the examples you provided;
> >
> 
> 
> [ snip ]
> 
> 
> >
> > Substitute "Community Network" for "Diving Club" and you have the intent
> of
> > the phrase "as or under the fiscal support of a non-profit organization
> or
> > university". ?Would "as or under the fiscal management and support of a
> > non-profit organization or university" be better? ?Do you have a better
> > suggestion on how to phrase this?
> 
> One way that this proposal could have been improved would have been to
> specify that accredited educational institutions and UN recognized
> NGO's may allocate v6 address space to groups that they deem deserving
> as defined by their internal processes after they themselves qualify
> under the existing criteria. That may have addressed the staff
> discretion comment, it certainly addresses the weak use cases and it
> eliminates the [possibly hundreds of] thousands of others who this
> proposal was not intended to benefit.
> 
> I will leave this in your capable and adventurous hands.
> 
> Best,
> 
> -M<
> _______________________________________________
> 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 joelja at bogus.com  Sun Aug 30 17:53:14 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Sun, 30 Aug 2009 14:53:14 -0700
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
 Assignment - Last Call
In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
References: <4A957584.4040608@arin.net>
	<4A96CBB0.3040005@arin.net>	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>	<4A9799C5.24405.832697B@farmer.umn.edu>	<4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A9AF4CA.80206@bogus.com>

I've found the discussion of organizational suitability very hard to
follow in part because it's been in the abstract.

What, (or is there an) organization having found the current arin
process either financially onerous or not qualifying under existing
rules would avail themselves of 2008-3.

If the beneficiaries of this policy are real rather than abstract it
should be much easier to tailor the policy to meet their needs. If they
don't exist yet, what purpose does the policy serve?

joelja

Milton L Mueller wrote:
> Please do not restrict this to "UN recognized NGOs." Only a handful of the world's NGO have the time or inclination to be recognized by the UN; many engaged in political speech would be knocked down by hostile govts if they sought recognition. --MM
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Martin Hannigan
>> Sent: Sunday, August 30, 2009 12:46 PM
>> To: David Farmer
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
>> Assignment - Last Call
>>
>> On Fri, Aug 28, 2009 at 9:48 AM, David Farmer<farmer at umn.edu> wrote:
>>> On 28 Aug 2009 Martin Hannigan wrote:
>>>
>>>> On Thu, Aug 27, 2009 at 2:08 PM, Member Services<info at arin.net> wrote:
>>>>
>>>> [ clip ]
>>> [clipped more]
>>>
>>>>> 2.8 Community Network
>>>>> A community network is any network organized and operated by a
>> volunteer
>>>>> group operating as or under the fiscal support of a non-profit
>> organization or university
>>>>> for the purpose of providing free or low-cost connectivity to the
>> residents of their local service
>>>>> area.
>>>>
>>>> The problematic language for me is "as or under". How do you operate
>>>> "under" the fiscal support of a non profit organization? Aren't
>>>> Universities non-profits? Diving clubs? Cub Scouts? What constitutes
>>>> operating "under" the fiscal support of a non-profit or university? It
>>>> looks like this proposal simply grabbed on to hot-button issues to
>>>> justify it's creation along with a few loopholes. I'm fairly certain
>>>> that while the abuse of this one may be limited, it will be abused.
>>> Using one of the examples you provided;
>>>
>>
>> [ snip ]
>>
>>
>>> Substitute "Community Network" for "Diving Club" and you have the intent
>> of
>>> the phrase "as or under the fiscal support of a non-profit organization
>> or
>>> university".  Would "as or under the fiscal management and support of a
>>> non-profit organization or university" be better?  Do you have a better
>>> suggestion on how to phrase this?
>> One way that this proposal could have been improved would have been to
>> specify that accredited educational institutions and UN recognized
>> NGO's may allocate v6 address space to groups that they deem deserving
>> as defined by their internal processes after they themselves qualify
>> under the existing criteria. That may have addressed the staff
>> discretion comment, it certainly addresses the weak use cases and it
>> eliminates the [possibly hundreds of] thousands of others who this
>> proposal was not intended to benefit.
>>
>> I will leave this in your capable and adventurous hands.
>>
>> Best,
>>
>> -M<
>> _______________________________________________
>> 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 randy at psg.com  Sun Aug 30 19:51:42 2009
From: randy at psg.com (Randy Bush)
Date: Mon, 31 Aug 2009 08:51:42 +0900
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment - Last Call
In-Reply-To: <4A9AF4CA.80206@bogus.com>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
	<4A9799C5.24405.832697B@farmer.umn.edu>
	<4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
	<4A9AF4CA.80206@bogus.com>
Message-ID: <m2ljl0zwq9.wl%randy@psg.com>

> If the beneficiaries of this policy are real rather than abstract it
> should be much easier to tailor the policy to meet their needs. If they
> don't exist yet, what purpose does the policy serve?

the problem with defining the beneficiary is that there is a gap-less
continuum from the red cross to the aarl to the folk who set up ad hoc
wireless in new orleans during the early part of the hurricane disaster
there.

i suspect many here are trying to draw a circle around seattle wireless
and its ilk.  the big problem is that it is a multi-dimensional space.
there is the form of organization (incorporated, underground, anarchic,
cooperative, ...), the intent of use (provider bypass, research, civil,
political, emergency, poor/rural access, ...), financial structure
(cooperative, no exchange of funds, grant/gift funded, non-profit, ...),
etc.  the list of dimensions goes on.

so i am not optimistic about an effort to bound a definition of the
beneficiaries.  and i suspect staff would not be entirely happy to have
something this loosey goosey dumped on them for decisions (staff, please
disabuse me if i underestimate your omniscience:-).  and, with the
overload failure of the 198.32.0.0/16 exchange point lesson, i.e. the of
carving a chunk and giving it to some well-meaning individual or
organization to manage, the problem does fall on arin.

therefore, i fear that, if this proposal must have a definition of the
beneficiary set, it may be a great opportunity for mailing list banter,
this message being an example, but it is unlikely go anywhere useful.

randy


From martin.hannigan at batelnet.bs  Sun Aug 30 20:13:19 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Sun, 30 Aug 2009 20:13:19 -0400
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks IPv6
	Assignment - Last Call
In-Reply-To: <75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
	<4A9799C5.24405.832697B@farmer.umn.edu>
	<4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4607e1d50908301713p60a678bexd1dbf77d91c18d91@mail.gmail.com>

On Sun, Aug 30, 2009 at 4:24 PM, Milton L Mueller<mueller at syr.edu> wrote:
> Please do not restrict this to "UN recognized NGOs." Only a handful of the world's NGO have the time or inclination to be recognized by the UN; many engaged in political speech would be knocked down by hostile govts if they sought recognition. --MM

I agree, I'm making raw suggestions. I know who originally made a
version of this proposal and believe that the intent was understood.
Today, I'm not quite sure who this policy proposal was written by/for
and the point that I would focus on is that the intent has been lost
in the multiple iterations of it.

There was a suggestion to abandon this and rewrite it specifically for
that reason. In the old regime, the previous PDP, the authors were the
guards of intent. The new PDP is in effect a legislative approach
which is still young and inexperienced. We are seeing many ramrod
approaches under the new regime and this one just happens to be the
most obvious IMHO.

Best,

-M<


From Wesley.E.George at sprint.com  Mon Aug 31 10:08:46 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Mon, 31 Aug 2009 09:08:46 -0500
Subject: [arin-ppml] Draft Policy 2008-3: Community Networks
	IPv6	Assignment - Last Call
In-Reply-To: <4607e1d50908301713p60a678bexd1dbf77d91c18d91@mail.gmail.com>
References: <4A957584.4040608@arin.net> <4A96CBB0.3040005@arin.net>
	<4607e1d50908280504u7bad9d7ft4591643cd73dca34@mail.gmail.com>
	<4A9799C5.24405.832697B@farmer.umn.edu>
	<4607e1d50908300946s17f0697fv29e0dc1b9998d9f2@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D78FF5F777@SUEX07-MBX-04.ad.syr.edu>
	<4607e1d50908301713p60a678bexd1dbf77d91c18d91@mail.gmail.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A8280D381D@PLSWM01C.ad.sprint.com>

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
Sent: Sunday, August 30, 2009 8:13 PM
<snip>
Today, I'm not quite sure who this policy proposal was written by/for
and the point that I would focus on is that the intent has been lost
in the multiple iterations of it.

There was a suggestion to abandon this and rewrite it specifically for
that reason.
<snip>
Best,
-M

+1
I brought it up on the last round of emails on this topic, and rather than clog inboxes with another long mail, I will simply refer to my previous email.
http://lists.arin.net/pipermail/arin-ppml/2009-August/014971.html (sorry for the side-scrolling, word wrap apparently didn't work properly)

I was expecting that the previous discussion would lead to a rework of this proposal to address the concerns, not simply putting it to last call with only minor changes. I intend no disrespect to the AC or their work on this policy thus far, but this says to me that the AC doesn't really know what to do with this policy to address the concerns either despite what I assume are several drafts and many discussions on the topic. I agree that discussing again in Dearborn will not produce different results than the last few meetings it has been discussed in (or the emails), but I'm not sure last call will produce any new direction either.
Unless the AC or an author or someone else who has a clear vision of the problem they are attempting to solve with this proposal can step forward and offer a method to change this draft so that it is much less ambiguous but still covers the intent, we need to abandon it and try again, with a policy that can be championed by one or more of the organizations that it is intended to help.
Otherwise, we're basically making policy decisions based on our interpretation of intent from 2nd and 3rd-hand info in order to help an indistinct group of people/orgs who are either not represented appropriately at ARIN by their parent organization, or unwilling to participate to provide guidance on this policy. My hunch is that it's the former. If that's the case, then those who believe this policy needs to happen need to be reaching out to those folks who can speak to this first-hand so that they can get involved and generate some new (and more productive) discussion on a new policy dealing with the matter at Dearborn or a subsequent meeting.

Thanks
Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From info at arin.net  Mon Aug 31 11:38:39 2009
From: info at arin.net (Member Services)
Date: Mon, 31 Aug 2009 11:38:39 -0400
Subject: [arin-ppml] Draft Policy 2009-6 (Global): IANA Policy for
 Allocation of ASNs to RIRs
Message-ID: <4A9BEE7F.8090802@arin.net>

Draft Policy 2009-6 (Global)
Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN
Blocks (ASNs) to Regional Internet Registries

On 20 August 2009 the ARIN Advisory Council (AC) selected "Internet
Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks
(ASNs) to Regional Internet Registries" as a draft policy for adoption
discussion on the PPML and at the Public Policy Meeting in Dearborn.

The draft was developed by the AC from "Policy Proposal 89. (Global)
Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN
Blocks (ASNs) to Regional Internet Registries". Per the Policy
Development Process the AC submitted text to ARIN for a staff and legal
assessment prior to its selection as a draft policy. After reviewing the
assessment the AC did not change the text.

Draft Policy 2009-6 is below and can be found at:
https://www.arin.net/policy/proposals/2009_6.htm

Below the draft policy is the ARIN staff and legal assessment, including
the original proposal text.

You are encouraged to discuss Draft Policy 2009-6 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process 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,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-6 (Global)
Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN
Blocks (ASNs) to Regional Internet Registries

Version/Date: 31 August 2009

Policy statement:

Modification of NRPM section 10.3 extending the deadline for an
undifferentiated ASN pool by 1 year to read:

1. Allocation Principles
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the
term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,
allocations of 16-bit and 32-bit only ASN blocks will be made separately
and independent of each other [1].

This means until 31 December 2010, RIRs can receive two separate ASN
blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA
under this policy. After this date, IANA and the RIRs will cease to make
any distinction between 16-bit and 32-bit only ASNs, and will operate
ASN allocations from an undifferentiated 32-bit ASN allocation pool.

Rationale:

a. Arguments supporting the proposal

Due to operational issues external to the IANA/RIR policy process,
32-bit only ASNs are not being issued by the RIRs at the anticipated
rate. As it stands, RIRs will likely not be able to justify a new block
of ASNs from the IANA after 31 December 2009 due to a glut of free 32
bit only ASNs in the RIR's pool. This leaves available, essential 16-bit
ASNs stranded in the IANA free pool. This proposal seeks to remedy the
potential problem by extending the deadline for differentiation by one year.

With this proposal the policy will be aligned with the actual reality in
regards to 32-bit ASN deployment and usage.

The subject was raised during RIPE 58 and a presentation was made:
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf 






The feedback in this session suggested that a global policy proposal
should be developed and should be discussed.

b. Arguments opposing the proposal

Some may think that extending the previously set timeline can be
perceived as some discouragement for the deployment of 32-bit ASNs. One
counter argument to this is that RIRs and Internet community have some
other mechanisms and activities to raise awareness for 32-bit ASN pool
(via public presentations and trainings). These activities will continue
while 16-bit ASN blocks are still allocated to RIRs by the IANA as they
are available and they are needed.

Timetable for implementation: Immediately upon ratification by ICANN Board

#####

Staff Assessment

Proposal: Internet Assigned Numbers Authority (IANA) Policy for
Allocation of ASN Blocks (ASNs) to Regional Internet Registries

Proposal Version (Date): 27 May 2009

Date of Assessment: 08-18-09

1. Proposal Summary (Staff Understanding)

This is a global proposal. It modifies section 10.3 of the NRPM to
extend the current deadline for an undifferentiated pool of ASNs from
Dec 31, 2009 to Dec 31, 2010. This proposal would allow IANA to issue
the RIRs blocks of both 16-bit ASNs and 32-bit ASNs until Dec 31, 2010.
After that time, no distinction would be made between the two types of
ASNs, and all ASNs would be allocated from a 32-bit pool.

2. Comments

A. ARIN Staff Comments

The policy can be implemented as written.

The policy would completely remove the word ?byte? from the NRPM in
favor of the term ?bit?.

B. ARIN General Counsel

Counsel does not see any material legal issues related to this policy.

3. Resource Impact

This policy would have minimal resource impact. It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:
Updated guidelines
Staff training

4. Proposal Text

Policy Proposal Name: Internet Assigned Numbers Authority (IANA) Policy
for Allocation of ASN Blocks (ASNs) to Regional Internet Registries

Date: 27 May 2009

Policy statement: Modification of NRPM section 10.3 extending the
deadline for an undifferentiated ASN pool by

1 year to read:

1. Allocation Principles

IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the
term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,
allocations of 16-bit and 32-bit only ASN blocks will be made separately
and independent of each other [1].

This means until 31 December 2010, RIRs can receive two separate ASN
blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA
under this policy. After this date, IANA and the RIRs will cease to make
any distinction between 16-bit and 32-bit only ASNs, and will operate
ASN allocations from an undifferentiated 32-bit ASN allocation pool.

Rationale:

a. Arguments supporting the proposal

Due to operational issues external to the IANA/RIR policy process,
32-bit only ASNs are not being issued by the RIRs at the anticipated
rate. As it stands, RIRs will likely not be able to justify a new block
of ASNs from the IANA after 31 December 2009 due to a glut of free 32
bit only ASNs in the RIR's pool. This leaves available, essential 16-bit
ASNs stranded in the IANA free pool. This proposal seeks to remedy the
potential problem by extending the deadline for differentiation by one year.

With this proposal the policy will be aligned with the actual reality in
regards to 32-bit ASN deployment and usage.

The subject was raised during RIPE 58 and a presentation was made:
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf 






The feedback in this session suggested that a global policy proposal
should be developed and should be discussed.

b. Arguments opposing the proposal

Some may think that extending the previously set timeline can be
perceived as some discouragement for the deployment of 32-bit ASNs. One
counter argument to this is that RIRs and Internet community have some
other mechanisms and activities to raise awareness for 32-bit ASN pool
(via public presentations and trainings). These activities will continue
while 16-bit ASN blocks are still allocated to RIRs by the IANA as they
are available and they are needed.

Timetable for implementation: Immediately upon ratification by ICANN Board












From info at arin.net  Mon Aug 31 11:39:06 2009
From: info at arin.net (Member Services)
Date: Mon, 31 Aug 2009 11:39:06 -0400
Subject: [arin-ppml] Draft Policy 2009-7: Open Access To IPv6
Message-ID: <4A9BEE9A.2000405@arin.net>

Draft Policy 2009-7
Open Access To IPv6

On 20 August 2009 the ARIN Advisory Council (AC) selected "Open Access
To IPv6" as a draft policy for adoption discussion on the PPML and at
the Public Policy Meeting in Dearborn.

The draft was developed by the AC from "Policy Proposal 90: Open Access
To IPv6". Per the Policy Development Process the AC submitted text to
ARIN for a staff and legal assessment prior to its selection as a draft
policy. After reviewing the assessment the AC did not change the text.

Draft Policy 2009-7 is below and can be found at:
https://www.arin.net/policy/proposals/2009_7.htm

Below the draft policy is the ARIN staff and legal assessment, including
the original proposal text.

You are encouraged to discuss Draft Policy 2009-7 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process 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,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-7
Open Access To IPv6

Version/Date: 31 August 2009

Policy statement:

1) Remove ?by advertising that connectivity through its single
aggregated address allocation? from article 3 of section 6.5.1.1

2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in
the ARIN region or have a plan for making at least 200 end-site
assignments to other organizations within 5 years? in its entirety.

Rationale:

It is acknowledged that these concepts have been put before the
community in the past. However, with the wisdom of actual operational
experience, the necessity of promoting IPv6 adoption throughout our
region, and emerging native v6 only network models, it becomes obvious
that these modifications to the NRPM are necessary. Removing the 200 end
site requirement enables smaller, but no less important and viable,
networks access to IPv6. Removing the ?known ISP? requirement
enfranchises new, native v6 businesses that can drive innovation and
expansion in the Internet industry, as well as other industries.
Removing the requirement for a single aggregate announcement benefits
the NRPM itself, as it has been decided by the community that it should
not contain routing advice.

Timetable for implementation: immediately upon BoT ratification

#####
#####

Staff Assessment

Proposal: Open Access to IPv6 (proposal #90)

Proposal Version (Date) 21 May 2009

Date Assessment Due: 05 Aug 2009

1. Proposal Summary (Staff Understanding)

This policy proposal would modify NRPM section 6.5.1.1 by removing all
or part of two initial criteria from the the existing IPv6 policy: the
requirement to advertise the single aggregate and the requirement to
plan on making 200 end site assignments to customers or be a known ISP
in the ARIN region. The only remaining criteria to qualify for an IPv6
allocation are to be an LIR/ISP, not be an end site, and plan on
providing IPv6 connectivity to organizations and assigning them IPv6
address space.

2. Comments

A. ARIN Staff Comments

* This policy would essentially remove all criteria for obtaining IPv6
address space, making it possible for any organization that claims to be
an ISP, and who may have very few, or perhaps no customers, to get a /32
allocation directly from ARIN.

* It may be viewed as unfair in that any ISP, regardless of size, will
now be able to come to ARIN for a /32 with little or no justification,
while other large enterprise organizations that are very well known to
ARIN (i.e. Hewlett Packard) need to provide detailed justification to
obtain any assignment larger than a /48.

B. ARIN General Counsel

Counsel believes this policy is unwise as a legal matter, but will not
recommend the Board refuse to enable it. The flaw is that the policy is
so permissive that fraudulent application to obtain resources will be
made and cannot be stopped because the policy's criterion are so heavily
weighted to issuance, and the criterion for issuance so limited that the
mere assertion one is an ISP, albeit without customers, could lead to
issuance of resources, unless I am misreading the proposed policy. While
encouraging small business or start ups is important, I believe this
policy will improperly encourage and permit fraud in the issuance of
small blocs of IPv6 addresses.

3. Resource Impact

This policy would have minimal resource impact. It is estimated that
implementation would occur within three months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:
* Updated guidelines
* Staff training

4. Proposal Text

Policy Proposal Name: Open Access To IPv6

Version/Date: 21 May 2009

Policy statement:

1) Remove ?by advertising that connectivity through its single
aggregated address allocation? from article 3 of section 6.5.1.1

2) Remove article 4 of section 6.5.1.1, ?be an existing, known ISP in
the ARIN region or have a plan for making at least 200 end-site
assignments to other organizations within 5 years? in its entirety.

Rationale:

It is acknowledged that these concepts have been put before the
community in the past. However, with the wisdom of actual operational
experience, the necessity of promoting IPv6 adoption throughout our
region, and emerging native v6 only network models, it becomes obvious
that these modifications to the NRPM are necessary. Removing the 200 end
site requirement enables smaller, but no less important and viable,
networks access to IPv6. Removing the ?known ISP? requirement
enfranchises new, native v6 businesses that can drive innovation and
expansion in the Internet industry, as well as other industries.
Removing the requirement for a single aggregate announcement benefits
the NRPM itself, as it has been decided by the community that it should
not contain routing advice.

Timetable for implementation: immediately upon BoT ratification







From info at arin.net  Mon Aug 31 11:39:29 2009
From: info at arin.net (Member Services)
Date: Mon, 31 Aug 2009 11:39:29 -0400
Subject: [arin-ppml] Draft Policy 2009-8: Equitable IPv4 Run-Out
Message-ID: <4A9BEEB1.2070708@arin.net>

Draft Policy 2009-8
Equitable IPv4 Run-Out

On 20 August 2009 the ARIN Advisory Council (AC) selected "Equitable
IPv4 Run-Out" as a draft policy for adoption discussion on the PPML and
at the Public Policy Meeting in Dearborn.

The draft was developed by the AC from Policy Proposals "93: Predicable
IPv4 Run Out by Prefix Size and 94: Predictable IPv4 Run Out by
Allocation Window". Per the Policy Development Process the AC submitted
text to ARIN for a staff and legal assessment prior to its selection as
a draft policy. After reviewing the assessment the AC made several
changes to the text.

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

Below the draft policy is the ARIN staff and legal assessment, including
the original proposal text.

You are encouraged to discuss Draft Policy 2009-8 on the PPML prior to
the October Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process 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,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-8
Equitable IPv4 Run-Out

Version/Date: 31 August 2009

Policy statement:

Replace NRPM 4.2.4.4 with;

4.2.4.4 Subscriber Members After One Year

After an organization has been a subscriber member of ARIN for one year,
they may choose to request up to a 12 month supply of IP addresses.

As the IANA free pool decreases, the length of supply that an
organization may request will be reduced at the following thresholds.
This reduction does not apply to resources received via section 8.3. An
organization receiving a transfer under section 8.3 may continue to
request up to a 12 month supply of IP addresses.

When IANA reaches 20 or fewer unallocated /8s, an organization may
choose to request up to a 6 month supply of IP addresses;

When IANA reaches 10 or fewer unallocated /8s, an organization may
choose to request up to a 3 month supply of IP addresses;

Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and following Run-Out

When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a
proportionally decreasing maximum allocation, and assignment, size will
be put into effect. The maximum allocation will be the next whole CIDR
prefix less than or equal to one quarter (1/4) of the total ARIN free
pool available at the time of each allocation, but no longer than the
applicable minimum allocation.

An organization may request additional resources when it can demonstrate
it has properly utilized all previous allocations per applicable
policies. However, the total of all allocations received within the last
three (3) month period and the current request, cannot exceed the
current maximum allocation size.

This maximum allocation size is applicable to allocations from the ARIN
free pool only. It is explicitly not applicable to resources received
via transfer under section 8.3, or any other specially designated resources.

Rationale:

This proposed policy is intended to ensure an equitable distribution of
IPv4 resources as run-out of the IANA free pool and subsequently the
ARIN free pool occurs. This is achieved in two parts; first, changing
section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4
resources that may be requested in steps as the IANA free pool runs-out.
This helps accomplish equity by reducing the window that an advantage or
disadvantage can exist between competitors, that will be created when
one competitor receives a final allocation just before run-out and
another competitor does not.

The reductions in the length of supply will be triggered by IANA
reaching defined levels of unallocated /8s, including the /8s reserved
as part of section 10.4 of the NRPM. These triggers have been chosen
base on the current rate of consumption of /8s by the RIRs.

The first part of this policy is similar to ideas in RIPE policy
proposal 2009-03
(http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been
adapted by discussion and for use within the ARIN region.

The second part of this policy, allows a maximum of one quarter (1/4) of
the then current total IPv4 resources to be allocated in a single
request, once ARIN has received its last /8 from IANA. This helps
achieve equity by ensuring the available resources are spread among
multiple organizations and that no single organization may monopolize
all of the resources available through a single request, at least until
the maximum allocation size has been reduced down to the minimum
allocation size.

Incrementally reducing the length of supply and then reducing the
maximum allocation size in proportion to the amount of resources
available should minimize, or possibly eliminate, the need to fulfill
requests with multiple smaller blocks.

As in the current NRPM, the length of supply only applies to ISP
allocations. However, the maximum allocation size is intended to apply
to both ISP allocations and End-user assignments.

This policy is intended to be independent of other policies or proposals
to reserve address space for IPv6 transition or other purposes. Neither
part is intended to limit Transfers to Specified Recipients per section
8.3 of the NRPM.

The current maximum allocation size should be published on the ARIN
website, preferably in real-time, as it may change rapidly as the ARIN
free pool resources are exhausted. In the worst-case the maximum
allocation size will decrease every forth allocation, when all four are
the then current maximum allocation size. However, in the beginning
there will likely be many smaller allocations before the maximum
allocation size is decreased, accelerating as the resources are exhausted.

Following the run-out phase, this policy provides an equitable means of
distribution of resources if or when additional resources become
available after ARIN has initially exhausted such resources. Such as if
resources are returned, recovered by other means, or additional
resources are obtained from IANA. Further, whenever ARIN receives a
sufficiently large amount of additional resources, this policy intends
for the maximum allocation size to be increased accordingly.

After ARIN receives its last /8, the intent is to normally limit an
organization to a single maximum allocation within a three month period.
However, saying it that simply opens this policy to gamesmanship in
requesting less than a maximum allocation. Requiring a maximum
allocation to cover new requests and all allocations received in the
previous three month period, should eliminate this kind of gamesmanship.

There is a beneficial side effect of stating it this way, in the special
situation when the maximum allocation size is increased, due to ARIN
obtaining a sufficiently large amount of additional resources, an
organization may receive additional resources earlier than the normal
three month period. But, only in this special situation and when an
organization properly utilizes a previous maximum allocation in less
than three months, may an organization receive additional resources in
less than the normal three month period.

Other ratios, such as one half (1/2) or one eighth (1/8) could be
considered. One eighth (1/8) would provide greater assurance of
eliminating the need to use multiple blocks to fulfill requests and
ensure a greater number of organizations receive resources. However, one
eighth (1/8) is more likely to be seen as rationing and an attempt to
artificially extend the lifetime of IPv4. During the ARIN XXIII policy
discussion there seemed to be a consensus that attempts to extend the
lifetime of IPv4 resources would be undesirable. While on the other
hand, one half (1/2) is even less likely to ration resources, but it
would likely result in the resource being spread across significantly
fewer organizations and increase the need to use multiple blocks to
fulfill requests.

In conclusion, combining the final 3 month length of supply with the one
quarter (1/4) ratio provides roughly an annualized equivalent of the
whole ARIN free pool being made available to a single organization.
While it is not possible for a single organization to receive the whole
ARIN free pool within one year under this policy, it is a virtual
certainty that multiple organization will be requesting resources, and
that the ARIN free pool will not likely last a full year following the
exhaustion of the IANA free pool anyway. Therefore, the ratio one
quarter (1/4) seems to strike a balance between making resources
available with as little restriction as possible and ensuring an
equitable distribution of those resources during and following the
run-out phase.

EDITORIAL NOTE: This Draft Policy 2009-8 merges ideas from two separate
policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94.
Predictable IPv4 Run Out by Allocation Window.

Timetable for implementation: Immediate

#####
#####

Proposal: Equitable IPv4 Run-Out

Proposal Version (Date): 3 August 2009

Date of Assessment:  18 August 2009

1. Proposal Summary (Staff Understanding)
Staff understands the policy applies to ISPs who have been ARIN members
for more than a year. When IANA reaches 20 /8s, the supply period for
IPv4 address space will decrease from a 12 months to 6 months. When the
IANA reaches 10 or less /8s,  the supply period is reduced to 3 months.
The second part of the proposal triggers upon receipt of ARIN?s last /8
from the IANA (per NRPM 10.4.2.2). The policy would establish a new
maximum prefix size for all requests and place a limit on the amount of
space an organization can receive  within any three month period. The
maximum prefix size would be on a sliding  scale relative to the total
amount of free IPv4 addresses in ARIN's inventory (one  fourth of the
total rounded down to the nearest smallest CIDR prefix). These polices
do not apply to Transfers to Specified Recipients (NRPM 8.3).

2. Comments

A.  ARIN Staff Comments

   The policy can be implemented as written.

   The title of section 4.2.4.4 needs to change from ?Twelve Months? to
?Subscriber Members After One Year?.

   Note that the maximum prefix size in effect at any given time (e.g.
/16) may be larger than the largest available contiguous address block
in ARIN?s inventory (e.g. /18). In order to fulfill a request in this
scenario, ARIN would have to issue several discontiguous address blocks.

   There is a suggestion in the rationale to display the maximum prefix
size in real time. But that prefix size might not be available upon
completion of a request. Example, on Friday we display /18. By the time
the request is finalized, the maximum is a /19, and that?s what is
issued to the customer.  We could put a disclaimer that the actual
prefix issued to a customer could be  smaller. Also, we see value in
keeping track of the maximum prefix size over time.

   The third sentence of the proposed 4.2.4.4 (starting with "This
reduction") is a run-on sentence and contains grammatical errors. ARIN
staff suggests the  following replacement text: ?This reduction does not
apply to resources received via section 8.3. Organizations requesting
transfers under 8.3 may choose to request up to a 12-month supply of IP
addresses.?

B. ARIN General Counsel

   ARIN has the legal duty and authority to establish more restrictive
rules to ?ration? the issuance of IPv4 resources as the scarcity of such
resources increases.  However, such rules must make clear rational sense
given current circumstances, and may be tested in litigation by
disappointed parties at the time they come fully into effect, not when
adopted.  Therefore, the proposed policy here will need to be carefully
reviewed and if passed, carefully implemented, for example, to prevent
any ?side effect? that would inadvertently favor one set of ISPs over
another.

3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to
implement:
   Updates to software
   Updated guidelines
   Staff training

4. Proposal Text

Equitable IPv4 Run-Out

Date: 3 August 2009

Policy statement:

Replace the text in NRPM 4.2.4.4 with;

After an organization has been a subscriber member of ARIN for one year,
they may choose to request up to a 12 month supply of IP addresses. As
the IANA free pool decreases, the length of supply that an organization
may request will be reduced at the following thresholds. This reduction
does not apply to  resources received via Transfers to Specified
Recipients per section 8.3, in this case  an organization may continue
choose to request up to a 12 month supply of IP addresses.

When IANA reaches 20 or fewer unallocated /8s , an organization may
choose to request up to a 6 month supply of IP addresses;

When IANA reaches 10 or fewer unallocated /8s , an organization may
choose to request up to a 3 month supply of IP addresses;

Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and following Run-Out

When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a
proportionally decreasing maximum allocation, and assignment, size will
be put into effect. The maximum allocation will be the next whole CIDR
prefix less than or equal to one quarter (1/4) of the total ARIN free
pool available at the time of each  allocation, but no longer than the
applicable minimum allocation. An OrgID may request additional resources
when it can demonstrate it has properly  utilized all previous
allocations per applicable policies. However, the total of all
allocations received within the last three (3) month period and the
current request, cannot exceed the current maximum allocation size.
This maximum allocation size is applicable to allocations from the ARIN
free pool only, and is explicitly not applicable to resources received
through Transfers to Specified Recipients per section 8.3, or any other
specially designated resources.

Rationale:

This proposed policy is intended to ensure an equitable distribution of
IPv4 resources as run-out of the IANA free pool and subsequently the
ARIN free pool occurs. This is achieved in two parts; first, changing
section 4.2.4.4 of the NRPM to reduce the length of supply of IPv4
resources that may be requested in steps as the IANA free pool runs-out.
This helps accomplish equity by reducing the window that an advantage or
disadvantage can exist between competitors, that will be created
when one competitor receives a final allocation just before run-out and
another competitor does not.

The reductions in the length of supply will be triggered by IANA
reaching defined levels of unallocated /8s, including the /8s reserved
as part of section 10.4 of the NRPM. These triggers have been chosen
base on the current rate of consumption of /8s by the RIRs.

The first part of this policy is similar to ideas in RIPE policy
proposal 2009-03
(http://www.ripe.net/ripe/policies/proposals/2009-03.html), and has been
adapted by discussion and for use within the ARIN region.

The second part of this policy, allows a maximum of one quarter (1/4) of
the then current total IPv4 resources to be allocated in a single
request, once ARIN has  received its last /8 from IANA. This helps
achieve equity by ensuring the available resources are spread among
multiple organizations and that no single organization may monopolize
all of the resources available through a single request, at least
until the maximum allocation size has been reduced down to the minimum
allocation size.

Incrementally reducing the length of supply and then reducing the
maximum allocation size in proportion to the amount of resources
available should minimize, or possibly eliminate, the need to fulfill
requests with multiple smaller blocks.

As in the current NRPM, the length of supply only applies to ISP
allocations. However, the maximum allocation size is intended to apply
to both ISP allocations and End-user assignments.

This policy is intended to be independent of other policies or proposals
to reserve address space for IPv6 transition or other purposes. Neither
part is intended to limit Transfers to Specified Recipients per section
8.3 of the NRPM.

The current maximum allocation size should be published on the ARIN
website, preferably in real-time, as it may change rapidly as the ARIN
free pool resources are exhausted. In the worst-case the maximum
allocation size will decrease every forth allocation, when all four are
the then current maximum allocation size. However, in the beginning
there will likely be many smaller allocations before the maximum
allocation size is decreased, accelerating as the resources are exhausted.

Following the run-out phase, this policy provides an equitable means of
distribution of resources if or when additional resources become
available after ARIN has  initially exhausted such resources. Such as if
resources are returned, recovered by other means, or additional
resources are obtained from IANA. Further, whenever ARIN receives a
sufficiently large amount of additional resources, this policy
intends for the maximum allocation size to be increased accordingly.

After ARIN receives its last /8, the intent is to normally limit an
organization to a single maximum allocation within a three month period.
However, saying it that simply opens this policy to gamesmanship in
requesting less than a maximum allocation. Requiring a maximum
allocation to cover new requests and all allocations received in the
previous three month period, should eliminate this kind
of gamesmanship.

There is a beneficial side effect of stating it this way, in the special
situation when the maximum allocation size is increased, due to ARIN
obtaining a sufficiently large amount of additional resources, an
organization may receive additional resources earlier than the normal
three month period. But, only in this special situation and
when an organization properly utilizes a previous maximum allocation in
less than three months, may an organization receive additional resources
in less than the normal three month period.

Other ratios, such as one half (1/2) or one eighth (1/8) could be
considered. One eighth (1/8) would provide greater assurance of
eliminating the need to use multiple blocks to fulfill requests and
ensure a greater number of organizations receive resources. However, one
eighth (1/8) is more likely to be seen as rationing and an attempt to
artificially extend the lifetime of IPv4. During the ARIN XXIII policy
discussion there seemed to be a consensus that attempts to extend the
lifetime of IPv4 resources would be undesirable. While on the other
hand, one half (1/2) is even less likely to ration resources, but it
would likely result in the resource being spread across significantly
fewer organizations and increase the need to use multiple blocks
to fulfill requests.

In conclusion, combining the final 3 month length of supply with the one
quarter (1/4) ratio provides roughly an annualized equivalent of the
whole ARIN free pool being made available to a single organization.
While it is not possible for a single organization to receive the whole
ARIN free pool within one year under this policy, it is a virtual
certainty that multiple organization will be requesting resources, and
that the ARIN free pool will not likely last a full year following the
exhaustion of the IANA free pool anyway. Therefore, the ratio one
quarter (1/4) seems to strike a balance between making resources
available with as little restriction as possible and ensuring an
equitable distribution of those resources during and following the
run-out phase.

EDITORIAL NOTE: This Draft Policy 2009-X merges ideas from two separate
policy proposals, 93. Predicable IPv4 Run Out by Prefix Size and 94.
Predictable IPv4 Run Out by Allocation Window.

Timetable for implementation: Immediate