From mysidia at gmail.com  Thu Jul  1 01:47:12 2010
From: mysidia at gmail.com (James Hess)
Date: Thu, 1 Jul 2010 00:47:12 -0500
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
Message-ID: <AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>

On Wed, Jun 30, 2010 at 2:15 PM, Keith W. Hare <Keith at jcc.com> wrote:
> We've had a /24 since 1991 and so are a legacy resource holder. We mostly ignored ARIN (because ARIN mostly ignored us) until about three years ago when there was some sort of outreach. At that point, I started monitoring the ARIN mailing lists and decided it made sense for us to support ARIN.

I don't think the above was suggesting there are no end-user members.
The restrictions on membership are pretty darn offensive I would
say...  organizations which are part  of the American RIR community
which ARIN is supposed to serve but do not have resources directly
allocated/assigned ARIN are arbitrarily  excluded from joining ARIN.

The end user organizations without direct assignments that get
resources issued to them by their LIR (or ISP) under ARIN policies,
and their resources are of course still  ultimately subject to ARIN
rules, continued justification of resources, etc.

So.. What is the justification that a legacy /24 holder, can sign a
LRSA and be an ARIN member, and yet an end user org in the ARIN region
who has just a /24 allocation from their LIR (ISP) cannot  be an ARIN
member also,  if they would prefer?

The indirect resource holder can only be  "ARIN Advocate",   AKA
serfs.; entities that support ARIN and provide ARIN financial backing,
but are arbitrarily denied voting rights, and therefore meaningful
representation in what is supposed to be open community driven
processes  (but are thereby restricted).

A significant number of  IP address users with regards to ARIN policy
are thereby arbitrarily excluded.


> Compared to our costs for software and hardware maintenance, $500 for the ARIN membership is noise.
Perhaps, but someone at each end user org still has to make a decision
that money is worth spending.
And I expect most end users are not legacy holders.

Anyways, ARIN is so kind to publish a list of members:
https://www.arin.net/public/memberList.xhtml
So,  as you can see there are  ~3570  entries  shown.

ARIN is also kind enough to publish some statistics  as well   (but
not enough statistics to ascertain)

One can infer, based on AS number utilization,   that  perhaps  not
that large a percentage of end users  are necessarily members.
How many   active end user  org IDs are there actually..?

Presumably one should be able to just  divide  3600  by the number of
Org IDs,  and get a pretty good approximation,   if  every
non-member  Org ID  must be an end-user...

-- 
-JH


From scottleibrand at gmail.com  Thu Jul  1 01:57:55 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 30 Jun 2010 22:57:55 -0700
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
 Use of "reserved" address space)
In-Reply-To: <AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>	<4C2B6362.4040709@gmail.com>	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
Message-ID: <4C2C2E63.5040005@gmail.com>

On Wed 6/30/2010 10:47 PM, James Hess wrote:
> On Wed, Jun 30, 2010 at 2:15 PM, Keith W. Hare<Keith at jcc.com>  wrote:
>    
>> We've had a /24 since 1991 and so are a legacy resource holder. We mostly ignored ARIN (because ARIN mostly ignored us) until about three years ago when there was some sort of outreach. At that point, I started monitoring the ARIN mailing lists and decided it made sense for us to support ARIN.
>>      
> I don't think the above was suggesting there are no end-user members.
> The restrictions on membership are pretty darn offensive I would
> say...  organizations which are part  of the American RIR community
> which ARIN is supposed to serve but do not have resources directly
> allocated/assigned ARIN are arbitrarily  excluded from joining ARIN.
>
> The end user organizations without direct assignments that get
> resources issued to them by their LIR (or ISP) under ARIN policies,
> and their resources are of course still  ultimately subject to ARIN
> rules, continued justification of resources, etc.
>
> So.. What is the justification that a legacy /24 holder, can sign a
> LRSA and be an ARIN member, and yet an end user org in the ARIN region
> who has just a /24 allocation from their LIR (ISP) cannot  be an ARIN
> member also,  if they would prefer?
>    

Actually, that will be changing very shortly, based on the outcome of 
the Public Policy process.  The AC just recommended that the Board adopt 
2010-2: /24 End User Minimum Allocation Unit, which will mean those orgs 
will qualify to get space from ARIN directly.

-Scott

> The indirect resource holder can only be  "ARIN Advocate",   AKA
> serfs.; entities that support ARIN and provide ARIN financial backing,
> but are arbitrarily denied voting rights, and therefore meaningful
> representation in what is supposed to be open community driven
> processes  (but are thereby restricted).
>
> A significant number of  IP address users with regards to ARIN policy
> are thereby arbitrarily excluded.
>
>
>    
>> Compared to our costs for software and hardware maintenance, $500 for the ARIN membership is noise.
>>      
> Perhaps, but someone at each end user org still has to make a decision
> that money is worth spending.
> And I expect most end users are not legacy holders.
>
> Anyways, ARIN is so kind to publish a list of members:
> https://www.arin.net/public/memberList.xhtml
> So,  as you can see there are  ~3570  entries  shown.
>
> ARIN is also kind enough to publish some statistics  as well   (but
> not enough statistics to ascertain)
>
> One can infer, based on AS number utilization,   that  perhaps  not
> that large a percentage of end users  are necessarily members.
> How many   active end user  org IDs are there actually..?
>
> Presumably one should be able to just  divide  3600  by the number of
> Org IDs,  and get a pretty good approximation,   if  every
> non-member  Org ID  must be an end-user...
>
>    


From michael.dillon at bt.com  Thu Jul  1 03:21:57 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 1 Jul 2010 08:21:57 +0100
Subject: [arin-ppml] Future pressures on the ARIN policy process
	(Was:Use of "reserved" address space)
In-Reply-To: <AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net><20100630151528.A39D82B2131@mx5.roble.com><4C2B6362.4040709@gmail.com><AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com><f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com><AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com><5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458066BE0BE@E03MVZ2-UKDY.domain1.systemhost.net>

> So.. What is the justification that a legacy /24 holder, can sign a
> LRSA and be an ARIN member, and yet an end user org in the ARIN region
> who has just a /24 allocation from their LIR (ISP) cannot  be an ARIN
> member also,  if they would prefer?

Isn't there a members at large category?

In any case, ARIN members do not make ARIN policy. That is done in
public on the PPML list where anyone can participate without paying
a fee.

--Michael Dillon



From owen at delong.com  Thu Jul  1 05:27:20 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Jul 2010 02:27:20 -0700
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <4C2C2E63.5040005@gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>	<4C2B6362.4040709@gmail.com>	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<4C2C2E63.5040005@gmail.com>
Message-ID: <ABF7D2DB-A3AC-4DB6-9137-B659BD3FB71E@delong.com>

> 
> Actually, that will be changing very shortly, based on the outcome of the Public Policy process.  The AC just recommended that the Board adopt 2010-2: /24 End User Minimum Allocation Unit, which will mean those orgs will qualify to get space from ARIN directly.
> 
No, not all of them.

Owen



From jcurran at arin.net  Thu Jul  1 06:21:16 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 1 Jul 2010 06:21:16 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process
	(Was:	Use of "reserved" address space)
In-Reply-To: <AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
Message-ID: <D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>

On Jul 1, 2010, at 1:47 AM, James Hess wrote:

> A significant number of  IP address users with regards to ARIN policy
> are thereby arbitrarily excluded.

Incorrect; all of these IP address users may participate in the ARIN
policy development process, as it is open to all parties.  They may 
even join ARIN if so desired, but if they do not receive registry 
services from ARIN, then they are not considered General Members 
and therefore cannot vote in elections.  

> Anyways, ARIN is so kind to publish a list of members:
> https://www.arin.net/public/memberList.xhtml
> So,  as you can see there are  ~3570  entries  shown.
> 
> ARIN is also kind enough to publish some statistics  as well   (but
> not enough statistics to ascertain)
> 
> One can infer, based on AS number utilization,   that  perhaps  not
> that large a percentage of end users  are necessarily members.
> How many   active end user  org IDs are there actually..?

I have the statistics from the time of the membership change 
(Dec 2009) and can provide those numbers to help clarify:

   Approximately 3450 Members who were ISPs

   Approximately   20 Members who were End-Users (with an additional 
                      1440 End-User organizations with RSA who have 
                      had not opted for membership at that time)
  
There may be more End-User members now, and we'll work on getting 
more detailed membership statistics made available online.

Thanks!
/John

John Curran
President and CEO
ARIN




From bill at herrin.us  Thu Jul  1 11:17:42 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Jul 2010 11:17:42 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
Message-ID: <AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>

On Thu, Jul 1, 2010 at 6:21 AM, John Curran <jcurran at arin.net> wrote:
> I have the statistics from the time of the membership change
> (Dec 2009) and can provide those numbers to help clarify:
>
> ? Approximately 3450 Members who were ISPs
>
> ? Approximately ? 20 Members who were End-Users (with an additional
> ? ? ? ? ? ? ? ? ? ? ?1440 End-User organizations with RSA who have
> ? ? ? ? ? ? ? ? ? ? ?had not opted for membership at that time)

Putting these numbers in perspective:

3450 non-trivial ISPs in the ARIN region, all eligible to vote on who
sits on the AC or board

20 non-ISPs in the ARIN region eligible to vote on who sites on the AC or board.

Unknown number of organizations with non-trivial address holdings (/27
or larger). either directly from ARIN or via their ISP in the ARIN
region  Lower bound likely to be at least 100,000.

Non-ISP interests represented during board and AC elections: fraction
of a percent and not a large fraction.

Board power over ARIN policy: few real limits that aren't self-imposed
(hence changeable should we ever fail to elect an "enlightened" board)

1736 votes maximum needed to to replace the board @ $500 each would
cost $868k if ARIN didn't tie membership to orgs directly holding
resources.

Annual dollar value of favorable policy to the transit-free ISPs in
the ARIN region: unknown but surely growing more significant with v4
address exhaustion.

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 mueller at syr.edu  Thu Jul  1 13:15:39 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 1 Jul 2010 13:15:39 -0400
Subject: [arin-ppml] Use of "reserved" address space.
In-Reply-To: <554DA757-F22C-428E-9EDE-5805DE451DF6@arin.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu>
	<4C2B90AE.8060609@ipinc.net>
	<554DA757-F22C-428E-9EDE-5805DE451DF6@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D705C801E550@SUEX07-MBX-04.ad.syr.edu>



> 
> On Jun 30, 2010, at 2:45 PM, Ted Mittelstaedt wrote:
> 
> > I have to agree mostly with Milton here, also I'll point out that
> > recently ARIN joined the ITU and as the ITU is an agency of the
> > United Nations, ARIN has in some ways lost it's independence
> > from the government.

Ted, nice as it is to be in agreement, let me point out some facts about sector membership in the ITU. 
Joining the ITU as a sector member means basically that you pay them some money (40k or so) and get access to their documents and certain meetings. I don't think it affects ARIN's legal or policy independence from govts. 



From Keith at jcc.com  Thu Jul  1 13:39:38 2010
From: Keith at jcc.com (Keith W. Hare)
Date: Thu, 1 Jul 2010 13:39:38 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process
	(Was:	Use of "reserved" address space)
In-Reply-To: <AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
Message-ID: <b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e7@jcc.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, July 01, 2010 11:18 AM
> To: John Curran
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Future pressures on the ARIN policy process
> (Was: Use of "reserved" address space)
> 
> On Thu, Jul 1, 2010 at 6:21 AM, John Curran <jcurran at arin.net> wrote:
> > I have the statistics from the time of the membership change
> > (Dec 2009) and can provide those numbers to help clarify:
> >
> > ? Approximately 3450 Members who were ISPs
> >
> > ? Approximately ? 20 Members who were End-Users (with an additional
> > ? ? ? ? ? ? ? ? ? ? ?1440 End-User organizations with RSA who have
> > ? ? ? ? ? ? ? ? ? ? ?had not opted for membership at that time)
> 
> Putting these numbers in perspective:
> 
> 3450 non-trivial ISPs in the ARIN region, all eligible to vote on who
> sits on the AC or board
> 
> 20 non-ISPs in the ARIN region eligible to vote on who sites on the AC
> or board.
> 
> Unknown number of organizations with non-trivial address holdings (/27
> or larger). either directly from ARIN or via their ISP in the ARIN
> region  Lower bound likely to be at least 100,000.
> 
> Non-ISP interests represented during board and AC elections: fraction
> of a percent and not a large fraction.

>From what I've seen in the last couple of years, there are multiple ISP interests. Some of these interests coincide with my interests as a non-ISP. Some of the interests are so arcane as to be uninteresting.

> Board power over ARIN policy: few real limits that aren't self-imposed
> (hence changeable should we ever fail to elect an "enlightened" board)
> 
> 1736 votes maximum needed to to replace the board @ $500 each would
> cost $868k if ARIN didn't tie membership to orgs directly holding
> resources.

Your math does not hold up. For every additional voting organization, the number to achieve a majority increases by an average of .5.

> 
> Annual dollar value of favorable policy to the transit-free ISPs in
> the ARIN region: unknown but surely growing more significant with v4
> address exhaustion.

I'm skeptical that it is possible to construct a policy that would vastly favor one group of ARIN participants without greatly impacting another group of ARIN participants.

So, why the concern about non-ISP ARIN voters?

Keith Hare


______________________________________________________________
 
Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com                     600 Newark Road
Phone: 740-587-0157               P.O. Box 381
Fax: 740-587-0163                 Granville, Ohio 43023
http://www.jcc.com                USA
______________________________________________________________





From bill at herrin.us  Thu Jul  1 14:21:32 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Jul 2010 14:21:32 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com> 
	<b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>
Message-ID: <AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com>

On Thu, Jul 1, 2010 at 1:39 PM, Keith W. Hare <Keith at jcc.com> wrote:
>> 1736 votes maximum needed to to replace the board @ $500 each would
>> cost $868k if ARIN didn't tie membership to orgs directly holding
>> resources.
>
> Your math does not hold up. For every additional voting
> organization, the number to achieve a majority increases
> by an average of .5.

Hi Keith,

I stand corrected. Max 3471 votes @ $500 each. Much less in reality
since eligible voters > voters who vote.


>> Annual dollar value of favorable policy to the transit-free ISPs in
>> the ARIN region: unknown but surely growing more significant with v4
>> address exhaustion.
>
> I'm skeptical that it is possible to construct a policy that
> would vastly favor one group of ARIN participants without
> greatly impacting another group of ARIN participants.

That's the point. Hand-pick the board and you can ram through nearly
anything you want, even if it has a significant downside for ARIN
participants who aren't you. There are some limits in place, but
little that isn't readily skirted with a simple majority vote of board
members. Certainly nothing of the "checks and balances" variety built
down in the portions of ARIN's structure that are immutable.

Things like the board members not drafting policies... the board can
change that with a simple majority vote.

I'm also not entirely sure how ARIN went about changing "those who pay
$500 are eligible to vote" to "those who pay and hold resources." Was
voting eligibility also decided with a vote of the board? If a process
can change it one way, the same process can change it another.

I don't mean to suggest that any of this would happen... I merely
suggest that the obstacles are more political than structural. Given
sufficient motivation it wouldn't be altogether hard to form a cabal.

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 jcurran at arin.net  Thu Jul  1 14:45:38 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 1 Jul 2010 14:45:38 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
 Use of "reserved" address space)
In-Reply-To: <AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>
	<AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com>
Message-ID: <4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>

On Jul 1, 2010, at 2:29 PM, "William Herrin" <bill at herrin.us<mailto:bill at herrin.us>> wrote:

That's the point. Hand-pick the board and you can ram through nearly
anything you want, even if it has a significant downside for ARIN
participants who aren't you. There are some limits in place, but
little that isn't readily skirted with a simple majority vote of board
members. Certainly nothing of the "checks and balances" variety built
down in the portions of ARIN's structure that are immutable.

Things like the board members not drafting policies... the board can
change that with a simple majority vote.

I'm also not entirely sure how ARIN went about changing "those who pay
$500 are eligible to vote" to "those who pay and hold resources." Was
voting eligibility also decided with a vote of the board? If a process
can change it one way, the same process can change it another.


You are absolutely correct with respect to the power of the Board
and ability of a single entity to potentially "capture" the organization
if they were able to dominate an election at the last minute.  This is
the type of potential risk that the Board considered when making the
recent changes in membership and voting.

/John

John Curran
President and CEO
ARIN

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

From info at arin.net  Thu Jul  1 14:46:14 2010
From: info at arin.net (Member Services)
Date: Thu, 01 Jul 2010 14:46:14 -0400
Subject: [arin-ppml] Policy Proposal 115. Global Policy for IPv4 Allocations
 by the IANA Post Exhaustion - revised text
Message-ID: <4C2CE276.4040204@arin.net>

The proposal originator submitted a revised version of the proposal.

Regards,

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


## * ##


Policy Proposal 115: Global Policy for IPv4 Allocations by the IANA Post
Exhaustion

Proposal Originator: Martin Hannigan on behalf of authors for ASO AC/NRO NC

Version/Date 1 July 2010

Policy statement:

1. Reclamation Pool

Upon adoption of this IPv4 address policy by the ICANN Board of
Directors, the IANA shall establish a Reclamation Pool to be utilized
post RIR IPv4 exhaustion as defined in Section 5. As soon as the first
RIR exhausts its inventory of IP address space, this Reclamation Pool
will be declared active. When the Reclamation Pool is declared active,
the Global Policy for the Allocation of the Remaining IPv4 Address
Space[3] and Policy for Allocation of IPv4 Blocks to Regional Internet
Registries[4] will be formally deprecated.

2. Returning Address Space to the IANA

The IANA will accept into the Reclamation Pool all eligible IPv4 address
space that are offered for return. Eligible address space includes
addresses that are not designated as "special use" by an IETF RFC or
addresses allocated to RIR's unless they are being returned by the RIR
that they were originally allocated to. Legacy address holders may
return address space directly to the IANA if they so choose.

3. Address Allocations from the Reclamation Pool by the IANA

Allocations from the Reclamation Pool may begin once the pool is
declared active. Addresses in the Reclamation Pool will be allocated on
a CIDR boundary equal to or shorter than the longest minimum allocation
unit of all RIRs in order to complete these allocations.The Reclamation
Pool will be divided on CIDR boundaries and distributed evenly to all
eligible RIR's. Any remainder not evenly divisible by the number of
eligible RIR's based on a CIDR boundary equal to or shorter than the
longest minimum allocation unit of all RIRs will remain in the
Reclamation Pool. Addresses that are left over will be held in the
Reclamation Pool until additional IP addresses can be returned to rejoin
addresses on CIDR boundaries to the Reclamation Pool or a minumum
allocation unit is set to allow allocation from existing inventory.

4. RIR Eligibility for Receiving Allocations from the Reclamation Pool

Upon the exhaustion of an RIR's free space pool, an RIR will become
eligible to request address space from the IANA Reclamation Pool when it
publicly announces via its respective global announcements email list
and by posting a notice on its website that it has exhausted its supply
of IPv4 address space. Exhaustion is defined as an inventory of less
than the equivalent of a single /8 and the inability to further assign
address space to its customers in units equal to or shorter than the
longest of the RIR's policy defined minimum allocation unit. Any RIR
that is formed after the ICANN Board of Directors has ratified this
policy is not eligible to utilize this policy to obtain IPv4 address
space from the IANA.

5. Reporting Requirements

The IANA shall publish on at least a weekly basis a report that is
publicly available which at a minimum details all address space that has
been received and that has been allocated. The IANA shall publish a
Returned Address Space Report which indicates what resources were
returned, by whom and when. The IANA shall publish an Allocations Report
on at least a weekly basis which at a minimum indicates what IPv4
address space has been allocated, which RIR received the allocation and
when. The IANA shall publish a public notice confirming RIR eligibility
subsequent to Section 4.

6. No Transfer Rights

Address space assigned from the Reclamation Pool may be transferred if
there is either an ICANN Board ratified global policy or globally
coordinated RIR policy specifically written to deal with transfers
whether inter-RIR or from one entity to another. Transfers must meet the
requirements of such a policy. In the absence of such a policy, no
transfers of any kind related to address space allocated or assigned
from the reclamation pool is allowed.

7. Definitions

IANA - Internet Assigned Numbers Authority, or its successor

ICANN - Internet Corporation for Assigned Names and Numbers, or its
successor

RIR - Regional Internet Registry as recognized by ICANN

MOU - Memorandum of Understanding between ICANN and the RIRs

IPv4 - Internet Protocol Version Four(4), the target protocol of this
Global Policy

Free Space Pool - IPv4 Addresses that are in inventory at any RIR,
and/or the IANA

8. Contributors

The following individuals donated their time, resources and effort to
develop this proposal on behalf of the Internet Community:

Steve Bertrand <steve at ipv6canada.com <mailto:steve at ipv6canada.com>>

Chris Grundemann <cgrundemann at gmail.com <mailto:cgrundemann at gmail.com>>

Martin Hannigan <marty at akamai.com <mailto:marty at akamai.com>>

Aaron Hughes <ahughes at bind.com <mailto:ahughes at bind.com>>

Louie Lee <louie at equinix.com <mailto:louie at equinix.com>>

Matt Pounsett <matt at conundrum.com <mailto:matt at conundrum.com>>

Jason Schiller <schiller at uu.net <mailto:schiller at uu.net>>

9. References

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm

Global Policy for the Allocation of the Remaining IPv4 Address Space,
IANA, Retrieved 27 April 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html

ICANN Address Supporting Organization (ASO) MoU

<http://bind.com/gpp4-2010/bin/edit/Main/MoU?topicparent=Main.GlobalPolicyFo

rTheDistributionOfIPv4Resources;nowysiwyg=0>  , Retrieved 27 May 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm

Global Policy for the Allocation of the Remaining IPv4 Address Space

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy
for Allocation of IPv4 Blocks to Regional Internet Registries


Rationale

This policy defines the process for the allocation of IPv4 addresses
post "Exhaustion Phase"[1]. A global policy is required in order for the
IANA to be able to transparently continue to be able to allocate IPv4
addresses beyond exhaustion. In order to fulfill the requirements of
this policy, the IANA must set up a reclamation pool to hold addresses
in and distribute from in compliance with this policy. This policy
establishes the process by which IPv4 addresses can be returned to and
re-issued from the IANA post Exhaustion Phase.

This document does not stipulate performance requirements in the
provision of services by the IANA to an RIR in accordance with this
policy. Such requirements should be specified by appropriate agreements
among the RIRs and ICANN.

The intent of this policy is as follows:

*  To include all post Exhaustion Phase IPv4 address space returned to
the IANA.

*  Allows allocations by the IANA from the Reclamation Pool once the
Exhaustion Phase has been completed.

*  Defines "need" as the basis for further IPv4 allocations by the IANA.

*  Does not differentiate any class of IPv4 address space unless
otherwise defined by an RFC.

*  Encourage the return of IPv4 address space by making this allocation
process available.

*  Disallow transfers of addresses sourced from the Reclamation Pool in
the absence of an IPv4 Global Transfer Policy to neutralize transfer
process inequities across RIR regions.

*  Applies to legacy IPv4 Address Space initially allocated by the IANA
to users including the allocations to RIRs.

*  Includes any length of fragments currently held by the IANA now or in
the future.

Timetable for implementation: Immediate








From bill at herrin.us  Thu Jul  1 16:00:42 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Jul 2010 16:00:42 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com> 
	<b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>
	<AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com> 
	<4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>
Message-ID: <AANLkTin7zIQhOJIqW7ZEVm6lm62_sVk1c4Z5K4Lcvl4w@mail.gmail.com>

On Thu, Jul 1, 2010 at 2:45 PM, John Curran <jcurran at arin.net> wrote:
> You are absolutely correct with respect to the power of the Board
> and ability of a single entity to potentially "capture" the organization
> if they?were able to dominate an election at the last minute. ?This is
> the type of potential risk that the Board considered when making the
> recent changes in membership and voting.

Hi John,

I agree with the board's decision to do away with "anybody can vote
with a $500 payment," for exactly the reasons you point out but I also
agree with James Hess' comment:

) The restrictions on membership are pretty darn offensive I would
) say...  organizations which are part  of the American RIR community
) which ARIN is supposed to serve but do not have resources directly
) allocated/assigned ARIN are arbitrarily  excluded from joining ARIN.

3450 ISPs and 20 non-ISPs eligible to vote has had a lopsided effect
on the folks selected for the board and the AC. Particularly the AC
most of whom haven't, shall we say, reached the height of
statesmanship achieved by the luminaries considered for the board.

Were the voter groups reversed, how many years ago would we have
sensibly reduced the minimum assignment to /24 for multihomed
end-users? Would *any* AC member elected by 3450 end-user orgs have
voted against recommending /24 for multihomers to the board?

Facing IPv4 address exhaustion, would a board elected by 3450 end-user
orgs accept a pricing recommendation of $1,200 for a thousand IPv4
addresses and only $18,000 for ten million?

I have no magic bullet for this problem. Voting systems are
surprisingly hard to do well and fairly. But Scott wanted suggestions
and one of my suggestions is: look for more ways to solve or mitigate
this problem.

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 marty at akamai.com  Thu Jul  1 16:14:22 2010
From: marty at akamai.com (Martin Hannigan)
Date: Thu, 01 Jul 2010 16:14:22 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
 Use of "reserved" address space)
In-Reply-To: <AANLkTin7zIQhOJIqW7ZEVm6lm62_sVk1c4Z5K4Lcvl4w@mail.gmail.com>
Message-ID: <C8526F5E.8093%marty@akamai.com>




On 7/1/10 4:00 PM, "William Herrin" <bill at herrin.us> wrote:

> On Thu, Jul 1, 2010 at 2:45 PM, John Curran <jcurran at arin.net> wrote:
>> You are absolutely correct with respect to the power of the Board
>> and ability of a single entity to potentially "capture" the organization
>> if they?were able to dominate an election at the last minute. ?This is
>> the type of potential risk that the Board considered when making the
>> recent changes in membership and voting.
> 
> Hi John,
> 
> I agree with the board's decision to do away with "anybody can vote
> with a $500 payment," for exactly the reasons you point out but I also
> agree with James Hess' comment:
> 
> ) The restrictions on membership are pretty darn offensive I would
> ) say...  organizations which are part  of the American RIR community
> ) which ARIN is supposed to serve but do not have resources directly
> ) allocated/assigned ARIN are arbitrarily  excluded from joining ARIN.
> 
> 3450 ISPs and 20 non-ISPs eligible to vote has had a lopsided effect
> on the folks selected for the board and the AC. Particularly the AC
> most of whom haven't, shall we say, reached the height of
> statesmanship achieved by the luminaries considered for the board.

[ snip ]

> I have no magic bullet for this problem. Voting systems are
> surprisingly hard to do well and fairly. But Scott wanted suggestions
> and one of my suggestions is: look for more ways to solve or mitigate
> this problem.



The nom-com would seem to be the place to point the microscope at, IMHO.

Best,

-M<




From bill at herrin.us  Thu Jul  1 16:46:54 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Jul 2010 16:46:54 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <AANLkTin7zIQhOJIqW7ZEVm6lm62_sVk1c4Z5K4Lcvl4w@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com> 
	<b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>
	<AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com> 
	<4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>
	<AANLkTin7zIQhOJIqW7ZEVm6lm62_sVk1c4Z5K4Lcvl4w@mail.gmail.com>
Message-ID: <AANLkTikRFiuw5bSkW2oSlnx8-U7syxH3Arekg97qe81K@mail.gmail.com>

On Thu, Jul 1, 2010 at 4:00 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Jul 1, 2010 at 2:45 PM, John Curran <jcurran at arin.net> wrote:
> ) The restrictions on membership are pretty darn offensive I would
> ) say... ?organizations which are part ?of the American RIR community
> ) which ARIN is supposed to serve but do not have resources directly
> ) allocated/assigned ARIN are arbitrarily ?excluded from joining ARIN.
>
> 3450 ISPs and 20 non-ISPs eligible to vote has had a lopsided effect
> on the folks selected for the board and the AC. Particularly the AC
> most of whom haven't, shall we say, reached the height of
> statesmanship achieved by the luminaries considered for the board.

You know, that came out really badly. Since I consider the folks on
the AC to be good, respectable, talented individuals, let me attempt
to rephrase it...

Everything else being equal, the current election process selects for
individuals who tend to lean towards ISP points of view. No surprise -
few but ISP reps are voting. Unfortunately, what's good for ISPs is
not always good for the rest of the address-using community. It would
be nice if the process did not introduce that bias... or introduced a
second factor with an opposing bias.


I dunno. Would it be possible/practical/useful to have some sort of
at-large member of the board and/or AC intentionally elected through
an alternate process that tries to be highly inclusive of end users
whose role is to serve as a check against ISP-leaning groupthink?

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  Thu Jul  1 15:34:03 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Jul 2010 12:34:03 -0700
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
Message-ID: <0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>


On Jul 1, 2010, at 8:17 AM, William Herrin wrote:

> On Thu, Jul 1, 2010 at 6:21 AM, John Curran <jcurran at arin.net> wrote:
>> I have the statistics from the time of the membership change
>> (Dec 2009) and can provide those numbers to help clarify:
>> 
>>   Approximately 3450 Members who were ISPs
>> 
>>   Approximately   20 Members who were End-Users (with an additional
>>                      1440 End-User organizations with RSA who have
>>                      had not opted for membership at that time)
> 
> Putting these numbers in perspective:
> 
> 3450 non-trivial ISPs in the ARIN region, all eligible to vote on who
> sits on the AC or board
> 
> 20 non-ISPs in the ARIN region eligible to vote on who sites on the AC or board.
> 
> Unknown number of organizations with non-trivial address holdings (/27
> or larger). either directly from ARIN or via their ISP in the ARIN
> region  Lower bound likely to be at least 100,000.
> 
> Non-ISP interests represented during board and AC elections: fraction
> of a percent and not a large fraction.
> 
While you make this accusation, I can point to several members of the board
and AC who are not employed by ISPs. I, myself, was not employed by an ISP
when I was elected.

I think that the balance on PPML and at the public policy meetings is somewhat
different from this voting block as you characterize it as well. 

I would like to see the AC elected by a broader community, but, I don't think that
the current process is particularly under-representing end users.

Owen



From warren at wholesaleinternet.com  Thu Jul  1 15:58:21 2010
From: warren at wholesaleinternet.com (Warren Wholesale.com)
Date: Thu, 1 Jul 2010 14:58:21 -0500
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>
	<4C2B6362.4040709@gmail.com>	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>	<b7234ebe2497c5b89b4f6c1137cc546e4c2cd2e9@jcc.com>	<AANLkTikxKzflg7uT6HUL-gr8l72OPRk9JGyGLgST2dG-@mail.gmail.com>
	<4BFD9CAB-4265-43D9-8A08-2473B1BB4BBD@arin.net>
Message-ID: <093301cb1957$c3e5fd70$4bb1f850$@com>

Last year I posted a thread on here about how an organization with
significant enough financial desire (along with a large swatch of IP
addresses) could forestall the migration to ipv6.  Unfortunately, I was
soundly rebuffed by people calling me paranoid. One person [privately]
called me a troll and threatened to report me to the list-police.

 

It is in my opinion a foregone conclusion that we will be dual-stacking for
the foreseeable future and that requires a continued supply of IPv4
addresses.  That puts current resource holders in a desirable position and
non-resource holders in a non-desirable position.  Right now it?s all fun
and games because everyone can get v4 addresses.  Once the resource is no
longer cheap, this is going to be an entirely different ballgame.  

 

With the impending IPv4 exhaustion I think ARIN changing the voting policy
was the right move.  We need more policies like that.

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of John Curran
Sent: Thursday, July 01, 2010 1:46 PM
To: William Herrin
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Future pressures on the ARIN policy process (Was:
Use of "reserved" address space)

 

On Jul 1, 2010, at 2:29 PM, "William Herrin" <bill at herrin.us> wrote:


That's the point. Hand-pick the board and you can ram through nearly
anything you want, even if it has a significant downside for ARIN
participants who aren't you. There are some limits in place, but
little that isn't readily skirted with a simple majority vote of board
members. Certainly nothing of the "checks and balances" variety built
down in the portions of ARIN's structure that are immutable.

Things like the board members not drafting policies... the board can
change that with a simple majority vote.

I'm also not entirely sure how ARIN went about changing "those who pay
$500 are eligible to vote" to "those who pay and hold resources." Was
voting eligibility also decided with a vote of the board? If a process
can change it one way, the same process can change it another.

 

You are absolutely correct with respect to the power of the Board

and ability of a single entity to potentially "capture" the organization 

if they were able to dominate an election at the last minute.  This is

the type of potential risk that the Board considered when making the

recent changes in membership and voting.





/John





John Curran

President and CEO

ARIN

  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 7142 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100701/a2919eb0/attachment.bin>

From bill at herrin.us  Thu Jul  1 18:04:11 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 1 Jul 2010 18:04:11 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com> 
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
Message-ID: <AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>

On Thu, Jul 1, 2010 at 3:34 PM, Owen DeLong <owen at delong.com> wrote:
> On Jul 1, 2010, at 8:17 AM, William Herrin wrote:
>> 3450 non-trivial ISPs in the ARIN region, all eligible to vote on who
>> sits on the AC or board
>>
>> 20 non-ISPs in the ARIN region eligible to vote on who sites on the AC or board.
>>
>> Unknown number of organizations with non-trivial address holdings (/27
>> or larger). either directly from ARIN or via their ISP in the ARIN
>> region ?Lower bound likely to be at least 100,000.
>>
>> Non-ISP interests represented during board and AC elections: fraction
>> of a percent and not a large fraction.
>
> While you make this accusation, I can point to several members of the board
> and AC who are not employed by ISPs. I, myself, was not employed by an ISP
> when I was elected.

Which says a lot about the integrity of the people involved in the
process but not a lot about the integrity of the process itself.


> I think that the balance on PPML and at the public policy meetings is somewhat
> different from this voting block as you characterize it as well.

I didn't characterize the balance of people on PPML or at the meetings
at all. I spoke only to the balance of folks voting in the elections
for AC and the board.

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 mysidia at gmail.com  Thu Jul  1 19:34:14 2010
From: mysidia at gmail.com (James Hess)
Date: Thu, 1 Jul 2010 18:34:14 -0500
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
Message-ID: <AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>

On Thu, Jul 1, 2010 at 5:04 PM, William Herrin <bill at herrin.us> wrote:

Adoption 2010-2 may help this.  But the burden of renumbering is high.
I don't think end users should have to renumber their /24 to a direct
/24 under 2010-2,
just to become general ARIN members.
It will also be impossible after IPv4 exhaustion,  unless they will
adopt IPv6 and qualify
for direct assigned IPv6 resources under a similar policy.


> I didn't characterize the balance of people on PPML or at the meetings
> at all. I spoke only to the balance of folks voting in the elections
> for AC and the board.

In regards to this notion that  non-voting orgs can participate in the
policy development process. It's true that they can participate in the
discussion.   However, the AC  oversee this process.    Any
organization that cannot participate in the elections is not really
_fully_ able to participate.

In theory, in the worst case, the AC or the Board could just ignore or
interpret the results of the discussion however best suited the people
who elected them.   The  resource holders with no vote have no way of
eventually making sure their interests are represented fairly in AC's
or board's discussions.  I would say they are disenfranchised from
open participation in the PDP process, despite their ability to
"discuss".

Surely  less-destructive  anti-takeover measures could be conceived...

ARIN could let resource holders who have been SWIP'ed  resources participate,
or allow them to have voting rights after being a member of  ARIN for  X years,
holding delegated resources for Y years,   or attending Z number of
past ARIN meetings,  providing they can show proof of their
eligibility.

That is based on the assumption that any attempt to  "takeover ARIN"
after IPv4  exhaustion
would not likely to be attempted if it would take years to do so.

I am not so sure a takeover scheme is even impossible with the current
limitations.
If the financial incentive is sufficient,  bad players  could  be
setting up shell organizations,  and apply for the least-expensive
resource possible  (AS numbers).

If there were more  _legitimate_  members,   that would be harder if
not impossible.
What could be the cost to create a few thousand organizations,   if an
org stands to improve profitability by tens of millions  by
influencing the outcome of  ARIN  board elections?


> Regards,
> Bill Herrin
--
-M


From owen at delong.com  Thu Jul  1 20:09:27 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Jul 2010 17:09:27 -0700
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
	<AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
Message-ID: <1BD98750-9AB1-43D8-ADCC-0372D26F29BC@delong.com>


On Jul 1, 2010, at 4:34 PM, James Hess wrote:

> On Thu, Jul 1, 2010 at 5:04 PM, William Herrin <bill at herrin.us> wrote:
> 
> Adoption 2010-2 may help this.  But the burden of renumbering is high.
> I don't think end users should have to renumber their /24 to a direct
> /24 under 2010-2,
> just to become general ARIN members.
> It will also be impossible after IPv4 exhaustion,  unless they will
> adopt IPv6 and qualify
> for direct assigned IPv6 resources under a similar policy.
> 
If they qualify under 2010-2, they automatically qualify for IPv6 end-user
assignment under current policy, whether they have the IPv4 /24 or not.

> 
>> I didn't characterize the balance of people on PPML or at the meetings
>> at all. I spoke only to the balance of folks voting in the elections
>> for AC and the board.
> 
> In regards to this notion that  non-voting orgs can participate in the
> policy development process. It's true that they can participate in the
> discussion.   However, the AC  oversee this process.    Any
> organization that cannot participate in the elections is not really
> _fully_ able to participate.
> 
I agree.  I think it would be better if the AC were elected by the broader
community. The board should, IMHO, still be elected by the membership.

> In theory, in the worst case, the AC or the Board could just ignore or
> interpret the results of the discussion however best suited the people
> who elected them.   The  resource holders with no vote have no way of
> eventually making sure their interests are represented fairly in AC's
> or board's discussions.  I would say they are disenfranchised from
> open participation in the PDP process, despite their ability to
> "discuss".
> 
In all cases, the decision of the AC at least can be petitioned by a relatively
small number of constituents, even if they are not members. I think this does
provide some level of safety valve. It may not be fool-proof, but, I think it is
at least of some help.

Owen



From marty at akamai.com  Thu Jul  1 20:45:35 2010
From: marty at akamai.com (Martin Hannigan)
Date: Thu, 01 Jul 2010 20:45:35 -0400
Subject: [arin-ppml] Set aside policy?
Message-ID: <C852AEEF.810C%marty@akamai.com>




Folks,

Is there _anything_ that people would consider reasonable for a set-aside
policy? I'm thinking about policy for transition infrastructure and wanted
to see if anyone else is thinking about this.

Best,

-M<



From scottleibrand at gmail.com  Thu Jul  1 20:48:11 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 01 Jul 2010 17:48:11 -0700
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C852AEEF.810C%marty@akamai.com>
References: <C852AEEF.810C%marty@akamai.com>
Message-ID: <4C2D374B.2010802@gmail.com>

On Thu 7/1/2010 5:45 PM, marty at akamai.com wrote:
> Is there _anything_ that people would consider reasonable for a set-aside
> policy? I'm thinking about policy for transition infrastructure and wanted
> to see if anyone else is thinking about this.
>    

How much space are you thinking about reserving?

-Scott


From farmer at umn.edu  Thu Jul  1 21:03:41 2010
From: farmer at umn.edu (David Farmer)
Date: Thu, 01 Jul 2010 20:03:41 -0500
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C852AEEF.810C%marty@akamai.com>
References: <C852AEEF.810C%marty@akamai.com>
Message-ID: <4C2D3AED.9000507@umn.edu>

An IPv4 set-aside for IPv6 transition infrastructure I assume.

How would this be different from NRPM 4.10?

Or do you mean at the IANA level and in relationship to PP#115 you are 
working on?

marty at akamai.com wrote:
> 
> 
> Folks,
> 
> Is there _anything_ that people would consider reasonable for a set-aside
> policy? I'm thinking about policy for transition infrastructure and wanted
> to see if anyone else is thinking about this.
> 
> 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.


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


From owen at delong.com  Thu Jul  1 21:27:46 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 1 Jul 2010 18:27:46 -0700
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C852AEEF.810C%marty@akamai.com>
References: <C852AEEF.810C%marty@akamai.com>
Message-ID: <C88D44E4-C5E4-450B-8EEE-6F0DB6F24CA5@delong.com>

Do you mean beyond 4.10 or are you looking to change 4.10 in some way?

Have you looked at my recent proposal for additional limitations on the space
reserved under 4.10?

Owen

For reference:

4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block.
In order to receive an allocation or assignment under this policy:
the applicant may not have received resources under this policy in the preceding six months;
previous allocations/assignments under this policy must continue to meet the justification requirements of this policy;
previous allocations/assignments under this policy must meet the utilization requirements of end user assignments;
the applicant must demonstrate that no other allocations or assignments will meet this need;
on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations.


On Jul 1, 2010, at 5:45 PM, Martin Hannigan wrote:

> 
> 
> 
> Folks,
> 
> Is there _anything_ that people would consider reasonable for a set-aside
> policy? I'm thinking about policy for transition infrastructure and wanted
> to see if anyone else is thinking about this.
> 
> 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.

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

From marty at akamai.com  Fri Jul  2 00:33:14 2010
From: marty at akamai.com (Martin Hannigan)
Date: Fri, 02 Jul 2010 00:33:14 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C88D44E4-C5E4-450B-8EEE-6F0DB6F24CA5@delong.com>
Message-ID: <C852E44A.8127%marty@akamai.com>




I?m aware of 4.10 and your proposal.  I?m not thinking about NAT devices or
small numbers of hosts as transition infrastructure. I?m interesting in
other ideas. Thanks for pointing everyone at these though.


Best,

-M<


On 7/1/10 9:27 PM, "Owen DeLong" <owen at delong.com> wrote:

> Do you mean beyond 4.10 or are you looking to change 4.10 in some way?
> 
> Have you looked at my recent proposal for additional limitations on the space
> reserved under 4.10?
> 
> Owen
> 
> For reference:
> 
> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10
> IPv4 block will be set aside and dedicated to facilitate IPv6 deployment.
> Allocations and assignments from this block must be justified by immediate
> IPv6 deployment requirements. Examples of such needs include: IPv4 addresses
> for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff
> will use their discretion when evaluating justifications.
> This block will be subject to a minimum size allocation of /28 and a maximum
> size allocation of /24. ARIN should use sparse allocation when possible within
> that /10 block.
> In order to receive an allocation or assignment under this policy:
> 1. the applicant may not have received resources under this policy in the
> preceding six months;
> 2. previous allocations/assignments under this policy must continue to meet
> the justification requirements of this policy;
> 3. previous allocations/assignments under this policy must meet the
> utilization requirements of end user assignments;
> 4. the applicant must demonstrate that no other allocations or assignments
> will meet this need;
> 5. on subsequent allocation under this policy, ARIN staff may require
> applicants to renumber out of previously allocated / assigned space under this
> policy in order to minimize non-contiguous allocations.
> 
> 
> On Jul 1, 2010, at 5:45 PM, Martin Hannigan wrote:
> 
>> 
>> 
>> 
>> Folks,
>> 
>> Is there _anything_ that people would consider reasonable for a set-aside
>> policy? I'm thinking about policy for transition infrastructure and wanted
>> to see if anyone else is thinking about this.
>> 
>> 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.
> 
> 

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

From lear at cisco.com  Fri Jul  2 05:36:40 2010
From: lear at cisco.com (Eliot Lear)
Date: Fri, 02 Jul 2010 11:36:40 +0200
Subject: [arin-ppml] ARIN and the ITU
In-Reply-To: <4C2B90AE.8060609@ipinc.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>	<75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu>
	<4C2B90AE.8060609@ipinc.net>
Message-ID: <4C2DB328.8010805@cisco.com>

 Ted,

On 6/30/10 8:45 PM, Ted Mittelstaedt wrote:
> I have to agree mostly with Milton here, also I'll point out that
> recently ARIN joined the ITU and as the ITU is an agency of the
> United Nations, ARIN has in some ways lost it's independence
> from the government.
I don't know of a single process change that has occurred because ARIN
has joined the ITU as a sector member.  Moreover, by doing so, ARIN has
gained a voice within the Union.  So have three of the four other RIRs. 
It's important that ARIN and the other RIRs make use of that voice to
explain how the Internet works.  Absent that voice, a void has existed
that has been filled with misinformation.

Eliot



From marty at akamai.com  Fri Jul  2 10:11:47 2010
From: marty at akamai.com (Martin Hannigan)
Date: Fri, 02 Jul 2010 10:11:47 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <4C2D374B.2010802@gmail.com>
Message-ID: <C8536BE3.8252%marty@akamai.com>




On 7/1/10 8:48 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

> On Thu 7/1/2010 5:45 PM, marty at akamai.com wrote:
>> Is there _anything_ that people would consider reasonable for a set-aside
>> policy? I'm thinking about policy for transition infrastructure and wanted
>> to see if anyone else is thinking about this.
>>    
> 
> How much space are you thinking about reserving?


That's a premature question IMHO. The concept of what transition
infrastructure "TI" is needs to be hammered out. Probably the hardest part
of any set-aside policy that will make an impact.


Best,

Marty



From schiller at uu.net  Fri Jul  2 10:49:18 2010
From: schiller at uu.net (Jason Schiller)
Date: Fri, 02 Jul 2010 10:49:18 -0400 (EDT)
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C8536BE3.8252%marty@akamai.com>
References: <C8536BE3.8252%marty@akamai.com>
Message-ID: <alpine.GSO.2.00.1007021039200.2299@peermon.argfrp.us.uu.net>

Marty,

In the very near future people will be forced into building IPv6-only 
networks.  The question is how will these IPv6-only networks reach the 
content that is only available on the IPv4 Internet.

Personally I don't think the IPv4/IPv6 Carrier Grade NAT solution is going 
to work well.  I suspect it will have problems with scaling, problems with 
being easily supported, problems with providing good CALEA support, 
interfere with geo-location, and be a big target (with lots of collateral 
damage) for DoS attacks.

The next less bad solution is to offer exactly one IPv4 address to each 
IPv6-only network.  This will allow them to stand-up their own (read at 
the customer premise) IPv4/IPv6 NAT.  This does not have the same scaling, 
CALEA, and support issues, and has the other problems to a lesser extent.  
Hopefully, these addresses are part of an aggregate and people are not 
attempting to get IPv4 PI /32s routed on the Internet.

While this level of rationing will save lots of addresses from business 
customers, it will be business as usual for most consumer customers.  I'm 
not sure what to think of that.

There are some other questions here.  If a business customer has multiple 
connections and a need to do traffic engineering, could they get one IPv4 
address per connection?  What if they are IPv6 multi-homed, will they need 
one globally unique IPv4 address for Router ID on each eBGP speaking 
router?  What if for reasons of scale they need to offload the NAT 
function to a purpose-build box sitting directly behind their router, in 
that case can they get enough IPv4 addresses for their router and their 
NAT box?

The bigger question is what do you consider IPv6 critical mass, for 
example when 80% of Internet facing services support IPv6?  And how long 
until that occurs, for example 5 years?  (pick whatever numbers make sense 
to the community)  In that amount of time, how many new IPv6-only networks 
will you activate?  

Unfortunately this line of logic may lead one to conclude that the ARIN 
community needs more than a single /8.  In that case is it wise to have 
an ARIN policy that allows people to get "Transition Space" for this 
purpose only now, before we whittle the IANA Free Pool down the last 5 /8s 
that are under the "Global Policy for the Allocation of the Remaining 
IPv4 Address Space"?  Note that this will greatly accelerate the depletion 
date.

__Jason



==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Fri, 2 Jul 2010, Martin Hannigan wrote:

|Date: Fri, 02 Jul 2010 10:11:47 -0400
|From: Martin Hannigan <marty at akamai.com>, marty at akamai.com
|To: Scott Leibrand <scottleibrand at gmail.com>, arin-ppml at arin.net
|Subject: Re: [arin-ppml] Set aside policy?
|
|
|
|
|On 7/1/10 8:48 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
|
|> On Thu 7/1/2010 5:45 PM, marty at akamai.com wrote:
|>> Is there _anything_ that people would consider reasonable for a set-aside
|>> policy? I'm thinking about policy for transition infrastructure and wanted
|>> to see if anyone else is thinking about this.
|>>    
|> 
|> How much space are you thinking about reserving?
|
|
|That's a premature question IMHO. The concept of what transition
|infrastructure "TI" is needs to be hammered out. Probably the hardest part
|of any set-aside policy that will make an impact.
|
|
|Best,
|
|Marty
|
|_______________________________________________
|PPML
|You are receiving this message because you are subscribed to
|the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
|Unsubscribe or manage your mailing list subscription at:
|http://lists.arin.net/mailman/listinfo/arin-ppml
|Please contact info at arin.net if you experience any issues.
|


From farmer at umn.edu  Fri Jul  2 11:13:14 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 02 Jul 2010 10:13:14 -0500
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C8536BE3.8252%marty@akamai.com>
References: <C8536BE3.8252%marty@akamai.com>
Message-ID: <4C2E020A.7060506@umn.edu>

marty at akamai.com wrote:
> 
> 
> On 7/1/10 8:48 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
> 
>> On Thu 7/1/2010 5:45 PM, marty at akamai.com wrote:
>>> Is there _anything_ that people would consider reasonable for a set-aside
>>> policy? I'm thinking about policy for transition infrastructure and wanted
>>> to see if anyone else is thinking about this.
>>>    
>> How much space are you thinking about reserving?
> 
> 
> That's a premature question IMHO. The concept of what transition
> infrastructure "TI" is needs to be hammered out. Probably the hardest part
> of any set-aside policy that will make an impact.

Are you thinking of a future/unknown TI technology or solution?

Or, do you have a particular TI technology or solution in mind?

Personally to some extent I could support either. However, I suspect 
there will be a inverse ratio between the level of vapor-ware of the TI 
technology or solution and the level of consensus that could be achieved 
within the community.

Also the more speculative the TI technology or solution, the more likely 
a policy backstop would be needed.  If we set-aside space for a unknown 
TI technology or solution what happens if one never materializes?  Or, 
similarly if it is a known TI technology or solution what happens if it 
isn't adopted?  How long should we wait for a TI technology or solution 
to materialize or to be adopted? What happens to the IPv4 space after 
that time?



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


From jcurran at arin.net  Fri Jul  2 16:18:26 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 2 Jul 2010 16:18:26 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process
	(Was:	Use of "reserved" address space)
In-Reply-To: <1BD98750-9AB1-43D8-ADCC-0372D26F29BC@delong.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
	<AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
	<1BD98750-9AB1-43D8-ADCC-0372D26F29BC@delong.com>
Message-ID: <5A7030EF-E4D2-4CED-B6AA-935DEA58015A@arin.net>

On Jul 1, 2010, at 8:09 PM, Owen DeLong <owen at delong.com> wrote:

> I agree.  I think it would be better if the AC were elected by the broader
> community. The board should, IMHO, still be elected by the membership.

I see distinct advantages (better representation) and disadvantages (greatly increased risk of capture as a means of getting policy made), but would like to take this thread in a slightly different direction for a moment. 

This is the type of question which might be interesting to provide to perspective Board candidates to see their views on the matter. There are probably a few other similar ones in areas such as fees and IPv6 promotion.   However, we have received very little community input for the NomCom on questions to be put on the candidate applications.

I'd ask that folks spend some time thinking about this, and send questions which will help you get a Board and AC which best serves ARIN's mission.   The deadline for question submission shall be extended briefly to allow more time for input.

Thanks!
/John

John Curran
President and CEO
ARIN 

From info at arin.net  Fri Jul  2 16:26:18 2010
From: info at arin.net (Member Services)
Date: Fri, 02 Jul 2010 16:26:18 -0400
Subject: [arin-ppml] Call for Nominee Questions - Extended Until Tuesday at
	1pm
Message-ID: <4C2E4B6A.2090508@arin.net>

(Apologies to those subscribed to arin-announce and ppml for duplicates)

In October 2010 ARIN will hold elections for open seats on the ARIN
Board of Trustees, ARIN Advisory Council, and NRO Number Council. To
prepare for these elections we are opening the floor for Community "Ask
the Nominee" questions!

If you have questions on relevant policy issues and challenges facing
ARIN that you'd like candidates to answer, send them to info at arin.net no
later than 1pm July 6, 2010.

Please indicate if your question is directed to candidates for the
Board, Advisory Council, NRO Number Council or any combination of the three.

The Nomination Committee (NomCom) will determine the final list and
phrasing of all questions. The NomCom may solicit additional input from
eligible voters on the final set of questions for Board, Advisory
Council, and NRO Number Council nominees.

ARIN will publish candidate bios and their questionnaire responses when
the slate of candidates is announced. The current questionnaires may be
viewed at:

Advisory Council:

https://www.arin.net/participate/elections/ac.html#accv

Board:
https://www.arin.net/participate/elections/board.html#botcv

NRO Number Council:

https://www.arin.net/participate/elections/nronumbercouncil.html#nccv

The 2010 election schedule is available on the ARIN website at:
https://www.arin.net/participate/elections/elec_calendar.html

The page includes links to other election-related information. The Call
for Nominations will be issued on 12 July.

We look forward to your input. If you have any questions concerning the
election process please contact us at info at arin.net or submit your
question through your web account.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers (ARIN)



From cgrundemann at gmail.com  Fri Jul  2 17:56:53 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 2 Jul 2010 15:56:53 -0600
Subject: [arin-ppml] ARIN and the ITU
In-Reply-To: <AANLkTikq7s91LGD3Knf19--ggR_hKXkXRPTqIZujwAZz@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>
	<75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu>
	<4C2B90AE.8060609@ipinc.net> <4C2DB328.8010805@cisco.com>
	<AANLkTikq7s91LGD3Knf19--ggR_hKXkXRPTqIZujwAZz@mail.gmail.com>
Message-ID: <AANLkTinUNVUNz33IWp5b8KHRqE80mLBVzI5Umx23C56a@mail.gmail.com>

+1

ARINs involvement in the ITU does not equal government control of ARIN, it
may however equal ARIN influence of government.

~Chris

My Android sent this message.

On Jul 2, 2010 2:37 AM, "Eliot Lear" <lear at cisco.com> wrote:

 Ted,

On 6/30/10 8:45 PM, Ted Mittelstaedt wrote:
> I have to agree mostly with Milton here, also I'll point out that
> recently ARIN joined the ITU and as the ITU is an agency of the
> United Nations, ARIN has in some ways lost it's independence
> from the government.
I don't know of a single process change that has occurred because ARIN
has joined the ITU as a sector member.  Moreover, by doing so, ARIN has
gained a voice within the Union.  So have three of the four other RIRs.
It's important that ARIN and the other RIRs make use of that voice to
explain how the Internet works.  Absent that voice, a void has existed
that has been filled with misinformation.

Eliot

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100702/be1644ce/attachment.htm>

From tedm at ipinc.net  Fri Jul  2 18:38:48 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 02 Jul 2010 15:38:48 -0700
Subject: [arin-ppml] ARIN and the ITU
In-Reply-To: <AANLkTinUNVUNz33IWp5b8KHRqE80mLBVzI5Umx23C56a@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>	<75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu>	<4C2B90AE.8060609@ipinc.net>	<4C2DB328.8010805@cisco.com>	<AANLkTikq7s91LGD3Knf19--ggR_hKXkXRPTqIZujwAZz@mail.gmail.com>
	<AANLkTinUNVUNz33IWp5b8KHRqE80mLBVzI5Umx23C56a@mail.gmail.com>
Message-ID: <4C2E6A78.5020907@ipinc.net>

Chris,

Influence in government is a two way street.

I realize that if ITU doesn't understand IP address allocation that
they cannot exert any kind of control at all, direct or indirect.  But
by educating them, "gaining a voice in the union" as it were, that
is also an invitation for them to "gain a voice with us"

It's a two way street.  I know probably some of you don't believe
me or even understand what I'm talking about but just remember this
10 years from now because by then you will understand.

Quite a lot of "governance" these days is done this way.  For
example in the US do you seriously think that the Chinese Government's
opinions have absolutely no effect on what the US Government does?
When the US Government is currently essentially funded by the
Chinese?  Putting it another way, it isn't really necessary for
the Chinese to invade, occupy and control the United States.  They
already have the means to make the US Government do whatever they
want it to.

By opening relations with ITU, ARIN may think it's in the drivers
seat of that relationship now, but it won't stay that way.  Once
the ITU members are educated and understand, they are going to want
to inject their "perspective and experience" back into ARIN the same
way that ARIN wants to inject it's "perspective and experience"
into the ITU, now.

I'm not saying this is all bad.  ARIN needs to be part of the recognized
power structure in the world government or when things get tight then 
the global players are going to exert pressure on the existing 
recognized power structure to take over IP allocations from the RIRs. 
It is much better now for ARIN to get engaged with that crew so that 
when the screws get turned later on, the ITU will be supportive of ARIN 
and push back against the governments (who really only have their own 
national interests at heart) so that nobody does anything radical.  But, 
the downside is that when you get involved in their business,
they are going to get involved in your business.

I just find it very foolish of people to think that IP address
assignment is somehow "above the law" and not of interest to the
world's governments.  Trust me, if the RIRs had screwed up address
assignment the governments would have taken it over a long time
ago, probably under the auspices of the ITU.  That is exactly
what happened when the registrars screwed up with the DNS system, and 
WIPO stepped in and ordered ICANN to come up with the UDRP.  And 
nowadays ICANN won't do anything significant with the DNS system unless 
they go to WIPO first.

Ted

On 7/2/2010 2:56 PM, Chris Grundemann wrote:
> +1
>
> ARINs involvement in the ITU does not equal government control of ARIN, it
> may however equal ARIN influence of government.
>
> ~Chris
>
> My Android sent this message.
>
> On Jul 2, 2010 2:37 AM, "Eliot Lear"<lear at cisco.com>  wrote:
>
>   Ted,
>
> On 6/30/10 8:45 PM, Ted Mittelstaedt wrote:
>> I have to agree mostly with Milton here, also I'll point out that
>> recently ARIN joined the ITU and as the ITU is an agency of the
>> United Nations, ARIN has in some ways lost it's independence
>> from the government.
> I don't know of a single process change that has occurred because ARIN
> has joined the ITU as a sector member.  Moreover, by doing so, ARIN has
> gained a voice within the Union.  So have three of the four other RIRs.
> It's important that ARIN and the other RIRs make use of that voice to
> explain how the Internet works.  Absent that voice, a void has existed
> that has been filled with misinformation.
>
> Eliot
>
> _______________________________________________
> 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 owen at delong.com  Fri Jul  2 18:56:34 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 2 Jul 2010 15:56:34 -0700
Subject: [arin-ppml] ARIN and the ITU
In-Reply-To: <4C2E6A78.5020907@ipinc.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>	<20100630151528.A39D82B2131@mx5.roble.com>	<75822E125BCB994F8446858C4B19F0D705C7E16B18@SUEX07-MBX-04.ad.syr.edu>	<4C2B90AE.8060609@ipinc.net>	<4C2DB328.8010805@cisco.com>	<AANLkTikq7s91LGD3Knf19--ggR_hKXkXRPTqIZujwAZz@mail.gmail.com>
	<AANLkTinUNVUNz33IWp5b8KHRqE80mLBVzI5Umx23C56a@mail.gmail.com>
	<4C2E6A78.5020907@ipinc.net>
Message-ID: <E1B07198-B706-4C63-BE5B-D4B0604CF3B9@delong.com>


On Jul 2, 2010, at 3:38 PM, Ted Mittelstaedt wrote:

> Chris,
> 
> Influence in government is a two way street.
> 
> I realize that if ITU doesn't understand IP address allocation that
> they cannot exert any kind of control at all, direct or indirect.  But
> by educating them, "gaining a voice in the union" as it were, that
> is also an invitation for them to "gain a voice with us"
> 
You are very wrong in believing that the ITU cannot exert control
if they don't understand addressing. The ITU can exert control if
they THINK they understand addressing, whether they have any
real understanding or not.

I would much rather invite the ITU to speak as a single voice in the
ARIN crowd than have the ITU dictate to ARIN through the various
governments in the ARIN service region how address policy will be
administered.

> It's a two way street.  I know probably some of you don't believe
> me or even understand what I'm talking about but just remember this
> 10 years from now because by then you will understand.
> 
A two way street where we influence the ITU and ITU has some
(limited) influence on us is vastly preferable to a one-way street
where we have no influence on the ITU and the ITU decides
unilaterally to take control of global IP addressing policy.

> Quite a lot of "governance" these days is done this way.  For
> example in the US do you seriously think that the Chinese Government's
> opinions have absolutely no effect on what the US Government does?

Of course they have some effect, as should all of our global neighbors
be able to have some input into the process. Isolationism is a strategy
which has not worked particularly well in the past when some amount
of isolation was possible. It is an utter failure today when we are all
sharing an ever smaller ball of land and water with ever increasing
levels of connectedness amongst the various peoples.

> When the US Government is currently essentially funded by the
> Chinese?  Putting it another way, it isn't really necessary for
> the Chinese to invade, occupy and control the United States.  They
> already have the means to make the US Government do whatever they
> want it to.
> 
I wouldn't go quite that far. The economic situation between the US
and China is more one of mutually assured destruction than of
master/slave as you describe.

> By opening relations with ITU, ARIN may think it's in the drivers
> seat of that relationship now, but it won't stay that way.  Once
> the ITU members are educated and understand, they are going to want
> to inject their "perspective and experience" back into ARIN the same
> way that ARIN wants to inject it's "perspective and experience"
> into the ITU, now.
> 
If you haven't noticed, the latter was already happening, so, ARIN
has decided to join the ITU in response.

> I'm not saying this is all bad.  ARIN needs to be part of the recognized
> power structure in the world government or when things get tight then the global players are going to exert pressure on the existing recognized power structure to take over IP allocations from the RIRs. It is much better now for ARIN to get engaged with that crew so that when the screws get turned later on, the ITU will be supportive of ARIN and push back against the governments (who really only have their own national interests at heart) so that nobody does anything radical.  But, the downside is that when you get involved in their business,
> they are going to get involved in your business.
> 
I think you have the order of occurrence here reversed. You should
review the Kuala Lumpur session with the ITU at APNIC for some
examples if you need a reference point.

> I just find it very foolish of people to think that IP address
> assignment is somehow "above the law" and not of interest to the
> world's governments.  Trust me, if the RIRs had screwed up address
> assignment the governments would have taken it over a long time
> ago, probably under the auspices of the ITU.  That is exactly
> what happened when the registrars screwed up with the DNS system, and WIPO stepped in and ordered ICANN to come up with the UDRP.  And nowadays ICANN won't do anything significant with the DNS system unless they go to WIPO first.
> 
Some of us would argue that WIPO did more damage than even
the registrars, but, that's a bit off topic for this list.

Owen

> Ted
> 
> On 7/2/2010 2:56 PM, Chris Grundemann wrote:
>> +1
>> 
>> ARINs involvement in the ITU does not equal government control of ARIN, it
>> may however equal ARIN influence of government.
>> 
>> ~Chris
>> 
>> My Android sent this message.
>> 
>> On Jul 2, 2010 2:37 AM, "Eliot Lear"<lear at cisco.com>  wrote:
>> 
>>  Ted,
>> 
>> On 6/30/10 8:45 PM, Ted Mittelstaedt wrote:
>>> I have to agree mostly with Milton here, also I'll point out that
>>> recently ARIN joined the ITU and as the ITU is an agency of the
>>> United Nations, ARIN has in some ways lost it's independence
>>> from the government.
>> I don't know of a single process change that has occurred because ARIN
>> has joined the ITU as a sector member.  Moreover, by doing so, ARIN has
>> gained a voice within the Union.  So have three of the four other RIRs.
>> It's important that ARIN and the other RIRs make use of that voice to
>> explain how the Internet works.  Absent that voice, a void has existed
>> that has been filled with misinformation.
>> 
>> Eliot
>> 
>> _______________________________________________
>> 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 jcurran at arin.net  Sun Jul  4 06:43:23 2010
From: jcurran at arin.net (John Curran)
Date: Sun, 4 Jul 2010 06:43:23 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
 Use of "reserved" address space)
In-Reply-To: <AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com>	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
	<AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
Message-ID: <CA7202A1-A982-4C73-878E-3812855EE9E4@arin.net>

On Jul 1, 2010, at 7:34 PM, "James Hess" <mysidia at gmail.com> wrote:

> I am not so sure a takeover scheme is even impossible with the current
> limitations.
> If the financial incentive is sufficient,  bad players  could  be
> setting up shell organizations,  and apply for the least-expensive
> resource possible  (AS numbers).

James -

  Just to follow-up on this item: while it remains possible for an organization hostile to ARIN's mission to potentially capture the organization, it is far less likely due to the vetting process that is inherent to resource assignment when taking in combination with the requirement to be a member as of Jan 1 to vote in that years election.   If there were a sudden surge in shell registrations, it would have to occur in the previous year to affect the coming election, and we would have many months before October to confirm the issue and to consult with the community about what next steps (if any) would make an appropriate response.

/John

John Curran
President and CEO
ARIN   

From bill at herrin.us  Sun Jul  4 11:27:31 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 4 Jul 2010 11:27:31 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
	Use of "reserved" address space)
In-Reply-To: <5A7030EF-E4D2-4CED-B6AA-935DEA58015A@arin.net>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> 
	<4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com> 
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com> 
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com> 
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com> 
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com> 
	<AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com> 
	<1BD98750-9AB1-43D8-ADCC-0372D26F29BC@delong.com>
	<5A7030EF-E4D2-4CED-B6AA-935DEA58015A@arin.net>
Message-ID: <AANLkTilF5kTqjUAXBKLfA4YQs32i413URAgR5qkRS-6A@mail.gmail.com>

On Fri, Jul 2, 2010 at 4:18 PM, John Curran <jcurran at arin.net> wrote:
> I'd ask that folks spend some time thinking about this, and
> send questions which will help you get a Board and AC
> which best serves ARIN's mission. ? The deadline for question
> submission shall be extended briefly to allow more time for input.

Hi John,

What set of questions was asked last time?


> If there were a sudden surge in shell registrations, it would have to
> occur in the previous year to affect the coming election, and we
> would have many months before October to confirm the issue
> and to consult with the community about what next steps
> (if any) would make an appropriate response.

How many orgs voted in the last election?

Thanks,
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 jcurran at arin.net  Sun Jul  4 13:21:39 2010
From: jcurran at arin.net (John Curran)
Date: Sun, 4 Jul 2010 13:21:39 -0400
Subject: [arin-ppml] Future pressures on the ARIN policy process (Was:
 Use of "reserved" address space)
In-Reply-To: <AANLkTilF5kTqjUAXBKLfA4YQs32i413URAgR5qkRS-6A@mail.gmail.com>
References: <20100630053142.B71271CC0D@ptavv.es.net>
	<20100630151528.A39D82B2131@mx5.roble.com> <4C2B6362.4040709@gmail.com>
	<AANLkTinzqf1R7Tn4VC37ZV-XquViAF2YDtgYmHXhsZqI@mail.gmail.com>
	<f2c5be64a51816901919ef4e9b018e4f4c2b8ca3@jcc.com>
	<AANLkTinzConkfaurGv_t3MhdACpryXRI0QgAAZSBf84W@mail.gmail.com>
	<5d757333068a58fa9e54db3fe44c07b34c2b97c8@jcc.com>
	<AANLkTikuD4d8Ve2aA0LPvo_Zzmx-ZIQKm8vvsUjIFoah@mail.gmail.com>
	<D7381BE9-1CFA-4832-8AF9-6A6F620E9E0E@arin.net>
	<AANLkTilXdyKaOfQBjP20j6e0aIriMgL0TNp8pZiZCujg@mail.gmail.com>
	<0DA758EA-3335-43E7-83AD-AE7E13C63BF3@delong.com>
	<AANLkTind2GnBIvNAG-mgiM2rffDTd0dG9a-uLLu0Wnxm@mail.gmail.com>
	<AANLkTikObEL78Ps-vGsmfzL64xCuSYM9Q6MRV1P04HGK@mail.gmail.com>
	<1BD98750-9AB1-43D8-ADCC-0372D26F29BC@delong.com>
	<5A7030EF-E4D2-4CED-B6AA-935DEA58015A@arin.net>
	<AANLkTilF5kTqjUAXBKLfA4YQs32i413URAgR5qkRS-6A@mail.gmail.com>
Message-ID: <D74FE0E9-C5F1-4C70-A9E2-E92B3033B64E@arin.net>

On Jul 4, 2010, at 11:28 AM, "William Herrin" <bill at herrin.us<mailto:bill at herrin.us>> wrote:

On Fri, Jul 2, 2010 at 4:18 PM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:
The deadline for question submission shall be extended briefly to allow more time for input.

Hi John,

What set of questions was asked last time?

Bill -

I don't have access to the list of questions in my
present location, but I recommend that you submit
any and all questions of interest to the NomCom
since appearance on past nominee questionnaires
does not insure appearance on this years form...

How many orgs voted in the last election?

From <https://www.arin.net/announcements/2009/20091105.html:> https://www.arin.net/announcements/2009/20091105.html:


478 unique member organizations cast a ballot in the Board of Trustees election.
468 unique member organizations cast a ballot in the Advisory Council election.
492 unique member organizations cast a ballot in either the Board of Trustees or Advisory Council election.


I hope you find this information useful,

/John


John Curran

President and CEO

ARIN


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

From info at arin.net  Wed Jul  7 10:31:47 2010
From: info at arin.net (Member Services)
Date: Wed, 07 Jul 2010 10:31:47 -0400
Subject: [arin-ppml] Policy Proposal 117: Required Resource Reviews - text
	revised
Message-ID: <4C348FD3.9040208@arin.net>

The proposal originator submitted a revised version of the proposal.

Regards,

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

Summary of changes:

Reworded paragraph 10(b) to bring in line with staff recommendation and 
incorporate feedback from counsel.

Removed paragraph 10(c) to incorporate feedback from counsel

Renumbered 10(d) to 10(c)

Renumbered 10(e) to 10(d)

Added new 10(e) to accommodate staff feedback requesting clarification 
that 12.2(c) does not exempt most of these reviews.

--------Revised policy text-----------

Policy Proposal 117: Required Resource Reviews

Proposal Originator: Owen DeLong

Proposal Version: 2

Date: 6 July 2010

Proposal type: new

Policy term: permanent

Policy statement:

Replace the text "under sections 4-6" in section 12, paragraph 7 with 
"under paragraphs 12.4 through 12.6"

Add to section 12 the following text:

10.    Except as provided below, resource reviews are conducted at the
discretion of the ARIN staff.  In any of the circumstances mentioned 
below, a resource review must be initiated by ARIN staff:

a.    Report or discovery of an acquisition, merger, transfer, trade or
sale in which the infrastructure and customer base of a network move 
from one organization to another organization, but, the applicable IP 
resources are not transferred. In this case, the organization retaining 
the IP resources must be reviewed. The organization receiving the 
customers may also be reviewed at the discretion of the ARIN staff.

b.    Upon receipt by ARIN of one or more credible reports of fraud or
abuse of an IP address block. Abuse shall be defined as use of the block 
in violation of the RSA or other ARIN policies and shall not extend to 
include general reports of host conduct which are not within ARIN's scope.

c.    In the case where an organization wishes to act as recipient of
resources pursuant to a transfer under section 8.3, unless otherwise 
prohibited by paragraph 12.2(c).

d.    An organization which submits a request for additional resources
when more than 25% of their existing resources are obscured in SWIP or 
RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).

e.    Other than as specified in 12.10(c), paragraph 12.2(c) does not
exempt organizations from the reviews required under section 12.10.

Rationale:

The first change is a minor correction which improves clarity and 
consistency of the original policy without changing the meaning.

The addition of 12.10 (a) through (e) serves to create a set of 
circumstances under which a  resource review is required, rather than 
optional and entirely at ARIN staff discretion.

The majority of early comments on this proposal focused on 12.10 (e).
Mostly it was confusion about the exact ramifications. This section will 
cause ARIN to maintain greater scrutiny only in cases where a given ISP 
issues more than 25% of their total space to residential customers who 
wish to remain anonymous and receive network blocks of /29 or larger. To 
the best of my knowledge, there are not currently any ISPs which meet 
this criteria. Additionally, it would only apply that scrutiny to IPv4, 
and will not carry forward into IPv6 residential assignments.

This policy should improve the compliance verification of ARIN policies 
and may result in the improved reclamation of under-utilized IP address 
space. It should also serve as a deterrent to certain address hoarding 
tactics which have come to light in recent history.

Timetable for implementation: Immediately upon ratification by the Board






From marty at akamai.com  Wed Jul  7 13:46:04 2010
From: marty at akamai.com (Martin Hannigan)
Date: Wed, 07 Jul 2010 13:46:04 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <20100703090846.GA6371@vacation.karoshi.com.>
Message-ID: <C85A359C.89E1%marty@akamai.com>



The idea is something along the lines of (and this is _very_ high level)

-Eliminate facilitation and provide for transition "transition pool"
-Continued adherence to the RSA and policy
-Utilization increased to 90%
-Demonstrate that previous assignments won't meet their need
-Require addresses only be used for dual stack devices
-Raised minimum allocation unit
-30 month look forward reservations
-"take or pay"; quarterly applications based on forward estimates, and only
the fraction for that quarter allocated. No application or fail to meet
needs analysis for a quarter = return of that quarter allocation to pool
-must have received v6 allocation and must be in use
-additionally received v4 address to transition pool
-officer certification


Best,

-M<


On 7/3/10 5:08 AM, "bmanning at vacation.karoshi.com"
<bmanning at vacation.karoshi.com> wrote:

> On Fri, Jul 02, 2010 at 10:13:14AM -0500, David Farmer wrote:
>> marty at akamai.com wrote:
>>> 
>>> 
>>> On 7/1/10 8:48 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
>>> 
>>>> On Thu 7/1/2010 5:45 PM, marty at akamai.com wrote:
>>>>> Is there _anything_ that people would consider reasonable for a set-aside
>>>>> policy? I'm thinking about policy for transition infrastructure and
>>>>> wanted
>>>>> to see if anyone else is thinking about this.
>>>>>   
>>>> How much space are you thinking about reserving?
>>> 
>>> 
>> Are you thinking of a future/unknown TI technology or solution?
>> 
>> Or, do you have a particular TI technology or solution in mind?
>> 
> 
> back in the day,  Jon liked to use the 50% rule.
> only put 50% of the defined resource into play
> UNTIL there was a migration stratagy.
> 
> sometimes it worked, sometimes not.
> 
> if there is a reasonable chance that something new
> could emerge (routing, ad-hoc networks, IoT, research
> directions, etc..) that -don't- fit the current model
> of address allocation/assignment then it makes
> sense to hold some in reserve.  As I understand it,
> ARIN is ill equip'ed to manage such an environment since
> policy is bottom-up driven... the entrenched commodity
> markets have (kind of by design) captured the ARIN process.
> 
> if its just business as usual, then the justification for
> holding on to a "little bit" just in case, makes no sense
> at all.
> 
> --bill



From bill at herrin.us  Thu Jul  8 09:20:44 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 8 Jul 2010 09:20:44 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <alpine.GSO.2.00.1007021039200.2299@peermon.argfrp.us.uu.net>
References: <C8536BE3.8252%marty@akamai.com>
	<alpine.GSO.2.00.1007021039200.2299@peermon.argfrp.us.uu.net>
Message-ID: <AANLkTikjdLES965Ih_9sKp3diGO9LMswOx5Lsh3RDHcg@mail.gmail.com>

Personally, I like the idea of having a respectable-sized IPv4 block
set aside for the end -- not for "transition" but for "technically
reasonable requests for which no reasonable alternate solution other
than globally routable IPv4 addresses is possible."

There's a theory that says address markets will keep IPv4 addresses
available. People will follow the money. Given a dollar value for
addresses, use that offers insufficient earnings could compress by
CGNs, by IPv6 migrations or even by more careful review of existing
deployment.

If that theory pans out, it will still take some time after depletion
for the economic process to sort itself out and begin to work
smoothly. It would be nice, during that sort-out period, if
requirements that were technically impossible to meet with RFC1918,
IPv6 or other v4 conservation measures still had a pool from which
they could be met.

If that theory doesn't pan out, it would be nice if that pool was
available while we figure out how, in a regulatory fashion, to recover
addresses from existing trivial (NATable) use. As a community, we're
unlikely to seriously consider how to reclaim addresses until and
unless doing so becomes critical to the continued operation of the
Internet.

So, I favor a set-aside.



On Fri, Jul 2, 2010 at 10:49 AM, Jason Schiller <schiller at uu.net> wrote:
> In the very near future people will [in my opinion] be
> forced into building IPv6-only networks.

Jason,

I fixed your post.

Your opinion has merit and is shared by a number of folks on this and
network ops lists. However, at least one alternate view - that NAT
will extend the life of IPv4 indefinitely (or at least until IPv4's
use is no longer desirable) - holds similar merit.

In my opinion, people will follow the money. They usually do. Money
remains to be made in expanding your IPv4 network, by hook or by crook
even if that means employing more and different NAT. There's still
little money to be made in building an IPv6 network. Start talking to
the customer about future-proofing and they'll ask you to keep an eye
on it and let them know when the future actually arrives.

No price is too high if you can sell it for more. No cost is low
enough if you can't.


> Personally I don't think the IPv4/IPv6 Carrier Grade NAT solution is going
> to work well. ?I suspect it will have problems with scaling, problems with
> being easily supported, problems with providing good CALEA support,
> interfere with geo-location, and be a big target (with lots of collateral
> damage) for DoS attacks.

>From a holistic perspective, NAT doesn't seem to have a whole lot of
trouble with these issues in comparable deployments today. Think:
serving enterprises at a few hundred to a few thousand users at a
time. Or serving carefree users at hot spots and hotels.

I'm curious: what challenge do you envision for CGNs that isn't
already overcome in one of those scenarios?


> The next less bad solution is to offer exactly one IPv4 address to each
> IPv6-only network.  This will allow them to stand-up their own (read at
> the customer premise) IPv4/IPv6 NAT.

Last I heard, and please point me to the appropriate RFC if I'm
mistaken, there was was an IPv6 address range set aside to mean "IPv4
connection using IPv4 packets via IPv6 API" but no IPv6 address range
set aside to mean "IPv4 connectino in IPv6 packets to be NATed at the
IPv6/IPv4 border."

That makes IPv4/IPv6 NAT so much more complex than vanilla IPv4 NAT --
it has to implement a full DNS proxy resolver and pray that the DNS
packets take the same trip through the NAT as the data packets so that
the response to the AAAA query returns addresses the NAT will
consistently map to the right IPv4 addresses. Gonna wreak havoc with
DNSSEC too.

IPv4 CGNs are at least conceivable. I don't see first-generation v6 to
v4 NATs being viable in production deployments. It will take some
deployment of NAT-friendly client PC code that deals with A records in
a v6-only environment which will take some standards work despite the
portions of the IETF crowd that are bitterly opposed to any NAT in
IPv6. That puts us far past free pool depletion.

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 tme at multicasttech.com  Thu Jul  8 09:32:00 2010
From: tme at multicasttech.com (Marshall Eubanks)
Date: Thu, 8 Jul 2010 09:32:00 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <AANLkTikjdLES965Ih_9sKp3diGO9LMswOx5Lsh3RDHcg@mail.gmail.com>
References: <C8536BE3.8252%marty@akamai.com>
	<alpine.GSO.2.00.1007021039200.2299@peermon.argfrp.us.uu.net>
	<AANLkTikjdLES965Ih_9sKp3diGO9LMswOx5Lsh3RDHcg@mail.gmail.com>
Message-ID: <6579C282-9942-4406-996B-88B45622F84D@multicasttech.com>


On Jul 8, 2010, at 9:20 AM, William Herrin wrote:

> Personally, I like the idea of having a respectable-sized IPv4 block
> set aside for the end -- not for "transition" but for "technically
> reasonable requests for which no reasonable alternate solution other
> than globally routable IPv4 addresses is possible."
>
> There's a theory that says address markets will keep IPv4 addresses
> available. People will follow the money. Given a dollar value for
> addresses, use that offers insufficient earnings could compress by
> CGNs, by IPv6 migrations or even by more careful review of existing
> deployment.
>
> If that theory pans out, it will still take some time after depletion
> for the economic process to sort itself out and begin to work
> smoothly. It would be nice, during that sort-out period, if
> requirements that were technically impossible to meet with RFC1918,
> IPv6 or other v4 conservation measures still had a pool from which
> they could be met.
>
> If that theory doesn't pan out, it would be nice if that pool was
> available while we figure out how, in a regulatory fashion, to recover
> addresses from existing trivial (NATable) use. As a community, we're
> unlikely to seriously consider how to reclaim addresses until and
> unless doing so becomes critical to the continued operation of the
> Internet.
>
> So, I favor a set-aside.

I agree with this reasoning, and this conclusion.

Regards
Marshall


>
>
> On Fri, Jul 2, 2010 at 10:49 AM, Jason Schiller <schiller at uu.net>  
> wrote:
>> In the very near future people will [in my opinion] be
>> forced into building IPv6-only networks.
>
> Jason,
>
> I fixed your post.
>
> Your opinion has merit and is shared by a number of folks on this and
> network ops lists. However, at least one alternate view - that NAT
> will extend the life of IPv4 indefinitely (or at least until IPv4's
> use is no longer desirable) - holds similar merit.
>
> In my opinion, people will follow the money. They usually do. Money
> remains to be made in expanding your IPv4 network, by hook or by crook
> even if that means employing more and different NAT. There's still
> little money to be made in building an IPv6 network. Start talking to
> the customer about future-proofing and they'll ask you to keep an eye
> on it and let them know when the future actually arrives.
>
> No price is too high if you can sell it for more. No cost is low
> enough if you can't.
>
>
>> Personally I don't think the IPv4/IPv6 Carrier Grade NAT solution  
>> is going
>> to work well.  I suspect it will have problems with scaling,  
>> problems with
>> being easily supported, problems with providing good CALEA support,
>> interfere with geo-location, and be a big target (with lots of  
>> collateral
>> damage) for DoS attacks.
>
>> From a holistic perspective, NAT doesn't seem to have a whole lot of
> trouble with these issues in comparable deployments today. Think:
> serving enterprises at a few hundred to a few thousand users at a
> time. Or serving carefree users at hot spots and hotels.
>
> I'm curious: what challenge do you envision for CGNs that isn't
> already overcome in one of those scenarios?
>
>
>> The next less bad solution is to offer exactly one IPv4 address to  
>> each
>> IPv6-only network.  This will allow them to stand-up their own  
>> (read at
>> the customer premise) IPv4/IPv6 NAT.
>
> Last I heard, and please point me to the appropriate RFC if I'm
> mistaken, there was was an IPv6 address range set aside to mean "IPv4
> connection using IPv4 packets via IPv6 API" but no IPv6 address range
> set aside to mean "IPv4 connectino in IPv6 packets to be NATed at the
> IPv6/IPv4 border."
>
> That makes IPv4/IPv6 NAT so much more complex than vanilla IPv4 NAT --
> it has to implement a full DNS proxy resolver and pray that the DNS
> packets take the same trip through the NAT as the data packets so that
> the response to the AAAA query returns addresses the NAT will
> consistently map to the right IPv4 addresses. Gonna wreak havoc with
> DNSSEC too.
>
> IPv4 CGNs are at least conceivable. I don't see first-generation v6 to
> v4 NATs being viable in production deployments. It will take some
> deployment of NAT-friendly client PC code that deals with A records in
> a v6-only environment which will take some standards work despite the
> portions of the IETF crowd that are bitterly opposed to any NAT in
> IPv6. That puts us far past free pool depletion.
>
> 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 cgrundemann at gmail.com  Mon Jul 12 12:39:24 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 12 Jul 2010 10:39:24 -0600
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <C852E44A.8127%marty@akamai.com>
References: <C88D44E4-C5E4-450B-8EEE-6F0DB6F24CA5@delong.com>
	<C852E44A.8127%marty@akamai.com>
Message-ID: <AANLkTinl7JQcGfaFFEMHEubb-YyHS_pLhuIOElRykTnI@mail.gmail.com>

On Thu, Jul 1, 2010 at 22:33, Martin Hannigan <marty at akamai.com> wrote:
>
>
>
> I?m aware of 4.10 and your proposal. ?I?m not thinking about NAT devices or
> small numbers of hosts as transition infrastructure. I?m interesting in
> other ideas. Thanks for pointing everyone at these though.

Section 4.10 is not necessarily limited to NAT or small allocations,
or at least does not have to be. The title refers to facilitating IPv6
deployment, not NAT. The majority of the examples listed are NAT but
that is mostly (I assume) because no other transition methods have
been readily identified. What if we expanded it to a /9 of the last /8
and increased the maximum allocation a bit? Maybe drop the restriction
to once every 3 months? We could also add some language around
transition specifically but I am not sure that is absolutely necessary
to allow the uses you envision...

$.02
~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From marty at akamai.com  Mon Jul 12 13:53:19 2010
From: marty at akamai.com (Martin Hannigan)
Date: Mon, 12 Jul 2010 13:53:19 -0400
Subject: [arin-ppml] Set aside policy?
In-Reply-To: <AANLkTinl7JQcGfaFFEMHEubb-YyHS_pLhuIOElRykTnI@mail.gmail.com>
Message-ID: <C860CECF.95F9%marty@akamai.com>




On 7/12/10 12:39 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

> On Thu, Jul 1, 2010 at 22:33, Martin Hannigan <marty at akamai.com> wrote:
>> 
>> 
>> 
>> I?m aware of 4.10 and your proposal. ?I?m not thinking about NAT devices or
>> small numbers of hosts as transition infrastructure. I?m interesting in
>> other ideas. Thanks for pointing everyone at these though.
> 
> Section 4.10 is not necessarily limited to NAT or small allocations,
> or at least does not have to be. The title refers to facilitating IPv6
> deployment, not NAT. The majority of the examples listed are NAT but
> that is mostly (I assume) because no other transition methods have
> been readily identified. What if we expanded it to a /9 of the last /8
> and increased the maximum allocation a bit?


The last /8 and anything returned from the potential adoption of something
like this would be more beneficial in an reworked set-aside policy IMHO.

My rationale for opening this can of worms is cost. I'm trying to find a way
to help mitigate the cost of going to a market while trying to balance the
needs of the community and Internet.


Too soon for "oppose/support", but additional ideas welcomed if folks agree
that 4.10 does not go far enough. I have received some comments on the below
out of band. I'm looking for more here in PPML.

Best,

-M<



---snarf

3. Eligibility
 
An applicant will become eligible to receive IPv4 addresses from this
"pool"[better terminology TBD] when they meet the following requirements:

X1. Applicant will provide a written plan detailing how the addresses will
be used and on what devices.

X2. Previous allocations or assignments under this policy must continue to
meet the justification requirements of this policy.

X3. Must have applied for, been approved, received and be utilizing an ARIN
allocated IPv6 allocation or assignment.

X4. All allocations or assignments made under this policy must be
efficiently utilized to a rate of 80%.

X5. Applicant must demonstrate that no other allocations or assignments that
they have received will meet their requirements.

X6. Applicants must provide documentation that demonstrates that the
addresses received under this policy will be used only on dual stack devices
that will have both an IPv4 and IPv6 address that will both be reachable
natively. 

X7. Be in compliance with Section 4, Acceptable Use of Addresses.
 

4. Acceptable Use of Addresses


X1. A single IPv4 /32 for each layer 3 contiguous customer network to allow
for IPv4-IPv6 NAT which enables IPv4 connectivity for IPv6 only customer
networks. 

X2. A single IPv4 /32 for each interconnect for each multi-homed layer 3
contiguous customer network that requires traffic engineering.

X3. Customer networks that require stand-alone NAT devices to reach v4 and
v6 networks. 

X4. Loopback addresses for edge routers that have one or more connections to
transit providers 

X5. Address for point to point links between edge routers and their transit
providers 

X6. Point to point links between routers and public networks facing NAT
devices. 

X7. A /32 for routers in Greenfield networks that are dual stacked

X8. /32 for public facing name servers, NTP servers, SMTP servers and Web
servers which are dual stacked and reachable on IPv4 and IPv6 networks.
 

5. Reservation Forecasting
 
An applicant may provide ARIN with a thirty-month forecast of IPv4 address
need. ARIN will reserve the requested size in compliance with Section 2 and
3. When a reservation forecast is approved by ARIN, the applicant will then
be authorized to draw down from the forecast quarterly. Prior to requesting
reserved addresses, applicant will provide documentation to ARIN that they
have maintained utilization requirements for previous allocation. If
applicant fails to meet utilization requirements for two consecutive
quarters, ARIN will cancel the reservation and return unused addresses to
the pool. 

Example: 


Applicant applies to ARIN under this policy and submits a thirty-month
forecast requesting a /16. Using criteria established in the NRPM and this
policy, ARIN will determine if applicant is eligible and has need. If the
applicant meets the requirements for the allocation, they will be allocated
a /16 or equivalent. The applicant will then be allocated 1/10th of the
forecasted requirement in a CIDR block or equivalent number of IPv4
addresses. ARIN will round down allocations or assignments to the closest
CIDR single block. Rounding errors will be applied to the last allocation of
the last quarter of the thirty month period and allocated then.


>Maybe drop the restriction
> to once every 3 months? We could also add some language around
> transition specifically but I am not sure that is absolutely necessary
> to allow the uses you envision...
> 
> $.02
> ~Chris


Hi Chris,




From dave at connetrix.com  Mon Jul 12 13:49:11 2010
From: dave at connetrix.com (Dave Feuer)
Date: Mon, 12 Jul 2010 13:49:11 -0400
Subject: [arin-ppml] How bad is it really?
Message-ID: <004801cb21ea$89159cf0$9b40d6d0$@com>

While cleaning up some old DNS records (again) I took a look at some of our
old address space. 2  x /23s from 2 providers. I did a quick whois and both
are still pointing to us. One we have not used since early 2001 the other
since late 2004. I did some tests and one of them still routes to the last
hop before it hit us.

 

Then I took a look at the records for a client with a /22 that we managed
the DNS for. I don't know how long he has not had the IP space but it's been
at least 3 years and more likely closer to or over 4 years. Still pointing
to him (and his company no longer even exists) and still routing to the last
hop before him. 

 

How much space is out there and routed and going no place? Is there any way
to find out? It's more of a question to satisfy my curiosity but I think it
would be interesting to know.

 

-Dave

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

From tedm at ipinc.net  Mon Jul 12 14:38:05 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 12 Jul 2010 11:38:05 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <004801cb21ea$89159cf0$9b40d6d0$@com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
Message-ID: <4C3B610D.9040108@ipinc.net>

Hi Dave,

   Well, I think there is a lot of small space like this.  To give you 
an example take subnet 199.248.255.0/24, this was a direct assignment to
Leatherman Tools, which was a customer of ours over a decade ago.  They 
stopped using that space around 1999 but it was still routed to us.  I
used it periodically up until 2004 until we got our /19, but of course I
could not trade it in since we didn't own it.  I did mention it to the
ARIN hostmaster at that time.  So it's been abandonded for 6 years as 
well.   The last change on it's POC was from our former
admin who applied his e-mail address for his new employer to it (for 
some odd reason) but his new employer went bankrupt - and a domain 
speculator now has the POC e-mail address.

   Presumably, when ARIN fully has Section 3.6.1 of the NRPM implemented
the domain speculator who has the domain on the POC will fail to respond 
to the annual POC notification e-mail, and eventually ARIN will
notice the POC record is invalid.  At that time they might paper-mail
Leatherman Tools which is still a going concern, and still at the
address in the POC to confirm the POC.  ARIN does have the option
under the NRPM of marking the POC "completely and permanently abandoned 
or otherwise illegitimate"
but I don't know if they have developed an internal process yet to
make such designations or whether such a process includes phone calls
or paper mails or other mechanisms (like querying a looking glass, etc.)
Almost certainly such an internal process will prioritize the
invalid POC's tied to the largest allocations first.

But you can imagine what would happen even if ARIN were to paper-mail
Leatherman Tools on this one.  Most likely the admin at
Leatherman will not know what the heck the paper-mail is about and
will wrongly assume they are still using that subnet - and tell
ARIN not to do anything about it.  So that subnet will remain tied up,
virtually forever, or at least until Leatherman Tools goes out of
business, which isn't likely.  It would take a 20-minute phone call from
the ARIN hostmaster to the head MIS admin at Leatherman Tools to
explain what is going on and get permission to take back this
legacy resource, and that's only if the guy at Leatherman is clueful.

   Now, the interesting thing here is that in
the 3-4 minutes that it took for you to read this and comprehend it, the 
global RIR's have probably assigned 10 times the amount of IPv4
space.  In other words, it's likely that it would NEVER be 
cost-effective for ARIN to recover this space and reallocate it.
So ARIN probably will never get around to deeming this particular
/24 "permanently abandoned"  Hopefully though at least it eventually
will be marked unresponsive.  The truth is that this particular subnet
is my "canary in the coal mine" since I know it's history and I know
it should be marked unresponsive, when I see that happen I'll know
ARIN is implementing 3.6.1 fully.

   Keep in mind that Section 3.6.1 requires ARIN to publish a list of
invalid POCS, so we should have in a year or two a list of subnets
that are "ripe for mining" as they say.  I think that most of the
community believes that there isn't a lot of this space out
there.  I would also predict that if ARIN comes back with the
equivalent of 5-10 /8's worth of "invalid POC" space that there
will quickly be support for further IPv4 reclamation activities.

Ted


On 7/12/2010 10:49 AM, Dave Feuer wrote:
> While cleaning up some old DNS records (again) I took a look at some of our
> old address space. 2  x /23s from 2 providers. I did a quick whois and both
> are still pointing to us. One we have not used since early 2001 the other
> since late 2004. I did some tests and one of them still routes to the last
> hop before it hit us.
>
>
>
> Then I took a look at the records for a client with a /22 that we managed
> the DNS for. I don't know how long he has not had the IP space but it's been
> at least 3 years and more likely closer to or over 4 years. Still pointing
> to him (and his company no longer even exists) and still routing to the last
> hop before him.
>
>
>
> How much space is out there and routed and going no place? Is there any way
> to find out? It's more of a question to satisfy my curiosity but I think it
> would be interesting to know.
>
>
>
> -Dave
>
>
>
>
>
> _______________________________________________
> 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 dave at connetrix.com  Mon Jul 12 15:41:15 2010
From: dave at connetrix.com (Dave Feuer )
Date: Mon, 12 Jul 2010 15:41:15 -0400
Subject: [arin-ppml] How bad is it really?
Message-ID: <201007121541.AA35913900@connetrix.com>

Ted,

Yes, but the question I asked still remains, how much is really out there (and is there an easy way to find out)? Between the 2 of us we have just accounted for 9 /24s are there only those 9 (yeah I know) or is it 9000, 900000 or 90000000 or an even grater number (which I think). It's not like we can find them, take them back and combine them into a /8. So that point is moot. It's just more of a hmmmmmm I wonder question.  

-Dave 
---------- Original Message ----------------------------------
From: Ted Mittelstaedt <tedm at ipinc.net>
Date:  Mon, 12 Jul 2010 11:38:05 -0700

>Hi Dave,
>
>   Well, I think there is a lot of small space like this.  To give you 
>an example take subnet 199.248.255.0/24, this was a direct assignment to
>Leatherman Tools, which was a customer of ours over a decade ago.  They 
>stopped using that space around 1999 but it was still routed to us.  I
>used it periodically up until 2004 until we got our /19, but of course I
>could not trade it in since we didn't own it.  I did mention it to the
>ARIN hostmaster at that time.  So it's been abandonded for 6 years as 
>well.   The last change on it's POC was from our former
>admin who applied his e-mail address for his new employer to it (for 
>some odd reason) but his new employer went bankrupt - and a domain 
>speculator now has the POC e-mail address.
>
>   Presumably, when ARIN fully has Section 3.6.1 of the NRPM implemented
>the domain speculator who has the domain on the POC will fail to respond 
>to the annual POC notification e-mail, and eventually ARIN will
>notice the POC record is invalid.  At that time they might paper-mail
>Leatherman Tools which is still a going concern, and still at the
>address in the POC to confirm the POC.  ARIN does have the option
>under the NRPM of marking the POC "completely and permanently abandoned 
>or otherwise illegitimate"
>but I don't know if they have developed an internal process yet to
>make such designations or whether such a process includes phone calls
>or paper mails or other mechanisms (like querying a looking glass, etc.)
>Almost certainly such an internal process will prioritize the
>invalid POC's tied to the largest allocations first.
>
>But you can imagine what would happen even if ARIN were to paper-mail
>Leatherman Tools on this one.  Most likely the admin at
>Leatherman will not know what the heck the paper-mail is about and
>will wrongly assume they are still using that subnet - and tell
>ARIN not to do anything about it.  So that subnet will remain tied up,
>virtually forever, or at least until Leatherman Tools goes out of
>business, which isn't likely.  It would take a 20-minute phone call from
>the ARIN hostmaster to the head MIS admin at Leatherman Tools to
>explain what is going on and get permission to take back this
>legacy resource, and that's only if the guy at Leatherman is clueful.
>
>   Now, the interesting thing here is that in
>the 3-4 minutes that it took for you to read this and comprehend it, the 
>global RIR's have probably assigned 10 times the amount of IPv4
>space.  In other words, it's likely that it would NEVER be 
>cost-effective for ARIN to recover this space and reallocate it.
>So ARIN probably will never get around to deeming this particular
>/24 "permanently abandoned"  Hopefully though at least it eventually
>will be marked unresponsive.  The truth is that this particular subnet
>is my "canary in the coal mine" since I know it's history and I know
>it should be marked unresponsive, when I see that happen I'll know
>ARIN is implementing 3.6.1 fully.
>
>   Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>invalid POCS, so we should have in a year or two a list of subnets
>that are "ripe for mining" as they say.  I think that most of the
>community believes that there isn't a lot of this space out
>there.  I would also predict that if ARIN comes back with the
>equivalent of 5-10 /8's worth of "invalid POC" space that there
>will quickly be support for further IPv4 reclamation activities.
>
>Ted
>
>
>On 7/12/2010 10:49 AM, Dave Feuer wrote:
>> While cleaning up some old DNS records (again) I took a look at some of our
>> old address space. 2  x /23s from 2 providers. I did a quick whois and both
>> are still pointing to us. One we have not used since early 2001 the other
>> since late 2004. I did some tests and one of them still routes to the last
>> hop before it hit us.
>>
>>
>>
>> Then I took a look at the records for a client with a /22 that we managed
>> the DNS for. I don't know how long he has not had the IP space but it's been
>> at least 3 years and more likely closer to or over 4 years. Still pointing
>> to him (and his company no longer even exists) and still routing to the last
>> hop before him.
>>
>>
>>
>> How much space is out there and routed and going no place? Is there any way
>> to find out? It's more of a question to satisfy my curiosity but I think it
>> would be interesting to know.
>>
>>
>>
>> -Dave
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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.
>
 




________________________________________________________________
Sent via the WebMail system at connetrix.com


 
                   


From lar at mwtcorp.net  Mon Jul 12 16:26:04 2010
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Mon, 12 Jul 2010 14:26:04 -0600
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007121541.AA35913900@connetrix.com>
References: <201007121541.AA35913900@connetrix.com>
Message-ID: <web-2431390@be1.mail.trib.com>




  "Dave Feuer " <dave at connetrix.com> wrote:
> Ted,
> 
> Yes, but the question I asked still remains, how much is really out there 
>(and is there an easy way to find out)? Between the 2 of us we have just 
>accounted for 9 /24s are there only those 9 (yeah I know) or is it 9000, 
>900000 or 90000000 or an even grater number (which I think). It's not like 
>we can find them, take them back and combine them into a /8. So that point 
>is moot. It's just more of a hmmmmmm I wonder question.  

There is a LOT of abandoned space. In my case I know of a /20 and two /21's
of PA space that we used and returned to the provider that is still unused. 
The
two /21's are in whois as still being assigned to me even though I have
repeatedly asked to have it changed. I have a customer that has 2 - /24's 
and a /23,
similar thing same large provider. The large providers that have allowed the
whois to get stale will be able to meet their IPV4 needs for awhile
by reclaiming assigned and unused space. I think it was just easier to get
new than keep track and reclaim old space rather than some evil plan but
I know it's out there in great number.

> 
> -Dave 
> ---------- Original Message ----------------------------------
>From: Ted Mittelstaedt <tedm at ipinc.net>
> Date:  Mon, 12 Jul 2010 11:38:05 -0700
> 
>>Hi Dave,
>>
>>   Well, I think there is a lot of small space like this.  To give you 
>>an example take subnet 199.248.255.0/24, this was a direct assignment to
>>Leatherman Tools, which was a customer of ours over a decade ago.  They 
>>stopped using that space around 1999 but it was still routed to us.  I
>>used it periodically up until 2004 until we got our /19, but of course I
>>could not trade it in since we didn't own it.  I did mention it to the
>>ARIN hostmaster at that time.  So it's been abandonded for 6 years as 
>>well.   The last change on it's POC was from our former
>>admin who applied his e-mail address for his new employer to it (for 
>>some odd reason) but his new employer went bankrupt - and a domain 
>>speculator now has the POC e-mail address.
>>
>>   Presumably, when ARIN fully has Section 3.6.1 of the NRPM implemented
>>the domain speculator who has the domain on the POC will fail to respond 
>>to the annual POC notification e-mail, and eventually ARIN will
>>notice the POC record is invalid.  At that time they might paper-mail
>>Leatherman Tools which is still a going concern, and still at the
>>address in the POC to confirm the POC.  ARIN does have the option
>>under the NRPM of marking the POC "completely and permanently abandoned 
>>or otherwise illegitimate"
>>but I don't know if they have developed an internal process yet to
>>make such designations or whether such a process includes phone calls
>>or paper mails or other mechanisms (like querying a looking glass, etc.)
>>Almost certainly such an internal process will prioritize the
>>invalid POC's tied to the largest allocations first.
>>
>>But you can imagine what would happen even if ARIN were to paper-mail
>>Leatherman Tools on this one.  Most likely the admin at
>>Leatherman will not know what the heck the paper-mail is about and
>>will wrongly assume they are still using that subnet - and tell
>>ARIN not to do anything about it.  So that subnet will remain tied up,
>>virtually forever, or at least until Leatherman Tools goes out of
>>business, which isn't likely.  It would take a 20-minute phone call from
>>the ARIN hostmaster to the head MIS admin at Leatherman Tools to
>>explain what is going on and get permission to take back this
>>legacy resource, and that's only if the guy at Leatherman is clueful.
>>
>>   Now, the interesting thing here is that in
>>the 3-4 minutes that it took for you to read this and comprehend it, the 
>>global RIR's have probably assigned 10 times the amount of IPv4
>>space.  In other words, it's likely that it would NEVER be 
>>cost-effective for ARIN to recover this space and reallocate it.
>>So ARIN probably will never get around to deeming this particular
>>/24 "permanently abandoned"  Hopefully though at least it eventually
>>will be marked unresponsive.  The truth is that this particular subnet
>>is my "canary in the coal mine" since I know it's history and I know
>>it should be marked unresponsive, when I see that happen I'll know
>>ARIN is implementing 3.6.1 fully.
>>
>>   Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>invalid POCS, so we should have in a year or two a list of subnets
>>that are "ripe for mining" as they say.  I think that most of the
>>community believes that there isn't a lot of this space out
>>there.  I would also predict that if ARIN comes back with the
>>equivalent of 5-10 /8's worth of "invalid POC" space that there
>>will quickly be support for further IPv4 reclamation activities.
>>
>>Ted
>>
>>
>>On 7/12/2010 10:49 AM, Dave Feuer wrote:
>>> While cleaning up some old DNS records (again) I took a look at some of 
>>>our
>>> old address space. 2  x /23s from 2 providers. I did a quick whois and 
>>>both
>>> are still pointing to us. One we have not used since early 2001 the other
>>> since late 2004. I did some tests and one of them still routes to the last
>>> hop before it hit us.
>>>
>>>
>>>
>>> Then I took a look at the records for a client with a /22 that we managed
>>> the DNS for. I don't know how long he has not had the IP space but it's 
>>>been
>>> at least 3 years and more likely closer to or over 4 years. Still pointing
>>> to him (and his company no longer even exists) and still routing to the 
>>>last
>>> hop before him.
>>>
>>>
>>>
>>> How much space is out there and routed and going no place? Is there any 
>>>way
>>> to find out? It's more of a question to satisfy my curiosity but I think 
>>>it
>>> would be interesting to know.
>>>
>>>
>>>
>>> -Dave
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>
> 
> 
> 
> 
> 
> ________________________________________________________________
> Sent via the WebMail system at connetrix.com
> 
> 
> 
>                   
> _______________________________________________
> 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
123 W 1st St.
Casper, WY 82601
Office 307 233-8387


From cgrundemann at gmail.com  Mon Jul 12 17:15:20 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 12 Jul 2010 15:15:20 -0600
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <web-2431390@be1.mail.trib.com>
References: <201007121541.AA35913900@connetrix.com>
	<web-2431390@be1.mail.trib.com>
Message-ID: <AANLkTilWR1qdfKFJIEusFPY4zBINoN_9b0T4CeLgBMuj@mail.gmail.com>

On Mon, Jul 12, 2010 at 14:26,  <lar at mwtcorp.net> wrote:
>
> There is a LOT of abandoned space. In my case I know of a /20 and two /21's
> of PA space that we used and returned to the provider that is still unused.
> The
> two /21's are in whois as still being assigned to me even though I have
> repeatedly asked to have it changed. I have a customer that has 2 - /24's
> and a /23,
> similar thing same large provider. The large providers that have allowed the
> whois to get stale will be able to meet their IPV4 needs for awhile
> by reclaiming assigned and unused space.

Disconnect orders in general seem to get far less attention then they
should in most providers, in my experience.  In addition to
languishing IP space, there are numerous physical ports, VLAN tags,
private AS numbers, type-2 circuits, etc. out there. The circuits and
ports seem to get cleaned up more often (usually in batches as part of
a cost-cutting project) because they cost money. In companies/networks
where VLAN availability becomes an issue, those start to get cleaned
up too. I am sure that we can expect the same with IPv4 nets, as you
say.
~Chris

> I think it was just easier to get
> new than keep track and reclaim old space rather than some evil plan but
> I know it's out there in great number.
>
>
> Larry Ash
> Network Administrator
> Mountain West Telephone
> 123 W 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.
>




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Mon Jul 12 17:24:04 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Jul 2010 14:24:04 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <004801cb21ea$89159cf0$9b40d6d0$@com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
Message-ID: <B0809F91-439D-4646-A83F-98C686008C5B@delong.com>

In cases where you know this is happening I strongly urge you to pass the information to the ARIN fraud reporting
process so that ARIN can work with the provider(s) in question to get the issue resolved.

Thank you,

Owen DeLong

On Jul 12, 2010, at 10:49 AM, Dave Feuer wrote:

> While cleaning up some old DNS records (again) I took a look at some of our old address space. 2  x /23s from 2 providers. I did a quick whois and both are still pointing to us. One we have not used since early 2001 the other since late 2004. I did some tests and one of them still routes to the last hop before it hit us.
>  
> Then I took a look at the records for a client with a /22 that we managed the DNS for. I don?t know how long he has not had the IP space but it?s been at least 3 years and more likely closer to or over 4 years. Still pointing to him (and his company no longer even exists) and still routing to the last hop before him.
>  
> How much space is out there and routed and going no place? Is there any way to find out? It?s more of a question to satisfy my curiosity but I think it would be interesting to know.
>  
> -Dave
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From jcurran at arin.net  Mon Jul 12 18:02:14 2010
From: jcurran at arin.net (John Curran)
Date: Mon, 12 Jul 2010 18:02:14 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3B610D.9040108@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
Message-ID: <F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>

On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:

> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
> invalid POCS, so we should have in a year or two a list of subnets
> that are "ripe for mining" as they say.  

Ted is right on target here, and we're proceeding with POC 
validation at an aggressive rate.  (For more information, see 
<https://www.arin.net/resources/services/poc_validation.html>)

We're presently sending out 7500 validation requests each week,
and getting just over a 33% update rate on those requests. It's
too early to draw conclusions, but there's obviously ample space
which presently lacks a responsive contact.  We'll provide a more
detailed update on POC validation during the October PPML meeting.

/John

John Curran
President and CEO
ARIN



From tedm at ipinc.net  Mon Jul 12 20:36:32 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 12 Jul 2010 17:36:32 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
Message-ID: <4C3BB510.1010600@ipinc.net>



On 7/12/2010 3:02 PM, John Curran wrote:
> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>
>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>> invalid POCS, so we should have in a year or two a list of subnets
>> that are "ripe for mining" as they say.
>
> Ted is right on target here, and we're proceeding with POC
> validation at an aggressive rate.  (For more information, see
> <https://www.arin.net/resources/services/poc_validation.html>)
>
> We're presently sending out 7500 validation requests each week,
> and getting just over a 33% update rate on those requests. It's
> too early to draw conclusions, but there's obviously ample space
> which presently lacks a responsive contact.  We'll provide a more
> detailed update on POC validation during the October PPML meeting.
>

I will chime in here and caution that only the POCs that are applied to 
entire allocated blocks are going to affect the supply of "reclaimable"
IPv4.  I would guess the majority of invalid POCs were created from
old SWIPS that were filed and just forgotten about.  While it's
good to mark these as invalid so that it does not waste the
community's time when attempting to solve spamming/network attack/
routing problems, as well as inform the parent ISP that the subnet
which is part of their block needs correction, the interesting
part is going to be when ARIN runs across a legacy block that
is simply unused, not advertised, with a defunct org on it.

Of course the REAL interesting part will be if ARIN runs across
a large unused block that is not being advertised, is not being used 
internally, yet the org is still -paying-the-yearly-renewal for it and
doesn't even know that they don't need to do that anymore.


Ted

> /John
>
> John Curran
> President and CEO
> ARIN
>
>


From owen at delong.com  Mon Jul 12 21:21:50 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Jul 2010 18:21:50 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BB510.1010600@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BB510.1010600@ipinc.net>
Message-ID: <EDB8F1A3-A01E-4419-BBFE-2917CC83D685@delong.com>


On Jul 12, 2010, at 5:36 PM, Ted Mittelstaedt wrote:

> 
> 
> On 7/12/2010 3:02 PM, John Curran wrote:
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>> 
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>> invalid POCS, so we should have in a year or two a list of subnets
>>> that are "ripe for mining" as they say.
>> 
>> Ted is right on target here, and we're proceeding with POC
>> validation at an aggressive rate.  (For more information, see
>> <https://www.arin.net/resources/services/poc_validation.html>)
>> 
>> We're presently sending out 7500 validation requests each week,
>> and getting just over a 33% update rate on those requests. It's
>> too early to draw conclusions, but there's obviously ample space
>> which presently lacks a responsive contact.  We'll provide a more
>> detailed update on POC validation during the October PPML meeting.
>> 
> 
> I will chime in here and caution that only the POCs that are applied to entire allocated blocks are going to affect the supply of "reclaimable"
> IPv4.  I would guess the majority of invalid POCs were created from

Not necessarily... Invalid POCs may lead to an organization having insufficient
justification for all of their current resources under a section 12 resource review.

> old SWIPS that were filed and just forgotten about.  While it's

Right... These could lead to useful or meaningful invocations of section 12.

> good to mark these as invalid so that it does not waste the
> community's time when attempting to solve spamming/network attack/
> routing problems, as well as inform the parent ISP that the subnet
> which is part of their block needs correction, the interesting
> part is going to be when ARIN runs across a legacy block that
> is simply unused, not advertised, with a defunct org on it.
> 
I still don't think that reclamation will do anything to provide a significant quantity
of useful address space, but, I didn't want to leave the claim that old SWIPs that
are forgotten are irrelevant to reclamation unanswered. That could give the
impression that they were a safe-harbour for hoarding addresses, which they
certainly should not be and are not under current policy.

> Of course the REAL interesting part will be if ARIN runs across
> a large unused block that is not being advertised, is not being used internally, yet the org is still -paying-the-yearly-renewal for it and
> doesn't even know that they don't need to do that anymore.
> 
Yep. I doubt that is as likely as some people seem to believe, but, we should
know relatively soon.

Owen

> 
> Ted
> 
>> /John
>> 
>> John Curran
>> President and CEO
>> 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 steve at ipv6canada.com  Mon Jul 12 21:46:20 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 12 Jul 2010 21:46:20 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
Message-ID: <4C3BC56C.5090007@ipv6canada.com>

On 2010.07.12 18:02, John Curran wrote:
> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
> 
>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>> invalid POCS, so we should have in a year or two a list of subnets
>> that are "ripe for mining" as they say.  
> 
> Ted is right on target here, and we're proceeding with POC 
> validation at an aggressive rate.  (For more information, see 
> <https://www.arin.net/resources/services/poc_validation.html>)
> 
> We're presently sending out 7500 validation requests each week,
> and getting just over a 33% update rate on those requests. It's
> too early to draw conclusions, but there's obviously ample space
> which presently lacks a responsive contact.  We'll provide a more
> detailed update on POC validation during the October PPML meeting.

Cheers for having a relatively accurate % so quickly in the discussion.

That is admirable.

Steve

ps. I'm a small part of that 33%. all it took was one ``click'' ;)


From sethm at rollernet.us  Mon Jul 12 22:21:44 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 12 Jul 2010 19:21:44 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BC56C.5090007@ipv6canada.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BC56C.5090007@ipv6canada.com>
Message-ID: <4C3BCDB8.7060609@rollernet.us>

On 7/12/10 6:46 PM, Steve Bertrand wrote:
> On 2010.07.12 18:02, John Curran wrote:
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>>
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>> invalid POCS, so we should have in a year or two a list of subnets
>>> that are "ripe for mining" as they say.  
>>
>> Ted is right on target here, and we're proceeding with POC 
>> validation at an aggressive rate.  (For more information, see 
>> <https://www.arin.net/resources/services/poc_validation.html>)
>>
>> We're presently sending out 7500 validation requests each week,
>> and getting just over a 33% update rate on those requests. It's
>> too early to draw conclusions, but there's obviously ample space
>> which presently lacks a responsive contact.  We'll provide a more
>> detailed update on POC validation during the October PPML meeting.
> 
> Cheers for having a relatively accurate % so quickly in the discussion.
> 
> That is admirable.
> 
> Steve
> 
> ps. I'm a small part of that 33%. all it took was one ``click'' ;)
> _______________________________________________


4 clicks for me so far. ;)

~Seth


From steve at ipv6canada.com  Mon Jul 12 22:30:37 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 12 Jul 2010 22:30:37 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BB510.1010600@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BB510.1010600@ipinc.net>
Message-ID: <4C3BCFCD.5020600@ipv6canada.com>

On 2010.07.12 20:36, Ted Mittelstaedt wrote:
> 
> 
> On 7/12/2010 3:02 PM, John Curran wrote:
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>>
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>> invalid POCS, so we should have in a year or two a list of subnets
>>> that are "ripe for mining" as they say.

I've had +six people respond to my last message in regards to this
thread (particularly to my ``click'').

After reading the policy, it would seem apparent to me that the
responsibility of any message sent by ARIN to a responsible POC would be
up to the address holder of the POC... is that correct?

ie. if spam filters catch a message destined to them that originate from
ARIN, then they, or their email admins should be aware to allow all
email from ARIN to traverse the filters and make it to the destination.

I appreciate this effort, and feel that it is the responsibility of the
recipient to accept the message properly from ARIN, as this has been
decided and documented in our policy.

If you fear your filters fscked it up:

"If you have any questions, please contact the ARIN Registration
Services Help Desk.

Ask ARIN via your ARIN Online web account:
https://www.arin.net/public/communication/message/beginQuestion.xhtml
E-mail: hostmaster at arin.net
Phone: +1.703.227.0660"

fwiw, I mean no disrespect... I'd like the ones who don't know that they
might have a message in their filters to read this.

For those that have responded to me with spam complaints, please send me
the headers. I'll help eliminate the text that hit the rules.

Steve




From matthew at matthew.at  Mon Jul 12 22:02:38 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 12 Jul 2010 19:02:38 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BC56C.5090007@ipv6canada.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BC56C.5090007@ipv6canada.com>
Message-ID: <6326606C-47ED-4527-8542-7F66F66D3D85@matthew.at>


On Jul 12, 2010, at 6:46 PM, Steve Bertrand <steve at ipv6canada.com> wrote:

> 
> 
> ps. I'm a small part of that 33%. all it took was one ``click'' ;)
> 

For me it only took one click too... after I found the message in a spam-filter mailbox it had sat in for weeks.

Wonder how many copies triggered the "too many suspect links" rule in others' filters.

Matthew Kaufman 




From steve at ipv6canada.com  Mon Jul 12 22:33:56 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 12 Jul 2010 22:33:56 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BCDB8.7060609@rollernet.us>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BC56C.5090007@ipv6canada.com>
	<4C3BCDB8.7060609@rollernet.us>
Message-ID: <4C3BD094.9060303@ipv6canada.com>

On 2010.07.12 22:21, Seth Mattinen wrote:
> On 7/12/10 6:46 PM, Steve Bertrand wrote:
>> On 2010.07.12 18:02, John Curran wrote:
>>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>>>
>>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>>> invalid POCS, so we should have in a year or two a list of subnets
>>>> that are "ripe for mining" as they say.  
>>>
>>> Ted is right on target here, and we're proceeding with POC 
>>> validation at an aggressive rate.  (For more information, see 
>>> <https://www.arin.net/resources/services/poc_validation.html>)
>>>
>>> We're presently sending out 7500 validation requests each week,
>>> and getting just over a 33% update rate on those requests. It's
>>> too early to draw conclusions, but there's obviously ample space
>>> which presently lacks a responsive contact.  We'll provide a more
>>> detailed update on POC validation during the October PPML meeting.
>>
>> Cheers for having a relatively accurate % so quickly in the discussion.
>>
>> That is admirable.
>>
>> Steve
>>
>> ps. I'm a small part of that 33%. all it took was one ``click'' ;)
>> _______________________________________________
> 
> 
> 4 clicks for me so far. ;)

...seth, why?

you're not trying to `click' on the cli again, are you? ;)

Steve


From matthew at matthew.at  Mon Jul 12 22:39:30 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 12 Jul 2010 19:39:30 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BCFCD.5020600@ipv6canada.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com>
Message-ID: <4C3BD1E2.2030004@matthew.at>

Steve Bertrand wrote:
>
> After reading the policy, it would seem apparent to me that the
> responsibility of any message sent by ARIN to a responsible POC would be
> up to the address holder of the POC... is that correct?
>
> ie. if spam filters catch a message destined to them that originate from
> ARIN, then they, or their email admins should be aware to allow all
> email from ARIN to traverse the filters and make it to the destination.
>   
Unfortunately, the world of email today makes it much more likely that a 
personal one-to-one communication will be delivered than will a bulk 
(and yes, this is a "bulk email" by any definition) delivery of messages 
with multiple "click to act now" URLs in it.

In my case the message wasn't immediately discarded, but was moved from 
the "personal messages, read now" box to the "suspect messages, review" 
box due to the "?validationCode=9dba..." in the first URL. That simply 
isn't the sort of thing that a "real person" would send to an ARIN POC 
in order to get help.

And if they didn't get a reply, they could try my phone number and get a 
prompt reply that way as well... but the POC validation process didn't 
call me on the phone, either.
> I appreciate this effort, and feel that it is the responsibility of the
> recipient to accept the message properly from ARIN, as this has been
> decided and documented in our policy.
>   
And how many of the POCs are participants in the policy-development 
process, do you suppose?

Personally I think it is a great first step, but it might have been a 
lot better to have a plain text message with absolutely no URLs and no 
advertising terms in it go out first that said "from now on, ARIN will 
reach you this way, please whitelist the source of this message".

Matthew Kaufman


From steve at ipv6canada.com  Mon Jul 12 22:41:12 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 12 Jul 2010 22:41:12 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BD1E2.2030004@matthew.at>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com> <4C3BD1E2.2030004@matthew.at>
Message-ID: <4C3BD248.8040304@ipv6canada.com>

On 2010.07.12 22:39, Matthew Kaufman wrote:

> Personally I think it is a great first step, but it might have been a
> lot better to have a plain text message 

...agreed.

Steve


From owen at delong.com  Mon Jul 12 22:49:12 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 12 Jul 2010 19:49:12 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BD1E2.2030004@matthew.at>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com> <4C3BD1E2.2030004@matthew.at>
Message-ID: <4F71A6BC-C9DC-46F4-B99C-F305CB1D6688@delong.com>


On Jul 12, 2010, at 7:39 PM, Matthew Kaufman wrote:

> Steve Bertrand wrote:
>> 
>> After reading the policy, it would seem apparent to me that the
>> responsibility of any message sent by ARIN to a responsible POC would be
>> up to the address holder of the POC... is that correct?
>> 
>> ie. if spam filters catch a message destined to them that originate from
>> ARIN, then they, or their email admins should be aware to allow all
>> email from ARIN to traverse the filters and make it to the destination.
>>  
> Unfortunately, the world of email today makes it much more likely that a personal one-to-one communication will be delivered than will a bulk (and yes, this is a "bulk email" by any definition) delivery of messages with multiple "click to act now" URLs in it.
> 
> In my case the message wasn't immediately discarded, but was moved from the "personal messages, read now" box to the "suspect messages, review" box due to the "?validationCode=9dba..." in the first URL. That simply isn't the sort of thing that a "real person" would send to an ARIN POC in order to get help.
> 
> And if they didn't get a reply, they could try my phone number and get a prompt reply that way as well... but the POC validation process didn't call me on the phone, either.

I'm pretty sure they are trying to get as many responses by email as possible first, then, will resort to calling contacts that did not respond to the email. I think we should all be able to agree that this is a logical and prudent use of resources as starting off with phone calls right away would be very resource intensive with potentially less effective results (out of office, voice mail, etc.).

>> I appreciate this effort, and feel that it is the responsibility of the
>> recipient to accept the message properly from ARIN, as this has been
>> decided and documented in our policy.
>>  
> And how many of the POCs are participants in the policy-development process, do you suppose?
> 
> Personally I think it is a great first step, but it might have been a lot better to have a plain text message with absolutely no URLs and no advertising terms in it go out first that said "from now on, ARIN will reach you this way, please whitelist the source of this message".
> 
I think a plain text message could well be an excellent follow-up. However, since the response
automation requires the URLs to be effective, it seems reasonable to attempt that as a first step.

Owen



From steve at ipv6canada.com  Mon Jul 12 23:10:20 2010
From: steve at ipv6canada.com (Steve Bertrand)
Date: Mon, 12 Jul 2010 23:10:20 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4F71A6BC-C9DC-46F4-B99C-F305CB1D6688@delong.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com> <4C3BD1E2.2030004@matthew.at>
	<4F71A6BC-C9DC-46F4-B99C-F305CB1D6688@delong.com>
Message-ID: <4C3BD91C.1030904@ipv6canada.com>

On 2010.07.12 22:49, Owen DeLong wrote:
> 
> On Jul 12, 2010, at 7:39 PM, Matthew Kaufman wrote:
> 
>> Steve Bertrand wrote:
>>>
>>> After reading the policy, it would seem apparent to me that the
>>> responsibility of any message sent by ARIN to a responsible POC would be
>>> up to the address holder of the POC... is that correct?
>>>
>>> ie. if spam filters catch a message destined to them that originate from
>>> ARIN, then they, or their email admins should be aware to allow all
>>> email from ARIN to traverse the filters and make it to the destination.
>>>  
>> Unfortunately, the world of email today makes it much more likely that a personal one-to-one communication will be delivered than will a bulk (and yes, this is a "bulk email" by any definition) delivery of messages with multiple "click to act now" URLs in it.
>>
>> In my case the message wasn't immediately discarded, but was moved from the "personal messages, read now" box to the "suspect messages, review" box due to the "?validationCode=9dba..." in the first URL. That simply isn't the sort of thing that a "real person" would send to an ARIN POC in order to get help.
>>
>> And if they didn't get a reply, they could try my phone number and get a prompt reply that way as well... but the POC validation process didn't call me on the phone, either.
> 
> I'm pretty sure they are trying to get as many responses by email as possible first, then, will resort to calling contacts that did not respond to the email. I think we should all be able to agree that this is a logical and prudent use of resources as starting off with phone calls right away would be very resource intensive with potentially less effective results (out of office, voice mail, etc.).
> 
>>> I appreciate this effort, and feel that it is the responsibility of the
>>> recipient to accept the message properly from ARIN, as this has been
>>> decided and documented in our policy.
>>>  
>> And how many of the POCs are participants in the policy-development process, do you suppose?
>>
>> Personally I think it is a great first step, but it might have been a lot better to have a plain text message with absolutely no URLs and no advertising terms in it go out first that said "from now on, ARIN will reach you this way, please whitelist the source of this message".
>>
> I think a plain text message could well be an excellent follow-up. However, since the response
> automation requires the URLs to be effective, it seems reasonable to attempt that as a first step.

Agreed, however:

If there are other plain-text people on this list who like Matthew's
idea, I'd be willing to write a wrapper for the outgoing/incoming
message, so that it can be passed in to the `click' procedure, without
having to `click'.

Two messages each, one plain, one html. Perhaps in ARIN Online, one
could select text only email.

Either way, a plain-text, open-source (published to CPAN) filter may fit
ARIN's API, and be extensible beyond email.

heh, I'm getting ahead of myself, and far off-topic for a policy list.

Email first, and then phone call.

Steve


From tedm at ipinc.net  Tue Jul 13 02:48:54 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 12 Jul 2010 23:48:54 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BD1E2.2030004@matthew.at>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com> <4C3BD1E2.2030004@matthew.at>
Message-ID: <4C3C0C56.507@ipinc.net>

Guys,

   Before getting too worked up, please keep in mind that the fact that
the mail message was ACCEPTED by your mail system and not immediately
bounced, indicates that there's a valid e-mail box there.

   I'd hazard a guess that if you didn't click on the link at all
that ARIN is going to still consider the POC  "most likely valid".

Ted

On 7/12/2010 7:39 PM, Matthew Kaufman wrote:
> Steve Bertrand wrote:
>>
>> After reading the policy, it would seem apparent to me that the
>> responsibility of any message sent by ARIN to a responsible POC would be
>> up to the address holder of the POC... is that correct?
>>
>> ie. if spam filters catch a message destined to them that originate from
>> ARIN, then they, or their email admins should be aware to allow all
>> email from ARIN to traverse the filters and make it to the destination.
> Unfortunately, the world of email today makes it much more likely that a
> personal one-to-one communication will be delivered than will a bulk
> (and yes, this is a "bulk email" by any definition) delivery of messages
> with multiple "click to act now" URLs in it.
>
> In my case the message wasn't immediately discarded, but was moved from
> the "personal messages, read now" box to the "suspect messages, review"
> box due to the "?validationCode=9dba..." in the first URL. That simply
> isn't the sort of thing that a "real person" would send to an ARIN POC
> in order to get help.
>
> And if they didn't get a reply, they could try my phone number and get a
> prompt reply that way as well... but the POC validation process didn't
> call me on the phone, either.
>> I appreciate this effort, and feel that it is the responsibility of the
>> recipient to accept the message properly from ARIN, as this has been
>> decided and documented in our policy.
> And how many of the POCs are participants in the policy-development
> process, do you suppose?
>
> Personally I think it is a great first step, but it might have been a
> lot better to have a plain text message with absolutely no URLs and no
> advertising terms in it go out first that said "from now on, ARIN will
> reach you this way, please whitelist the source of this message".
>
> Matthew Kaufman


From farmer at umn.edu  Tue Jul 13 10:41:34 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 13 Jul 2010 09:41:34 -0500
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BD91C.1030904@ipv6canada.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>
	<4C3BD1E2.2030004@matthew.at>	<4F71A6BC-C9DC-46F4-B99C-F305CB1D6688@delong.com>
	<4C3BD91C.1030904@ipv6canada.com>
Message-ID: <4C3C7B1E.9060805@umn.edu>

On 7/12/10 22:10 CDT, Steve Bertrand wrote:
> On 2010.07.12 22:49, Owen DeLong wrote:
>>
>> I think a plain text message could well be an excellent follow-up. However, since the response
>> automation requires the URLs to be effective, it seems reasonable to attempt that as a first step.
>
> Agreed, however:
>
> If there are other plain-text people on this list who like Matthew's
> idea, I'd be willing to write a wrapper for the outgoing/incoming
> message, so that it can be passed in to the `click' procedure, without
> having to `click'.
>
> Two messages each, one plain, one html. Perhaps in ARIN Online, one
> could select text only email.
>
> Either way, a plain-text, open-source (published to CPAN) filter may fit
> ARIN's API, and be extensible beyond email.
>
> heh, I'm getting ahead of myself, and far off-topic for a policy list.
>
> Email first, and then phone call.

If anyone has suggestions on how to improve this or any other of ARIN's 
processes I would like to remind you of the ACSP.

https://www.arin.net/participate/acsp/index.html

Specifically to make a suggestion;

https://www.arin.net/app/suggestion/



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


From info at arin.net  Tue Jul 13 12:42:16 2010
From: info at arin.net (Member Services)
Date: Tue, 13 Jul 2010 12:42:16 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - June 2010
In-Reply-To: <4C20F2BB.8070009@arin.net>
References: <4C20F2BB.8070009@arin.net>
Message-ID: <4C3C9768.9050008@arin.net>

The Advisory Council's meeting minutes have been published for their 17
June May 2010 meeting and are available at:
https://www.arin.net/about_us/ac/ac2010_0617.html

Per the messages below the deadline for petitions regarding any of the
AC actions taken at their meeting is 20 July 2010.

For more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

Regards,

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


Member Services wrote:
> In accordance with the ARIN Policy Development Process (PDP), the ARIN
> Advisory Council (AC) held a meeting on 17 June 2010 and made decisions
> about several draft policies and proposals.
>
> The AC recommended that the ARIN Board of Trustees adopt the following
> draft policy:
>
> 2010-2: /24 End User Minimum Assignment Unit
>
> The AC moved the following draft policy to an extended last call (it
> will be posted separately to last call):
>
> 2010-1: Waiting List for Unmet IPv4 Requests
>
> The AC accepted the following proposal on to the AC's docket for
> development and evaluation:
>
> 115. Global Policy for IPv4 Allocations by the IANA Post Exhaustion
>
> The AC abandoned the following proposal:
>
> 111. IPv4 Fragment Management policy proposal
>
> The ARIN AC abandoned Proposal 111 because its intent was rendered moot
> by the sending of 2010-1 to last call.
>
> 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.? Proposal 111 may be petitioned to try to change it
> into a draft policy for discussion on the Public Policy Mailing List and
> at the October meeting (Discussion Petition). The deadline to begin a
> petition is five business days after the AC's draft meeting minutes are
> published.
>
> 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 are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>





From springer at inlandnet.com  Tue Jul 13 18:45:24 2010
From: springer at inlandnet.com (John Springer)
Date: Tue, 13 Jul 2010 15:45:24 -0700 (PDT)
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3BC56C.5090007@ipv6canada.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BC56C.5090007@ipv6canada.com>
Message-ID: <20100713151718.P60520@mail.inlandnet.com>

Quick question, is the "33% update rate" those that actually
update (add to or edit) the POC information or those + those who say no 
changes needed, i.e. the response rate?

tia

John Springer

On Mon, 12 Jul 2010, Steve Bertrand wrote:

> On 2010.07.12 18:02, John Curran wrote:
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>>
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>> invalid POCS, so we should have in a year or two a list of subnets
>>> that are "ripe for mining" as they say.
>>
>> Ted is right on target here, and we're proceeding with POC
>> validation at an aggressive rate.  (For more information, see
>> <https://www.arin.net/resources/services/poc_validation.html>)
>>
>> We're presently sending out 7500 validation requests each week,
>> and getting just over a 33% update rate on those requests. It's
>> too early to draw conclusions, but there's obviously ample space
>> which presently lacks a responsive contact.  We'll provide a more
>> detailed update on POC validation during the October PPML meeting.
>
> Cheers for having a relatively accurate % so quickly in the discussion.
>
> That is admirable.
>
> Steve
>
> ps. I'm a small part of that 33%. all it took was one ``click'' ;)
> _______________________________________________
> 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 dave at connetrix.com  Wed Jul 14 12:49:48 2010
From: dave at connetrix.com (Dave Feuer )
Date: Wed, 14 Jul 2010 12:49:48 -0400
Subject: [arin-ppml] How bad is it really?
Message-ID: <201007141249.AA5570768@connetrix.com>



---------- Original Message ----------------------------------
From: John Curran <jcurran at arin.net>
Date:  Mon, 12 Jul 2010 18:02:14 -0400

>On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>
>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>> invalid POCS, so we should have in a year or two a list of subnets
>> that are "ripe for mining" as they say.  
>
>Ted is right on target here, and we're proceeding with POC 
>validation at an aggressive rate.  (For more information, see 
><https://www.arin.net/resources/services/poc_validation.html>)
>
>We're presently sending out 7500 validation requests each week,
>and getting just over a 33% update rate on those requests. It's
>too early to draw conclusions, but there's obviously ample space
>which presently lacks a responsive contact.  We'll provide a more
>detailed update on POC validation during the October PPML meeting.

Drifting from the original question which was how much space like this is out there...
But, how is that being checked? Here is what I see as the issue, and feel free to call me out if I am way off base.
We had IP space from UUnet (remember them) back in the late 90?s till early 2001, we shut it down more than 9 years ago range was 280.236.182.0 /23. If I query the WhoIs now I see the following:

CustName:   Systems & Software
Address:    One Ames Ct. suite 108
City:       Plainview
StateProv:  NY
PostalCode: 11803
Country:    US
RegDate:    1998-02-09
Updated:    2003-05-30

NetRange:   208.236.182.0 - 208.236.183.255 
CIDR:       208.236.182.0/23 
NetName:    UU-208-236-182
NetHandle:  NET-208-236-182-0-1
Parent:     NET-208-192-0-0-1
NetType:    Reassigned
Comment:    
RegDate:    1998-02-09
Updated:    2003-05-30

RTechHandle: OA12-ARIN
RTechName:   UUnet Technologies, Inc., Technologies 
RTechPhone:  +1-800-900-0241
RTechEmail:  help4u at verizonbusiness.com 

OrgAbuseHandle: ABUSE3-ARIN
OrgAbuseName:   abuse 
OrgAbusePhone:  +1-800-900-0241
OrgAbuseEmail:  abuse-mail at verizonbusiness.com

OrgNOCHandle: OA12-ARIN
OrgNOCName:   UUnet Technologies, Inc., Technologies 
OrgNOCPhone:  +1-800-900-0241
OrgNOCEmail:  help4u at verizonbusiness.com

OrgTechHandle: JHU140-ARIN
OrgTechName:   Huffines, Jody 
OrgTechPhone:  +1-703-886-6093
OrgTechEmail:  Jody.Huffines at verizonbusiness.com

OrgTechHandle: SWIPP-ARIN
OrgTechName:   swipper 
OrgTechPhone:  +1-800-900-0241
OrgTechEmail:  swipper at verizonbusiness.com

<snip>


That?s us, so as far as the world knows we have that space. So the IPs went from UUnet to MCI to Verizon through the M&A?s. Last year when we were getting our own allocation I saw this and sent 2 emails to them and then promptly forgot about it. But technically it?s still pointing to us and VZ can use it as a justification to get more IP space. If you query the main netblock you get the same info. So if you do send out an email to them for the 1000?s of subnets do you really think they are going to check each one or just blindly say ?yes we are using it?. 

I have, since Monday when I brought this up called some other people I know who have had different providers through the years and found as of now about a dozen /24?s or larger blocks still pointing to places that don?t use them or are not in business anymore. One of which is actually a pile of rubble in Veags, but that?s another story. As a side note on human nature, nobody else wanted me to put up their IP info for fear or ?rocking the boat?. 

-Dave









>/John
>
>John Curran
>President and CEO
>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.
>
 




________________________________________________________________
Sent via the WebMail system at connetrix.com


 
                   



From tedm at ipinc.net  Wed Jul 14 13:24:38 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Jul 2010 10:24:38 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007141249.AA5570768@connetrix.com>
References: <201007141249.AA5570768@connetrix.com>
Message-ID: <4C3DF2D6.7060202@ipinc.net>



On 7/14/2010 9:49 AM, Dave Feuer wrote:
>
>
> ---------- Original Message ---------------------------------- From:
> John Curran<jcurran at arin.net> Date:  Mon, 12 Jul 2010 18:02:14 -0400
>
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>>
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list
>>> of invalid POCS, so we should have in a year or two a list of
>>> subnets that are "ripe for mining" as they say.
>>
>> Ted is right on target here, and we're proceeding with POC
>> validation at an aggressive rate.  (For more information, see
>> <https://www.arin.net/resources/services/poc_validation.html>)
>>
>> We're presently sending out 7500 validation requests each week, and
>> getting just over a 33% update rate on those requests. It's too
>> early to draw conclusions, but there's obviously ample space which
>> presently lacks a responsive contact.  We'll provide a more
>> detailed update on POC validation during the October PPML meeting.
>
> Drifting from the original question which was how much space like
> this is out there... But, how is that being checked? Here is what I
> see as the issue, and feel free to call me out if I am way off base.
> We had IP space from UUnet (remember them) back in the late 90?s till
> early 2001, we shut it down more than 9 years ago range was
> 280.236.182.0 /23. If I query the WhoIs now I see the following:
>
> CustName:   Systems&  Software Address:    One Ames Ct. suite 108
> City:       Plainview StateProv:  NY PostalCode: 11803 Country:
> US RegDate:    1998-02-09 Updated:    2003-05-30
>
> NetRange:   208.236.182.0 - 208.236.183.255 CIDR:
> 208.236.182.0/23 NetName:    UU-208-236-182 NetHandle:
> NET-208-236-182-0-1 Parent:     NET-208-192-0-0-1 NetType:
> Reassigned Comment: RegDate:    1998-02-09 Updated:    2003-05-30
>
> RTechHandle: OA12-ARIN RTechName:   UUnet Technologies, Inc.,
> Technologies RTechPhone:  +1-800-900-0241 RTechEmail:
> help4u at verizonbusiness.com
>
> OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName:   abuse OrgAbusePhone:
> +1-800-900-0241 OrgAbuseEmail:  abuse-mail at verizonbusiness.com
>
> OrgNOCHandle: OA12-ARIN OrgNOCName:   UUnet Technologies, Inc.,
> Technologies OrgNOCPhone:  +1-800-900-0241 OrgNOCEmail:
> help4u at verizonbusiness.com
>
> OrgTechHandle: JHU140-ARIN OrgTechName:   Huffines, Jody
> OrgTechPhone:  +1-703-886-6093 OrgTechEmail:
> Jody.Huffines at verizonbusiness.com
>
> OrgTechHandle: SWIPP-ARIN OrgTechName:   swipper OrgTechPhone:
> +1-800-900-0241 OrgTechEmail:  swipper at verizonbusiness.com
>
> <snip>
>
>
> That?s us, so as far as the world knows we have that space. So the
> IPs went from UUnet to MCI to Verizon through the M&A?s. Last year
> when we were getting our own allocation I saw this and sent 2 emails
> to them and then promptly forgot about it. But technically it?s still
> pointing to us and VZ can use it as a justification to get more IP
> space.

Technically this is fraud and should be reported to hostmaster at arin.net

One big red flag here is that the netblock owner (Verizon) has set
the POC e-mail address to themselves, instead of the customer.

Technically this is also a violation of the NRPM because Verizon is
NOT supplying the customer contact data for the SWIP as required by the 
NRPM  (supplying most of it ain't good enough, either all the
data is accurate or the whole POC is trash)

I would presume that as the years pass and ARIN gets past the
initial group of non-responders during their yearly POC check, that
they will become more sophisticated in the POC checks and
start comparing the e-mail addresses on the POCs

As you might imagine, it would be childs play to write a program
that would analyze all SWIP POCs in an allocated subnet and if
most of them were set to the same e-mail address as the main
"parent" POC used on the aggregate allocation, that this would
trigger a review by ARIN.  It might be something that a graduate
student could take up for their Senior's thesis.  I'd title it
"Increasing the accuracy of IPv4 utilization reporting" or some
such.

This is why it is so important to shoot down any attempt to
allow SWIPS to contain "proxy" information.  Some of those have
come up as proposals in the past under the guise of "protecting
privacy" and recieved a surprising amount of support.

In the case of Verizon, at one of the last meetings a Verizon rep
did admit that the POC cleanup had caused them to do a whole lot
of unexpected work, cleaning up POC entries.  I would not say that
this is deliberate misreporting on their part, but I would say that
based on the assumption that within a few months of you reporting
this to ARIN (and posting it here on the mailing list isn't a
formal report) that it would be corrected.

Also keep in mind Verizon just sold a whole chunk of their Pacific 
Northwest territory to Frontier Cmmunications, and there's going to be a 
LOT of innacurate SWIPS in WHOIS for all of the DSL/FIOS/etc. that got
transferred to Frontier.

> If you query the main netblock you get the same info. So if
> you do send out an email to them for the 1000?s of subnets do you
> really think they are going to check each one or just blindly say
> ?yes we are using it?.
>

If they respond at all that would be great!  Right now the important
thing is to get all the e-mail addresses in the POCs to even exist.
The big problem IMHO is rogues like crackers and spammers who are BGP
advertising abandoned resources that have bogus e-mail addresses and
old, invalid business street addresses in them, and using them to
spam and crack with.

> I have, since Monday when I brought this up called some other people
> I know who have had different providers through the years and found
> as of now about a dozen /24?s or larger blocks still pointing to
> places that don?t use them or are not in business anymore. One of
> which is actually a pile of rubble in Veags, but that?s another
> story. As a side note on human nature, nobody else wanted me to put
> up their IP info for fear or ?rocking the boat?.
>

All of that should be reported to hostmaster at arin.net   ARIN may elect 
to do nothing about it at this time espically if history shows that
the providers are regularly requesting new allocations, they just may 
wait until another request comes through from that provider then force
them to clean it up.

Ultimately the failure to fulfill IPv4 allocations by the RIR's is going
to force all the providers with bogus/old/abandoned SWIPS to clean them
up.  I would ask you, does it really matter if Verizon gets more IPv4
post-IPv4 runout by internal housecleaning, or by buying it on the 
transfer market?

Ted

> -Dave
>
>
>
>
>
>
>
>
>
>> /John
>>
>> John Curran President and CEO 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.
>>
>
>
>
>
>
> ________________________________________________________________ Sent
> via the WebMail system at connetrix.com
>
>
>
>
>
> _______________________________________________ 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 jcurran at arin.net  Wed Jul 14 13:41:58 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 14 Jul 2010 13:41:58 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007141249.AA5570768@connetrix.com>
References: <201007141249.AA5570768@connetrix.com>
Message-ID: <D9D4C5EF-FBEB-4F73-BBB5-146F1F11D18F@arin.net>

On Jul 14, 2010, at 12:49 PM, Dave Feuer wrote:

> So if you do send out an email to them for the 1000?s of subnets do you really think they are going to check each one or just blindly say ?yes we are using it?. 

To be very clear, we're emailing the POCs in the WHOIS database
them asking to confirm that the POC contact information is valid
per NRPM 3.6.  None of this relates to the validity or currency
of a particular reassignment record, only the POC contact info.

John Curran
President and CEO
ARIN

p.s.  To answer an related query, the 33% validated rate is the 
      combination of those who click "Correct" and those who 
      clicked "Update".  It is entirely based on response to the
      URLs supplied in the POC validation emails.



From jlewis at lewis.org  Wed Jul 14 13:39:09 2010
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 14 Jul 2010 13:39:09 -0400 (EDT)
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007141249.AA5570768@connetrix.com>
References: <201007141249.AA5570768@connetrix.com>
Message-ID: <Pine.LNX.4.61.1007141312290.5148@soloth.lewis.org>

On Wed, 14 Jul 2010, Dave Feuer  wrote:

> Drifting from the original question which was how much space like this 
> is out there... But, how is that being checked? Here is what I see as 
> the issue, and feel free to call me out if I am way off base. We had IP 
> space from UUnet (remember them) back in the late 90?s till early 2001, 
> we shut it down more than 9 years ago range was 280.236.182.0 /23. If I 
> query the WhoIs now I see the following:
>
> CustName:   Systems & Software
> RegDate:    1998-02-09
> Updated:    2003-05-30
>
> That?s us, so as far as the world knows we have that space. So the IPs 
> went from UUnet to MCI to Verizon through the M&A?s. Last year when we 
> were getting our own allocation I saw this and sent 2 emails to them and 
> then promptly forgot about it. But technically it?s still pointing to us 
> and VZ can use it as a justification to get more IP space. If you query

This makes me wonder how many networks have been doing this as a long term 
game plan for IPv4 runout?  i.e. is this just broken turn-down procedure / 
sloppy IP management, or intentional fraud for the ARIN auditors so they 
can keep qualifying for more space?  When IPv4 runout happens, they may be 
able to keep doing business as usual on IPv4 for years by finally 
recycling all the unused space they've accumulated.

Where I work, the company has reinvented itself multiple times going from 
regional dial-up provider to DSL provider (not much of a change...but both 
burn up lots of IPs), to VOIP provider, to colo/data center provider. 
Each time things have changed, as one type of business was shut down, the 
IPs got freed up and reused.  It's meant that we haven't had to go back to 
ARIN very much for IPs because it seems like each time things have started 
to get tight (getting close to 80% utilization of all our space, not just 
the most recent allocation) the business model changes, space gets freed 
up, and we don't immediately need any more.  Perhaps I've been short 
sighted and should have just kept asking for more space every 6 months.

I've seen the same thing, where large provider IP space associated with a 
trasit T1 stays swipped ~10 years after the T1 was cancelled and the IPs 
are clearly not routed (seen by routing loops in traceroute).

Unfortunnately, I don't think better auditing by ARIN is a feasible 
solution...at least not to the degree that would be necessary to 
differentiate ghost customers from live ones.  i.e. does anyone really 
want the ARIN auditors asking for proof of most recent payment for each 
customer you've swip'd space to?

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

From bicknell at ufp.org  Wed Jul 14 14:12:34 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 14 Jul 2010 11:12:34 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <D9D4C5EF-FBEB-4F73-BBB5-146F1F11D18F@arin.net>
References: <201007141249.AA5570768@connetrix.com>
	<D9D4C5EF-FBEB-4F73-BBB5-146F1F11D18F@arin.net>
Message-ID: <20100714181234.GB46497@ussenterprise.ufp.org>

In a message written on Wed, Jul 14, 2010 at 01:41:58PM -0400, John Curran wrote:
> To be very clear, we're emailing the POCs in the WHOIS database
> them asking to confirm that the POC contact information is valid
> per NRPM 3.6.  None of this relates to the validity or currency
> of a particular reassignment record, only the POC contact info.

So to put a fine point on it, if an ISP listed themselves in all their
swips, in this round they would get all the e-mails, and if they clicked
on all the verification URL's be marked as "clean"?

I'm totally ok with that being the first step.  Emphasis on "first". :)

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100714/fb808ef1/attachment.sig>

From owen at delong.com  Wed Jul 14 14:19:17 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Jul 2010 11:19:17 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007141249.AA5570768@connetrix.com>
References: <201007141249.AA5570768@connetrix.com>
Message-ID: <56BF5A9C-2F89-493A-BA3D-5AB593ADEB05@delong.com>

As i said earlier in the conversation, I encourage you and anyone else who is aware of such situations
to report them to the ARIN Fraud and Abuse process.

That way, ARIN staff can investigate the issue, and, if necessary, initiate a resource review under section
12 of the NRPM to deal with the situation appropriately.

Owen

On Jul 14, 2010, at 9:49 AM, Dave Feuer wrote:

> 
> 
> ---------- Original Message ----------------------------------
> From: John Curran <jcurran at arin.net>
> Date:  Mon, 12 Jul 2010 18:02:14 -0400
> 
>> On Jul 12, 2010, at 2:38 PM, Ted Mittelstaedt wrote:
>> 
>>> Keep in mind that Section 3.6.1 requires ARIN to publish a list of
>>> invalid POCS, so we should have in a year or two a list of subnets
>>> that are "ripe for mining" as they say.  
>> 
>> Ted is right on target here, and we're proceeding with POC 
>> validation at an aggressive rate.  (For more information, see 
>> <https://www.arin.net/resources/services/poc_validation.html>)
>> 
>> We're presently sending out 7500 validation requests each week,
>> and getting just over a 33% update rate on those requests. It's
>> too early to draw conclusions, but there's obviously ample space
>> which presently lacks a responsive contact.  We'll provide a more
>> detailed update on POC validation during the October PPML meeting.
> 
> Drifting from the original question which was how much space like this is out there...
> But, how is that being checked? Here is what I see as the issue, and feel free to call me out if I am way off base.
> We had IP space from UUnet (remember them) back in the late 90?s till early 2001, we shut it down more than 9 years ago range was 280.236.182.0 /23. If I query the WhoIs now I see the following:
> 
> CustName:   Systems & Software
> Address:    One Ames Ct. suite 108
> City:       Plainview
> StateProv:  NY
> PostalCode: 11803
> Country:    US
> RegDate:    1998-02-09
> Updated:    2003-05-30
> 
> NetRange:   208.236.182.0 - 208.236.183.255 
> CIDR:       208.236.182.0/23 
> NetName:    UU-208-236-182
> NetHandle:  NET-208-236-182-0-1
> Parent:     NET-208-192-0-0-1
> NetType:    Reassigned
> Comment:    
> RegDate:    1998-02-09
> Updated:    2003-05-30
> 
> RTechHandle: OA12-ARIN
> RTechName:   UUnet Technologies, Inc., Technologies 
> RTechPhone:  +1-800-900-0241
> RTechEmail:  help4u at verizonbusiness.com 
> 
> OrgAbuseHandle: ABUSE3-ARIN
> OrgAbuseName:   abuse 
> OrgAbusePhone:  +1-800-900-0241
> OrgAbuseEmail:  abuse-mail at verizonbusiness.com
> 
> OrgNOCHandle: OA12-ARIN
> OrgNOCName:   UUnet Technologies, Inc., Technologies 
> OrgNOCPhone:  +1-800-900-0241
> OrgNOCEmail:  help4u at verizonbusiness.com
> 
> OrgTechHandle: JHU140-ARIN
> OrgTechName:   Huffines, Jody 
> OrgTechPhone:  +1-703-886-6093
> OrgTechEmail:  Jody.Huffines at verizonbusiness.com
> 
> OrgTechHandle: SWIPP-ARIN
> OrgTechName:   swipper 
> OrgTechPhone:  +1-800-900-0241
> OrgTechEmail:  swipper at verizonbusiness.com
> 
> <snip>
> 
> 
> That?s us, so as far as the world knows we have that space. So the IPs went from UUnet to MCI to Verizon through the M&A?s. Last year when we were getting our own allocation I saw this and sent 2 emails to them and then promptly forgot about it. But technically it?s still pointing to us and VZ can use it as a justification to get more IP space. If you query the main netblock you get the same info. So if you do send out an email to them for the 1000?s of subnets do you really think they are going to check each one or just blindly say ?yes we are using it?. 
> 
> I have, since Monday when I brought this up called some other people I know who have had different providers through the years and found as of now about a dozen /24?s or larger blocks still pointing to places that don?t use them or are not in business anymore. One of which is actually a pile of rubble in Veags, but that?s another story. As a side note on human nature, nobody else wanted me to put up their IP info for fear or ?rocking the boat?. 
> 
> -Dave
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> /John
>> 
>> John Curran
>> President and CEO
>> 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.
>> 
> 
> 
> 
> 
> 
> ________________________________________________________________
> Sent via the WebMail system at connetrix.com
> 
> 
> 
> 
> 
> _______________________________________________
> 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 tedm at ipinc.net  Wed Jul 14 14:34:45 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Jul 2010 11:34:45 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <20100714181234.GB46497@ussenterprise.ufp.org>
References: <201007141249.AA5570768@connetrix.com>	<D9D4C5EF-FBEB-4F73-BBB5-146F1F11D18F@arin.net>
	<20100714181234.GB46497@ussenterprise.ufp.org>
Message-ID: <4C3E0345.2030306@ipinc.net>


If your definition of the "first step" is "ISP listed themselves in all 
their swips" then I am NOT OK with that!!!

Ted

On 7/14/2010 11:12 AM, Leo Bicknell wrote:
> In a message written on Wed, Jul 14, 2010 at 01:41:58PM -0400, John Curran wrote:
>> To be very clear, we're emailing the POCs in the WHOIS database
>> them asking to confirm that the POC contact information is valid
>> per NRPM 3.6.  None of this relates to the validity or currency
>> of a particular reassignment record, only the POC contact info.
>
> So to put a fine point on it, if an ISP listed themselves in all their
> swips, in this round they would get all the e-mails, and if they clicked
> on all the verification URL's be marked as "clean"?
>
> I'm totally ok with that being the first step.  Emphasis on "first". :)
>
>
>
>
> _______________________________________________
> 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 marty at akamai.com  Wed Jul 14 14:38:39 2010
From: marty at akamai.com (Martin Hannigan)
Date: Wed, 14 Jul 2010 14:38:39 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <56BF5A9C-2F89-493A-BA3D-5AB593ADEB05@delong.com>
Message-ID: <C8637C6F.99F3%marty@akamai.com>




On 7/14/10 2:19 PM, "Owen DeLong" <owen at delong.com> wrote:

> As i said earlier in the conversation, I encourage you and anyone else who is
> aware of such situations
> to report them to the ARIN Fraud and Abuse process.
> 
> That way, ARIN staff can investigate the issue, and, if necessary, initiate a
> resource review under section
> 12 of the NRPM to deal with the situation appropriately.
> 

For actual or suspected fraud, I agree with the overall sentiment of your
post. Much of this discussion doesn't make me suspect fraud with examples
used FWIW. This is operational.

In the case of having resources SWIP'd to an ORG that isn't actually using
them, it would seem very reasonable to instead request that the ORG remove
the SWIP record pointing at you and if they don't in a reasonable period of
time simply ask hostmaster at arin.net to do it via a CC of the request to the
ORG that created the record. This works like a champ (for me).

I don't really know how the fraud process internally works and if it is
actually a fire drill, but why start a one for normal, day to day,
operational issues?


Best,

-M<



From owen at delong.com  Wed Jul 14 14:47:03 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Jul 2010 11:47:03 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <C8637C6F.99F3%marty@akamai.com>
References: <C8637C6F.99F3%marty@akamai.com>
Message-ID: <4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>


On Jul 14, 2010, at 11:38 AM, Martin Hannigan wrote:

> 
> 
> 
> On 7/14/10 2:19 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> As i said earlier in the conversation, I encourage you and anyone else who is
>> aware of such situations
>> to report them to the ARIN Fraud and Abuse process.
>> 
>> That way, ARIN staff can investigate the issue, and, if necessary, initiate a
>> resource review under section
>> 12 of the NRPM to deal with the situation appropriately.
>> 
> 
> For actual or suspected fraud, I agree with the overall sentiment of your
> post. Much of this discussion doesn't make me suspect fraud with examples
> used FWIW. This is operational.
> 
Whether you consider it fraud, abuse, or negligence, SWIPing resources to an
ORG that is no longer using them (or leaving them SWIPped as such) is in
violation of ARIN policy and the RSA. As such, if you know of a situation where
an ORG has done so, the right thing to do is report it through the fraud and
abuse reporting process.

> In the case of having resources SWIP'd to an ORG that isn't actually using
> them, it would seem very reasonable to instead request that the ORG remove
> the SWIP record pointing at you and if they don't in a reasonable period of
> time simply ask hostmaster at arin.net to do it via a CC of the request to the
> ORG that created the record. This works like a champ (for me).
> 
If it's your record, that's a reasonable first step. If it's not your record, but, you
have direct knowledge, it's probably best to simply state that to ARIN and
let ARIN work it out with the ORG in question.

> I don't really know how the fraud process internally works and if it is
> actually a fire drill, but why start a one for normal, day to day,
> operational issues?
> 
It's not a fire drill, and, likely the results from using it would be very much like
the results you obtained from the email to hostmaster with much the same
process. However, I think that the fraud/abuse channel is the appropriate
channel for such a report with the possible exception of a direct report
from the organization to whom the resources are SWIPped.

Owen



From michael.dillon at bt.com  Wed Jul 14 15:03:27 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Jul 2010 20:03:27 +0100
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3DF2D6.7060202@ipinc.net>
References: <201007141249.AA5570768@connetrix.com> <4C3DF2D6.7060202@ipinc.net>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917117D28@EMV01-UKBR.domain1.systemhost.net>

> Technically this is fraud and should be reported to hostmaster at arin.net

It is not fraud, it is sloppy record keeping.

I have worked for several large telcos over the years and every single one
of them had serious problems with slack (or non-existent) decommissioning 
processes. One company that I worked for 10 years ago, did an audit and 
discovered that they were paying $2 million dollars per month for tail
circuits which had been disconnected, sometimes for years. Most of them
were still plugged into router ports which may have made it easier to
identify them. The big question was whether or not there were other tail
circuits that were just dangling from a patch panel after the router port 
had been reused.

While you can generally make a business case for running an audit every year
or two to mop up these decommissioning oversights, these audits often do
not extend to cleaning up all the records, especially not IP address records

If there are any IP address records.

A lot of ISPs, even very big ones, rely far too much on spreadsheets for
this, even when they have commercial IP Address Management tools in place
for their DHCP-related customers. Meanwhile, Fred in engineering has a
spreadsheet that collects errors and oversights and eventually gets lost
when Fred retires.

We really should force large providers to run their own whois directory
rather than SWIPing transactions into ARIN. There could be some sort of
mirroring protocol for ARIN to keep in sync every week or so. This would
be more likely to be connected to a live OSS/BSS system that has up to
date data.

--Michael Dillon



From michael.dillon at bt.com  Wed Jul 14 15:11:58 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 14 Jul 2010 20:11:58 +0100
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>

> Whether you consider it fraud, abuse, or negligence, SWIPing resources
> to an
> ORG that is no longer using them (or leaving them SWIPped as such) is
> in
> violation of ARIN policy and the RSA. As such, if you know of a
> situation where
> an ORG has done so, the right thing to do is report it through the
> fraud and
> abuse reporting process.

Actually I think this is a stupid approach and will just lead to
lawsuits.

Martin Hannigan had the right idea when he suggested that you should

1. send an email to the former provider asking for the record to
   be updated, and
2. send an email to ARIN CCing the former provider, asking ARIN 
   to clean up the provider's mess.

And none of this needs to be reported to fraud or abuse departments
since it is a simple operational issue of exception handling. Mistakes
are common and you need an exception process to collect mistakes and
shepherd them through to correction.

--Michael Dillon



From owen at delong.com  Wed Jul 14 17:44:28 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 14 Jul 2010 14:44:28 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>


On Jul 14, 2010, at 12:11 PM, <michael.dillon at bt.com> wrote:

>> Whether you consider it fraud, abuse, or negligence, SWIPing resources
>> to an
>> ORG that is no longer using them (or leaving them SWIPped as such) is
>> in
>> violation of ARIN policy and the RSA. As such, if you know of a
>> situation where
>> an ORG has done so, the right thing to do is report it through the
>> fraud and
>> abuse reporting process.
> 
> Actually I think this is a stupid approach and will just lead to
> lawsuits.
> 
> Martin Hannigan had the right idea when he suggested that you should
> 
> 1. send an email to the former provider asking for the record to
>   be updated, and
> 2. send an email to ARIN CCing the former provider, asking ARIN 
>   to clean up the provider's mess.
> 
> And none of this needs to be reported to fraud or abuse departments
> since it is a simple operational issue of exception handling. Mistakes
> are common and you need an exception process to collect mistakes and
> shepherd them through to correction.
> 
ARIN doesn't have a fraud or abuse department. The fraud and abuse
complaints to ARIN are handled by Registration Services almost identical
to the way CCing hostmaster as you mention above will get handled.

I don't see how reporting this kind of violation of the RSA through the
ARIN process intended for such reports will result in lawsuits. Could you
please explain that rather bizarre conclusion?

Owen



From tedm at ipinc.net  Wed Jul 14 19:55:05 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Jul 2010 16:55:05 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423917117D28@EMV01-UKBR.domain1.systemhost.net>
References: <201007141249.AA5570768@connetrix.com> <4C3DF2D6.7060202@ipinc.net>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D28@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4C3E4E59.1020108@ipinc.net>



On 7/14/2010 12:03 PM, michael.dillon at bt.com wrote:
>> Technically this is fraud and should be reported to hostmaster at arin.net
>
> It is not fraud, it is sloppy record keeping.
>

If it was true sloppy record keeping then logically the original
e-mail address would have still been on the POC.  The fact that the
e-mail contact address was changed to one at Verizon yet the name of
the defunct customer was NOT changed could be seen as a deliberate
rules violation.

I think we all can agree that a lot of things with IP address keeping
were done by a lot of people in the past who just didn't know the
rules.  Just like millions of people every day break speeding laws
because they don't realize they just passed a speeding sign a quarter
mile back that lowered the speed limit from 45Mph to 35Mph.  Most cops
who pull those people over won't issue a ticket (if they have a clean
record)  But they ARE violating the rules, they ARE committing a traffic
infraction, and the ARE liable for it.

What is called for in this case is ARIN issuing a notice to Verizon to 
correct that particular SWIP, just like in the traffic case what is 
called for is the cop issuing a notice and not writing a ticket for 
going 45 in a 35 zone.

> I have worked for several large telcos over the years and every single one
> of them had serious problems with slack (or non-existent) decommissioning
> processes. One company that I worked for 10 years ago, did an audit and
> discovered that they were paying $2 million dollars per month for tail
> circuits which had been disconnected, sometimes for years. Most of them
> were still plugged into router ports which may have made it easier to
> identify them. The big question was whether or not there were other tail
> circuits that were just dangling from a patch panel after the router port
> had been reused.
>
> While you can generally make a business case for running an audit every year
> or two to mop up these decommissioning oversights, these audits often do
> not extend to cleaning up all the records, especially not IP address records
>
> If there are any IP address records.
>
> A lot of ISPs, even very big ones, rely far too much on spreadsheets for
> this, even when they have commercial IP Address Management tools in place
> for their DHCP-related customers. Meanwhile, Fred in engineering has a
> spreadsheet that collects errors and oversights and eventually gets lost
> when Fred retires.
>
> We really should force large providers to run their own whois directory
> rather than SWIPing transactions into ARIN. There could be some sort of
> mirroring protocol for ARIN to keep in sync every week or so. This would
> be more likely to be connected to a live OSS/BSS system that has up to
> date data.
>

ipplan supposedly has a back end that generates SWIPS.  But it does not
do IPv6

HaCi (http://sourceforge.net/projects/haci/) does both IPv4 and IPv6, 
that's what we use.  But there is no interconnect code to the ARIN WHOIS 
database.  Periodically when I have the time I try to work on some
very kludgy scripts to feed the data to the reference rwhois code
database. (which we also run)

FreeIPdb (http://home.globalcrossing.net/~freeipdb/)  does both IPv4 and
IPv6 - there's an rwhois portion "in development"  (don't hold your 
breath, it's been in development for 4 years now)

Netdot (https://netdot.uoregon.edu/trac/) also manages IP space but 
there is no interconnect code to the ARIN WHOIS database.

All of these are open source.  All work.  And HaCi is in my opinion
the best candidate to add a RESTful interface to.  I would love to
see the ARIN WHOIS developers add one to that code.  I'd be happy to
setup a system for them to use for development that had a running
HaCi install on it.

Ted


From tedm at ipinc.net  Wed Jul 14 20:36:10 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 14 Jul 2010 17:36:10 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3E4E59.1020108@ipinc.net>
References: <201007141249.AA5570768@connetrix.com>
	<4C3DF2D6.7060202@ipinc.net>	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D28@EMV01-UKBR.domain1.systemhost.net>
	<4C3E4E59.1020108@ipinc.net>
Message-ID: <4C3E57FA.8060001@ipinc.net>



On 7/14/2010 4:55 PM, Ted Mittelstaedt wrote:
>
>
> On 7/14/2010 12:03 PM, michael.dillon at bt.com wrote:
>>> Technically this is fraud and should be reported to hostmaster at arin.net
>>
>> It is not fraud, it is sloppy record keeping.
>>
>
> If it was true sloppy record keeping then logically the original
> e-mail address would have still been on the POC. The fact that the
> e-mail contact address was changed to one at Verizon yet the name of
> the defunct customer was NOT changed could be seen as a deliberate
> rules violation.
>
> I think we all can agree that a lot of things with IP address keeping
> were done by a lot of people in the past who just didn't know the
> rules. Just like millions of people every day break speeding laws
> because they don't realize they just passed a speeding sign a quarter
> mile back that lowered the speed limit from 45Mph to 35Mph. Most cops
> who pull those people over won't issue a ticket (if they have a clean
> record) But they ARE violating the rules, they ARE committing a traffic
> infraction, and the ARE liable for it.
>
> What is called for in this case is ARIN issuing a notice to Verizon to
> correct that particular SWIP, just like in the traffic case what is
> called for is the cop issuing a notice and not writing a ticket for
> going 45 in a 35 zone.
>
>> I have worked for several large telcos over the years and every single
>> one
>> of them had serious problems with slack (or non-existent) decommissioning
>> processes. One company that I worked for 10 years ago, did an audit and
>> discovered that they were paying $2 million dollars per month for tail
>> circuits which had been disconnected, sometimes for years. Most of them
>> were still plugged into router ports which may have made it easier to
>> identify them. The big question was whether or not there were other tail
>> circuits that were just dangling from a patch panel after the router port
>> had been reused.
>>
>> While you can generally make a business case for running an audit
>> every year
>> or two to mop up these decommissioning oversights, these audits often do
>> not extend to cleaning up all the records, especially not IP address
>> records
>>
>> If there are any IP address records.
>>
>> A lot of ISPs, even very big ones, rely far too much on spreadsheets for
>> this, even when they have commercial IP Address Management tools in place
>> for their DHCP-related customers. Meanwhile, Fred in engineering has a
>> spreadsheet that collects errors and oversights and eventually gets lost
>> when Fred retires.
>>
>> We really should force large providers to run their own whois directory
>> rather than SWIPing transactions into ARIN. There could be some sort of
>> mirroring protocol for ARIN to keep in sync every week or so. This would
>> be more likely to be connected to a live OSS/BSS system that has up to
>> date data.
>>
>
> ipplan supposedly has a back end that generates SWIPS. But it does not
> do IPv6
>

Correction on this - IPPlan 6.0-Beta apparently has IPv6 support now.

> HaCi (http://sourceforge.net/projects/haci/) does both IPv4 and IPv6,
> that's what we use. But there is no interconnect code to the ARIN WHOIS
> database. Periodically when I have the time I try to work on some
> very kludgy scripts to feed the data to the reference rwhois code
> database. (which we also run)
>
> FreeIPdb (http://home.globalcrossing.net/~freeipdb/) does both IPv4 and
> IPv6 - there's an rwhois portion "in development" (don't hold your
> breath, it's been in development for 4 years now)
>
> Netdot (https://netdot.uoregon.edu/trac/) also manages IP space but
> there is no interconnect code to the ARIN WHOIS database.
>
> All of these are open source. All work. And HaCi is in my opinion
> the best candidate to add a RESTful interface to. I would love to
> see the ARIN WHOIS developers add one to that code. I'd be happy to
> setup a system for them to use for development that had a running
> HaCi install on it.
>
> Ted
> _______________________________________________
> 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 mysidia at gmail.com  Thu Jul 15 00:43:24 2010
From: mysidia at gmail.com (James Hess)
Date: Wed, 14 Jul 2010 23:43:24 -0500
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
	<78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
Message-ID: <AANLkTimJESUfbnCiBjbiRKugvgk3KVkwGlRLVN1JgCkL@mail.gmail.com>

On Wed, Jul 14, 2010 at 4:44 PM, Owen DeLong <owen at delong.com> wrote:
> On Jul 14, 2010, at 12:11 PM, <michael.dillon at bt.com> wrote:
[snip]
Indeed "Abuse"   is such a loaded word to use for a possible mistake.
 I  would suggest the phrase  "Fraud and Abuse Process"  be replaced
with:    Fraud and  Policy Violations Reporting Process
Still,  at a certain extent,  certain mistakes are just negligence..
ARIN orgs  have a responsibility to make some reasonable efforts to
follow policy and keep their assignment records accurate.    It
cannot be excusable (really) to leave a stale record in place for THAT
many years.


I think it should be considered whether the POC validation could be
reasonably extended to include re-assignment validation.
For example,  every year on the anniversary date of each assignment,
e-mail the POCs  of orgs re-assignments are made TO, requesting
verification.     The e-mail should prompt to click on a link, which
should be guarded by a CAPTCHA or other means of human verification,
and require them to say "Yes" to a statement certifying this
assignment is active, the organization named in the re-assignment  is
using the address space,
AND  the POC receiving the e-mail is currently an  authorized contact
for that organization's networks.

If  an  ORG has multiple assignments to them,  the web page  should
list   them all,  with a checkbox by each one,   so  they can  verify
them all at once,  and avoid receiving more than 1  e-mail message per
year  (by re-verifying each assignment to them on the same date).

If there is no response within a month,  add a  "Status: Unverified"
to the re-assignment in WHOIS, while still publishing it.

And do not allow that re-assignment to be counted as utilized by the
org assigning it,   until the matter has been cleared up.


--
-Mysid


From michael.dillon at bt.com  Thu Jul 15 03:58:07 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 15 Jul 2010 08:58:07 +0100
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
	<78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917117DFA@EMV01-UKBR.domain1.systemhost.net>

> ARIN doesn't have a fraud or abuse department. 

The why do you keep making such a big deal about reporting things to ARIN's
fraud and abuse department?

>The fraud and abuse
> complaints to ARIN are handled by Registration Services almost
> identical
> to the way CCing hostmaster as you mention above will get handled.

Then you should drop the inflamatory language and just tell people to
send an email to Registration Services via the hostmaster email 
address.

> I don't see how reporting this kind of violation of the RSA through the
> ARIN process intended for such reports will result in lawsuits. Could
> you
> please explain that rather bizarre conclusion?

You, as an ARIN official, keep making comments about how these operational
errors are FRAUD. That is getting close to libel and slander. If lots
of others pick up on this language it is only a matter of time before
it spreads and someone makes serious allegations of fraud that threaten
to damage someone's business. At that point, I would expect to see lawsuits
and they would naturally include you, the ARIN official who started it all,
and ARIN itself.

Can we just drop this whole "big stick" attitude and focus on carrots?

ARIN has never made it easy to clean up this kind of thing. If ARIN would
simply engage with some of the larger providers and ask what could be
done to help them audit their IP address records, and clean up leftover
addresses from incomplete decommissioning processes, then I think you
would get much, much further than with threats.

It would also provide an opportunity for providers to share best practice
tips on address auditing and perhaps develop some tools which could be
run internally on management networks to identify unused address blocks.

--Michael Dillon



From michael.dillon at bt.com  Thu Jul 15 04:08:48 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 15 Jul 2010 09:08:48 +0100
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <AANLkTimJESUfbnCiBjbiRKugvgk3KVkwGlRLVN1JgCkL@mail.gmail.com>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
	<78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
	<AANLkTimJESUfbnCiBjbiRKugvgk3KVkwGlRLVN1JgCkL@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917117E15@EMV01-UKBR.domain1.systemhost.net>

> Indeed "Abuse"   is such a loaded word to use for a possible mistake.
>  I  would suggest the phrase  "Fraud and Abuse Process"  be replaced
> with:    Fraud and  Policy Violations Reporting Process

What is wrong with calling a spade, a spade?

It is in fact, the "Data Cleansing Process" because its goal is
to cleanse the database of errors and ommissions which have
accumulated over the years.

> Still,  at a certain extent,  certain mistakes are just negligence..
> ARIN orgs  have a responsibility to make some reasonable efforts to
> follow policy and keep their assignment records accurate.    It
> cannot be excusable (really) to leave a stale record in place for THAT
> many years.

You have no idea how hard it is to keep databases in sync in a large
company that has grown through acquisition after acquisition. It takes
a lot of effort and regular data cleansing audits. 

In addition, customers get migrated to new infrastructure, old address
blocks get repurposed. It is very easy to get into a situation where
you can identify that an IP address is in fact in use, but the record
is incorrect because it identifies a different use. Now you know that
you shouldn't delete the record, but in the absence of proper records
it is hard to know what the address block is being used for.

In addition, this is *NOT* the Internet addressing organization. IP addresses
are not exclusively for use on the Internet. It is perfectly legitimate
for an organization to use IP addresses on networks which do not peer
with the public Internet or exchange traffic with the Internet. So you
and I have no way of knowing whether that address block is in fact
unused. We can only say that it has a high probability of being
incorrectly recorded, but the outcome may be to change the record 
to show that it is used for infrastructure or some management network
or some internal lab that is intentionally not routes to the Internet.

--Michael Dillon



From owen at delong.com  Thu Jul 15 05:26:37 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 15 Jul 2010 02:26:37 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423917117DFA@EMV01-UKBR.domain1.systemhost.net>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
	<78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117DFA@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <72B3A3E4-2E82-4406-A05D-B7EC4B6A6DE2@delong.com>


On Jul 15, 2010, at 12:58 AM, <michael.dillon at bt.com> wrote:

>> ARIN doesn't have a fraud or abuse department. 
> 
> The why do you keep making such a big deal about reporting things to ARIN's
> fraud and abuse department?
> 
I never used the term fraud and abuse department.

I used the term fraud and abuse reporting process. This is a documented
process which is available through the ARIN web site and which is handled
by the registration services department.

>> The fraud and abuse
>> complaints to ARIN are handled by Registration Services almost
>> identical
>> to the way CCing hostmaster as you mention above will get handled.
> 
> Then you should drop the inflamatory language and just tell people to
> send an email to Registration Services via the hostmaster email 
> address.
> 
Again, you are putting different words in my mouth than what I sand and
then complaining about the new words.

>> I don't see how reporting this kind of violation of the RSA through the
>> ARIN process intended for such reports will result in lawsuits. Could
>> you
>> please explain that rather bizarre conclusion?
> 
> You, as an ARIN official, keep making comments about how these operational
> errors are FRAUD. That is getting close to libel and slander. If lots
> of others pick up on this language it is only a matter of time before
> it spreads and someone makes serious allegations of fraud that threaten
> to damage someone's business. At that point, I would expect to see lawsuits
> and they would naturally include you, the ARIN official who started it all,
> and ARIN itself.
> 
You see them as operational errors. I see them as operational error until
reports to said org go unheeded and they willfully fail to correct the
situation. At that point, they become abuse. When said org then gets
more space based on this non-existent utilization, it becomes fraud.
 
> Can we just drop this whole "big stick" attitude and focus on carrots?
> 
No, at this point, given the willful nature of at least some of the violations
I am aware of, I'm not in the mood to give carrots to those ORGs and I
think it is time to start wielding the stick.

> ARIN has never made it easy to clean up this kind of thing. If ARIN would
> simply engage with some of the larger providers and ask what could be
> done to help them audit their IP address records, and clean up leftover
> addresses from incomplete decommissioning processes, then I think you
> would get much, much further than with threats.
> 
Sure it is.... You simply submit a SWIP delete template.

I worked for a large provider and we completely automated this process.
Our registration system would automatically send in SWIPs for all address
registration transactions. It only took a few lines of PERL code to make
it all work. It even parsed the ARIN responses and notified a human if
there was a problem.

> It would also provide an opportunity for providers to share best practice
> tips on address auditing and perhaps develop some tools which could be
> run internally on management networks to identify unused address blocks.
> 
That doesn't seem like it would be all that hard under the current situation
and should be even easier when ARIN launches RESTful whois, assuming
they can make it work this time.

Owen



From spiffnolee at yahoo.com  Thu Jul 15 06:41:33 2010
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 15 Jul 2010 03:41:33 -0700 (PDT)
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <201007141249.AA5570768@connetrix.com>
References: <201007141249.AA5570768@connetrix.com>
Message-ID: <935117.37238.qm@web63302.mail.re1.yahoo.com>



I shouldn't get involved in this.

[RE: Verizon SWIP elided]
There's nothing wrong with an ISP providing their contact information 
on the record.  They do need to clean up their database.

History:
Policy proposal 2002-8 https://www.arin.net/policy/proposals/2002_8.html
said you could privatize some contact information, as long as there was at 
least one responsive contact.  The text now found in NRPM 3.3 is terser.
It was discussed at the public policy meeting 
https://www.arin.net/participate/meetings/reports/ARIN_X/ppm_minutes.html#2002_8

The intent of this policy, as I recall, was to ensure that there was at least 
one responsive contact, where in many cases the end-user was not a 
network administrator, and would not be able to respond to reports of 
network incidents.  There was no debate on the mailing list, and it was
clear from the discussion (it passed 53-0) that every ISP intended to 
substitute their own NOC info for their customers, except when the
customer had a good contact.

So UUNET provided NOC info instead of customer info.  I made that 
decision.  I made it based on my understanding of policy and best 
practice at the time.

Also around that time, I staffed up a "disconnect" team at UUNET
(then MCI/WorldCom).  I had five full-time people dedicated to 
clearing out records from disconnecting customers.  It's hard work;
you have to check every single record of the customer to see whether
the customer has truly disconnected, or just moved, and whether they
or somebody else is now using that resource (port, address, domain).
It takes an hour to clean out records from one customer.
Although I was able to show that we saved money by dedicating
staff to it, this was the time of layoffs, following WorldCom's fraud.
The team was understaffed.  Not much later, I quit.

Lee



> Drifting from the original  question which was how much space like this is out 
>there...
> But, how is that  being checked? Here is what I see as the issue, and feel free 
>to call me out if  I am way off base.
> We had IP space from UUnet (remember them) back in the  late 90?s till early 
>2001, we shut it down more than 9 years ago range was  280.236.182.0 /23. If I 
>query the WhoIs now I see the  following:
> 
> CustName:   Systems & Software
> Address:     One Ames Ct. suite 108
> City:        Plainview
> StateProv:  NY
> PostalCode: 11803
> Country:     US
> RegDate:    1998-02-09
> Updated:     2003-05-30
> 
> NetRange:   208.236.182.0 - 208.236.183.255 
> CIDR:       208.236.182.0/23 
> NetName:     UU-208-236-182
> NetHandle:  NET-208-236-182-0-1
> Parent:      NET-208-192-0-0-1
> NetType:    Reassigned
> Comment:    
> RegDate:    1998-02-09
> Updated:     2003-05-30
> 
> RTechHandle: OA12-ARIN
> RTechName:   UUnet  Technologies, Inc., Technologies 
> RTechPhone:   +1-800-900-0241
> RTechEmail:  help4u at verizonbusiness.com 
> 
> OrgAbuseHandle: ABUSE3-ARIN
> OrgAbuseName:   abuse 
> OrgAbusePhone:  +1-800-900-0241
> OrgAbuseEmail:  abuse-mail at verizonbusiness.com
> 
> OrgNOCHandle:  OA12-ARIN
> OrgNOCName:   UUnet Technologies, Inc., Technologies 
> OrgNOCPhone:  +1-800-900-0241
> OrgNOCEmail:  help4u at verizonbusiness.com
> 
> OrgTechHandle:  JHU140-ARIN
> OrgTechName:   Huffines, Jody 
> OrgTechPhone:   +1-703-886-6093
> OrgTechEmail:  Jody.Huffines at verizonbusiness.com
> 
> OrgTechHandle:  SWIPP-ARIN
> OrgTechName:   swipper 
> OrgTechPhone:   +1-800-900-0241
> OrgTechEmail:  swipper at verizonbusiness.com
> 
> <snip>
> 
> 
> That?s  us, so as far as the world knows we have that space. So the IPs went 
>from UUnet  to MCI to Verizon through the M&A?s. Last year when we were getting 
>our own  allocation I saw this and sent 2 emails to them and then promptly 
>forgot about  it. But technically it?s still pointing to us and VZ can use it as 
>a  justification to get more IP space. If you query the main netblock you get 
>the  same info. So if you do send out an email to them for the 1000?s of subnets 
>do  you really think they are going to check each one or just blindly say ?yes 
>we  are using it?. 
>
> 
> I have, since Monday when I brought this up called some  other people I know 
>who have had different providers through the years and found  as of now about a 
>dozen /24?s or larger blocks still pointing to places that  don?t use them or 
>are not in business anymore. One of which is actually a pile  of rubble in 
>Veags, but that?s another story. As a side note on human nature,  nobody else 
>wanted me to put up their IP info for fear or ?rocking the boat?. 
>
> 
> -Dave
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >/John
> >
> >John  Curran
> >President and  CEO
> >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.
> >
> 
> 
> 
> 
> 
> ________________________________________________________________
> Sent  via the WebMail system at connetrix.com
> 
> 
> 
>                    
> 
> _______________________________________________
> 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 michael.dillon at bt.com  Thu Jul 15 08:21:12 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 15 Jul 2010 13:21:12 +0100
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <72B3A3E4-2E82-4406-A05D-B7EC4B6A6DE2@delong.com>
References: <C8637C6F.99F3%marty@akamai.com>
	<4FEB6E49-CF61-4584-AB52-D941A305B37F@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117D2C@EMV01-UKBR.domain1.systemhost.net>
	<78C6B6D3-7857-4B7C-AE35-D93E5E0B0DF0@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423917117DFA@EMV01-UKBR.domain1.systemhost.net>
	<72B3A3E4-2E82-4406-A05D-B7EC4B6A6DE2@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917117FC0@EMV01-UKBR.domain1.systemhost.net>

> I worked for a large provider and we completely automated this process.
> Our registration system would automatically send in SWIPs for all
> address
> registration transactions. It only took a few lines of PERL code to
> make
> it all work. It even parsed the ARIN responses and notified a human if
> there was a problem.

You only THINK that you automated it. SWIP transactions are emails. What
happens when some of them go astray. You system thinks it has updated
ARIN's db but it hasn't. And your db has deleted the record so that
if someone is notified of a problem, they don't know what to do. They
have never seen a SWIP transaction and there is now no way in the system
for them to delete the non-existent customer.

Maybe somebody bypassed your tool and deleted a bunch of customers 
from the DB with a maintenance script after an audit. This kind of
thing happens all the time, and nobody notices that they missed the
SWIP process until years later, someone with clue comes along.

Keeping multiple databases in sync is hard work unless you have a system
that is specifically designed for that synchronization job. ARIN's system
is not designed for this. SWIP was a crude hack, and although the new
system is a reasonably well engineered system for transaction processing,
it is *NOT* a database synchronisation system.

> > It would also provide an opportunity for providers to share best
> practice
> > tips on address auditing and perhaps develop some tools which could
> be
> > run internally on management networks to identify unused address
> blocks.
> >
> That doesn't seem like it would be all that hard under the current
> situation

To my knowledge ARIN has never invited people to work on this kind
of thing. Why is there not an ARIN sponsored project for an open
source IP address records system? In such a project you could define
a standard database schema, and build a standard module for syncing
your ISP records with ARIN's whois directory. Then other IPAM folks
could copy and adapt that syncing module.

--Michael Dillon



From stephen at sprunk.org  Sat Jul 17 23:22:51 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sat, 17 Jul 2010 22:22:51 -0500
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C3C0C56.507@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>
	<4C3BD1E2.2030004@matthew.at> <4C3C0C56.507@ipinc.net>
Message-ID: <4C42738B.1040605@sprunk.org>

On 13 Jul 2010 01:48, Ted Mittelstaedt wrote:
> Before getting too worked up, please keep in mind that the fact that
> the mail message was ACCEPTED by your mail system and not immediately
> bounced, indicates that there's a valid e-mail box there.

No, it does not.  I'm aware of at least one firewall appliance that
"accepts" all mail submitted to any address and, after doing some
security checks, blindly forwards it to an internal smarthost (which
might or might not send a DSN if the address is invalid).  I'm not sure
whether this is an RFC violation, but either way it's existence proof
that the SMTP response code that ARIN receives is _not_ a reliable
indication that the address used does in fact correspond to an actual
mailbox.

And, of course, we all know about mailboxes that reside at /dev/null,
spam filtering systems, old mailboxes for ex-employees, etc. that mean
some (unknown) fraction of mail never gets seen by a human even if the
address _does_ have a valid mailbox of some sort, so validity in that
sense is a meaningless measure anyway.

> I'd hazard a guess that if you didn't click on the link at all that
> ARIN is going to still consider the POC  "most likely valid".

Why would they?  They sent an email and the intended recipient didn't
click one of the links.  Either the message never reached the recipient
or the recipient disregarded it, which indicates that email address is
not a reliable means of contacting them--and that's what we're trying to
determine, isn't it?

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/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100717/a0c3a593/attachment.p7s>

From mysidia at gmail.com  Sat Jul 17 23:58:28 2010
From: mysidia at gmail.com (James Hess)
Date: Sat, 17 Jul 2010 22:58:28 -0500
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C42738B.1040605@sprunk.org>
References: <004801cb21ea$89159cf0$9b40d6d0$@com> <4C3B610D.9040108@ipinc.net>
	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BB510.1010600@ipinc.net> <4C3BCFCD.5020600@ipv6canada.com>
	<4C3BD1E2.2030004@matthew.at> <4C3C0C56.507@ipinc.net>
	<4C42738B.1040605@sprunk.org>
Message-ID: <AANLkTilWuYZKW5N8D5aZM6YEFlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>

On Sat, Jul 17, 2010 at 10:22 PM, Stephen Sprunk <stephen at sprunk.org> wrote:
> On 13 Jul 2010 01:48, Ted Mittelstaedt wrote:
>> Before getting too worked up, please keep in mind that the fact that
>> the mail message was ACCEPTED by your mail system and not immediately
>> bounced, indicates that there's a valid e-mail box there.
> No, it does not. ?I'm aware of at least one firewall appliance that
> "accepts" all mail submitted to any address and, after doing some
> security checks, blindly forwards it to an internal smarthost (which

I will agree some spam traps  catch mail sent to non-existent e-mail addresses
("domain catch-all e-mail rule"),  and pretend that delivery has
succeeded,  while discarding the message.

It is possible the e-mail address was deleted,  or the mailbox is no
longer checked by a human (abandoned but still existent mailbox).

It may also be possible that a completely different new person now
owns the mailbox.
ex:  mailbox was deleted,  6-12 months later, a new person  with a
similar name  joined the organization,
and they would  end up with the exact same e-mail address that used to
belong to a contact.

>> I'd hazard a guess that if you didn't click on the link at all that
>> ARIN is going to still consider the POC ?"most likely valid".


What point would there be even  sending the link if  a user not
clicking on it would fail to indicate that the record was invalid?

It would make about as much sense as sending them a link to click on
if  "their e-mail address was no longer operational"

A contact that cannot  even act on a request to verify themselves
(especially if multiple reminders to verify are sent),   is not a
responsive contact..


-- 
-JH


From tedm at ipinc.net  Mon Jul 19 16:41:07 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 19 Jul 2010 13:41:07 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C42738B.1040605@sprunk.org>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>
	<4C3C0C56.507@ipinc.net> <4C42738B.1040605@sprunk.org>
Message-ID: <4C44B863.6040605@ipinc.net>



On 7/17/2010 8:22 PM, Stephen Sprunk wrote:
> On 13 Jul 2010 01:48, Ted Mittelstaedt wrote:
>> Before getting too worked up, please keep in mind that the fact that
>> the mail message was ACCEPTED by your mail system and not immediately
>> bounced, indicates that there's a valid e-mail box there.
>
> No, it does not.  I'm aware of at least one firewall appliance that
> "accepts" all mail submitted to any address and, after doing some
> security checks, blindly forwards it to an internal smarthost (which
> might or might not send a DSN if the address is invalid).

That kind of architecture is unworkable in practice and I'll tell you
why.  Today spammers figure out valid e-mail addresses by mailing 
domains and waiting for an error 500.  If this firewall appliance 
accepts everything then every address query the spammer sends will be
considered valid, thus the spammer will have hundreds of thousands of
bogus e-mail addresses for that domain - and when they start spamming
then your going to melt the internal smarthost down.

> I'm not sure
> whether this is an RFC violation, but either way it's existence proof
> that the SMTP response code that ARIN receives is _not_ a reliable
> indication that the address used does in fact correspond to an actual
> mailbox.
>

I think your confused in any case.  All the firewall appliances I've 
seen that forward mail are written to use LDAP or Microsoft Networking
protocols or just SMTP queries on the smarthost to verify the incoming
e-mail recipient address BEFORE dropping the SMTP handshake.

> And, of course, we all know about mailboxes that reside at /dev/null,
> spam filtering systems, old mailboxes for ex-employees, etc. that mean
> some (unknown) fraction of mail never gets seen by a human even if the
> address _does_ have a valid mailbox of some sort, so validity in that
> sense is a meaningless measure anyway.
>

I have to disagree here.  The WHOIS standard requires contact info, it
does NOT require that valid contact info is only people who actually
get off their fat ass and RESPOND to e-mails.

Technically if I issue a SWIP that has a POC with an e-mail address that
goes to an e-mail box that I never respond to, never read, then that IS
a valid e-mail address and I'm good under the NRPM.

Nobody than me would LOVE to see an adjustment to the RSA and NRPM that 
mandated that recipients of address blocks respond to legitimate 
e-mails.  So, I actually LIKE what ARIN is doing with requiring e-mail
links to be responded to.  But, I'm not naieve enough to think that
anywhere in the NRPM or RSA that there's language that explicitly gives
ARIN the right to do POC verification by requiring a human response.
My gut feel is that sooner or later some bozo out there is going to
sue ARIN claiming that they are overstepping their authority to do
POC verification, so the earlier that we can head that off by modifying
language in the NRPM and RSA that defines what a valid contact is, the
happier I'll be.

But clearly there's a lot of people out there who would consider the
parent ISP to be "valid POC contact info" and would fight any attempt
to mandate real addresses and e-mail addresses on the SWIP POCs, so
good luck with getting any requirements for specifying valid contacts
passed.

>> I'd hazard a guess that if you didn't click on the link at all that
>> ARIN is going to still consider the POC  "most likely valid".
>
> Why would they?  They sent an email and the intended recipient didn't
> click one of the links.  Either the message never reached the recipient
> or the recipient disregarded it, which indicates that email address is
> not a reliable means of contacting them--and that's what we're trying to
> determine, isn't it?
>

Unfortunately, no.  If you can point to language in the RSA or NRPM that
disallows e-mail addresses in POCs that go to recipients that disregard
them, please do so.  I would love to be corrected on that.

Ted

> S
>
>
>
>
> _______________________________________________
> 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 tedm at ipinc.net  Mon Jul 19 16:47:08 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 19 Jul 2010 13:47:08 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <AANLkTilWuYZKW5N8D5aZM6YEFlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>
	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>
	<4C3C0C56.507@ipinc.net>	<4C42738B.1040605@sprunk.org>
	<AANLkTilWuYZKW5N8D5aZM6YEFlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>
Message-ID: <4C44B9CC.2000208@ipinc.net>



On 7/17/2010 8:58 PM, James Hess wrote:

>
>>> I'd hazard a guess that if you didn't click on the link at all that
>>> ARIN is going to still consider the POC  "most likely valid".
>
>
> What point would there be even  sending the link if  a user not
> clicking on it would fail to indicate that the record was invalid?
>
> It would make about as much sense as sending them a link to click on
> if  "their e-mail address was no longer operational"
>
> A contact that cannot  even act on a request to verify themselves
> (especially if multiple reminders to verify are sent),   is not a
> responsive contact..
>

I would ask, what is the point of filling out a SWIP at all if the
ISP that is doing the filling out is simply going to substitute their
OWN contact info in place of the real contact info of the actual user
of the address block?

I would also ask what is the point of even having a WHOIS database if
ISPs are going to be allowed to do that?

Yet we have a lot of people here who claim that this is valid practice.

In my opinion, there's a LOT that ought to be done to increase
disclosure in address assignments.  If this had been mandated from day 1
then it wouldn't be a problem now.  After all if you purchase property
you are required to fill out your real contact name on the deed at the
county and anybody can go look at it.  I don't see that usage of IP
addressing is any different.

Ted


From jradel at vantage.com  Mon Jul 19 16:55:49 2010
From: jradel at vantage.com (Jon Radel)
Date: Mon, 19 Jul 2010 16:55:49 -0400
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C44B9CC.2000208@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>	<4C3C0C56.507@ipinc.net>	<4C42738B.1040605@sprunk.org>	<AANLkTilWuYZKW5N8D5aZM6YEFlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>
	<4C44B9CC.2000208@ipinc.net>
Message-ID: <4C44BBD5.40309@vantage.com>



On 7/19/10 4:47 PM, Ted Mittelstaedt wrote:
> After all if you purchase property you are required to fill out your 
> real contact name on the deed at the county and anybody can go look at 
> it. I don't see that usage of IP addressing is any different.
So it's ok with you if the trusts that own "my" real property, and are 
the legal entities in the public records,  were to be the contacts in 
ARIN records?  I don't think that's a step forward; you might not want 
to depend on that analogy.

-- 
Jon Radel



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

From kkargel at polartel.com  Mon Jul 19 17:21:38 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 19 Jul 2010 16:21:38 -0500
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C44B863.6040605@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>
	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>
	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>
	<4C3BD1E2.2030004@matthew.at>	<4C3C0C56.507@ipinc.net>
	<4C42738B.1040605@sprunk.org> <4C44B863.6040605@ipinc.net>
Message-ID: <8695009A81378E48879980039EEDAD288C0497FB@MAIL1.polartel.local>

> But clearly there's a lot of people out there who would consider the
> parent ISP to be "valid POC contact info" and would fight any attempt
> to mandate real addresses and e-mail addresses on the SWIP POCs, so
> good luck with getting any requirements for specifying valid contacts
> passed.
> 
>  
> Ted
> 
We have been through this discussion numerous times.  IMHO the ISP is not only sometimes a valid contact but is often the most effective contact. 

There are many many organizations out who have not got a clue and who are operating networks with IP's SWIP'ed to them.  If you contact the actual operator they will not know what you are talking about and may refer you back to their "Internet Contractor" who will refer you back to the originating ISP who will explain things to the "Internet Contractor" and refer you back to them again.  

There is nothing wrong with listing the customer company name but with contact info for the "contracted" cognizant administrator.  

$.02


From tedm at ipinc.net  Mon Jul 19 17:27:56 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 19 Jul 2010 14:27:56 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C44BBD5.40309@vantage.com>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>	<4C3C0C56.507@ipinc.net>	<4C42738B.1040605@sprunk.org>	<AANLkTilWuYZKW5N8D5aZM6YEFlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>	<4C44B9CC.2000208@ipinc.net>
	<4C44BBD5.40309@vantage.com>
Message-ID: <4C44C35C.60708@ipinc.net>



On 7/19/2010 1:55 PM, Jon Radel wrote:
>
>
> On 7/19/10 4:47 PM, Ted Mittelstaedt wrote:
>> After all if you purchase property you are required to fill out your
>> real contact name on the deed at the county and anybody can go look at
>> it. I don't see that usage of IP addressing is any different.
> So it's ok with you if the trusts that own "my" real property, and are
> the legal entities in the public records, were to be the contacts in
> ARIN records? I don't think that's a step forward; you might not want to
> depend on that analogy.
>

Why not?  The trusts that own "your"
real property are responsible for paying taxes on it, they are
entities separate from the government.

The government allocated them land, and put their names on it
via a deed, much the way an ISP allocates customers IP addresses,
and puts the customers name on those allocations via SWIP.

If your trust was allowed to substitute the county government's
name on your deed for "privacys" sake then I'd think there was
a problem.


Ted

>
>
> _______________________________________________
> 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 tedm at ipinc.net  Mon Jul 19 17:43:19 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 19 Jul 2010 14:43:19 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <8695009A81378E48879980039EEDAD288C0497FB@MAIL1.polartel.local>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.net>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.net>	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>	<4C3C0C56.507@ipinc.net>
	<4C42738B.1040605@sprunk.org> <4C44B863.6040605@ipinc.net>
	<8695009A81378E48879980039EEDAD288C0497FB@MAIL1.polartel.local>
Message-ID: <4C44C6F7.90505@ipinc.net>



On 7/19/2010 2:21 PM, Kevin Kargel wrote:
>> But clearly there's a lot of people out there who would consider
>> the parent ISP to be "valid POC contact info" and would fight any
>> attempt to mandate real addresses and e-mail addresses on the SWIP
>> POCs, so good luck with getting any requirements for specifying
>> valid contacts passed.
>>
>>
>> Ted
>>
> We have been through this discussion numerous times.  IMHO the ISP is
> not only sometimes a valid contact but is often the most effective
> contact.
>
> There are many many organizations out who have not got a clue and who
> are operating networks with IP's SWIP'ed to them.  If you contact the
> actual operator they will not know what you are talking about and may
> refer you back to their "Internet Contractor" who will refer you back
> to the originating ISP who will explain things to the "Internet
> Contractor" and refer you back to them again.
>
> There is nothing wrong with listing the customer company name but
> with contact info for the "contracted" cognizant administrator.
>

The network has a technical contact field which is specifically for
putting the clueful person there.  If that's the ISP then that's
fine.  But the SWIP POC needs to be the actual entity that got the
IP address block.  SWIPS are used for justification for more addressing
and unless the company name is very well known "Ford, GM, Coca Cola"
then it's not going to be easy or possible to audit the SWIPS for 
validity for justification for more numbering.  The street address of 
the company needs to be on the SWIP at the very least.  Whether you also 
want to put the ISP's e-mail address under the company POC in addition 
to the technical contact is IMHO a grey area, but that isn't the point 
of the POC verification.  All the POC verification project is currently 
requiring is that whatever e-mail address IS placed in the POC, it needs 
to be valid, because whoever is on the end of that e-mail
address is supposed to certify that the entire POC itself is correct.

As you say we have been through this discussion.  What I just said is
ARIN policy.  If you had ever asked for additional numbering blocks
from ARIN you would have been told that by them.

Ted

> $.02
>


From terry.l.davis at boeing.com  Mon Jul 19 18:21:54 2010
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 19 Jul 2010 15:21:54 -0700
Subject: [arin-ppml] How bad is it really?
In-Reply-To: <4C44C35C.60708@ipinc.net>
References: <004801cb21ea$89159cf0$9b40d6d0$@com>	<4C3B610D.9040108@ipinc.ne
	t>	<F7E8C8EA-3744-4F91-B04C-4A0230DD7299@arin.net>	<4C3BB510.1010600@ipinc.
	net>	<4C3BCFCD.5020600@ipv6canada.com>	<4C3BD1E2.2030004@matthew.at>	<4C3C0
	C56.507@ipinc.net>	<4C42738B.1040605@sprunk.org>	<AANLkTilWuYZKW5N8D5aZM6YE
	FlrK8jsQ7iKlaQ1w-cUw@mail.gmail.com>
	<4C44B9CC.2000208@ipinc.net><4C44BBD5.40309@vantage.com>
	<4C44C35C.60708@ipinc.net>
Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516E41A71@XCH-NW-05V.nw.nos.boeing.com>


Just an FYI, the accuracy of the SWIPs is becoming a big issue at the ICANN level and to all manner of nation/state law enforcement around the globe.

I'd almost guarantee you that "they will become absolutely accurate"; global organized crime has seen to that!  I think the open issue is who will be able to access that information and how much of it they will be able to view.

My $0.02....

Take care
Terry
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
> Sent: Monday, July 19, 2010 2:28 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] How bad is it really?
> 
> 
> 
> On 7/19/2010 1:55 PM, Jon Radel wrote:
> >
> >
> > On 7/19/10 4:47 PM, Ted Mittelstaedt wrote:
> >> After all if you purchase property you are required to 
> fill out your
> >> real contact name on the deed at the county and anybody 
> can go look at
> >> it. I don't see that usage of IP addressing is any different.
> > So it's ok with you if the trusts that own "my" real 
> property, and are
> > the legal entities in the public records, were to be the contacts in
> > ARIN records? I don't think that's a step forward; you 
> might not want to
> > depend on that analogy.
> >
> 
> Why not?  The trusts that own "your"
> real property are responsible for paying taxes on it, they are
> entities separate from the government.
> 
> The government allocated them land, and put their names on it
> via a deed, much the way an ISP allocates customers IP addresses,
> and puts the customers name on those allocations via SWIP.
> 
> If your trust was allowed to substitute the county government's
> name on your deed for "privacys" sake then I'd think there was
> a problem.
> 
> 
> Ted
> 
> >
> >
> > _______________________________________________
> > 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 info at arin.net  Tue Jul 20 14:11:30 2010
From: info at arin.net (Member Services)
Date: Tue, 20 Jul 2010 14:11:30 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2010
Message-ID: <4C45E6D2.8070307@arin.net>

In accordance with the ARIN Policy Development Process (PDP), the ARIN
Advisory Council (AC) held a meeting on 15 July 2010 and made decisions
about several draft policies and proposals.

The AC recommended that the ARIN Board of Trustees adopt the following
draft policy:

   2010-1: Waiting List for Unmet IPv4 Requests

The AC selected the following proposals as draft policies for adoption
discussion online and at the ARIN XXVI Public Policy Meeting in Atlanta.
Each draft policy will be posted shortly to the PPML.

   113. IPv6 for 6rd
   115. Global Policy for IPv4 Allocations by the IANA Post Exhaustion
   117. Required Resource Reviews
   118. IPv6 Subsequent Allocation

The AC decided not to select Proposal 109 as a draft policy at this time:

   109. Standardize IP Reassignment Registration Requirements

Regarding Proposal 109, the AC would really like to see the sentiments
in this proposal re-surface in bite-size pieces. SWIP requirements, both
IPv4 and IPv6, the distinction of residential customers, the utilization
requirements for subsequent allocations, and customer privacy are all
good topics, but agreement in some will be held up by any disagreements
on the others when trying to address them as one.

The AC abandoned the following proposal:

   116. Permitted Uses of space reserved under NRPM 4.10

The AC voted to abandon this proposal because of a lack of sufficient
support to accept it as draft policy. Several AC members felt it not
appropriate that ARIN policy dictate any specific architecture or method
a network should use to transition from v4 to v6.

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.? Proposals 109 and 116 may be petitioned to try to
change them into draft policies for adoption discussion on the Public
Policy Mailing List and at the October meeting (Discussion Petition).
The deadline to begin a petition will be five business days after the
AC's draft meeting minutes are published.

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 are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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






From info at arin.net  Tue Jul 20 14:11:44 2010
From: info at arin.net (Member Services)
Date: Tue, 20 Jul 2010 14:11:44 -0400
Subject: [arin-ppml] Draft Policy 2010-9: IPv6 for 6rd
Message-ID: <4C45E6E0.7040204@arin.net>

Draft Policy 2010-9
IPv6 for 6rd

On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 for 6rd"
as a  draft policy for adoption discussion on the PPML and at the Public
Policy Meeting in Atlanta in October.

The draft was developed by the AC from policy proposal "113. IPv6 for
6rd". 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. Below the draft policy is the ARIN staff and legal assessment,
followed by the text that was submitted by the AC.

Draft Policy 2010-9 is below and can be found at:
https://www.arin.net/policy/proposals/2010_9.html

You are encouraged to discuss Draft Policy 2010-9 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 2010-9
IPv6 for 6rd

Version/Date: 20 July 2010

Policy statement:

If you have non contiguous IPv4 addresses then you automatically qualify
for IPv6 space for 6rd. Upon receipt of a 6rd request, the minimum
subnet required for the functionality of 6rd will be automaticlly
granted and larger blocks will be granted based on justification. If
IPv6 addresses are already allocated to the requestor then an effort
will be made to give them an IPv6 allocation that is preferably
contiguous to the prior existing one. The use of this address space will
be used for 6rd and returned to ARIN when 6rd is no longer used on the
network. Justification for use of IPv6 for 6rd will be reviewed every 3
years and reclaimed if it is not in use. Requestor will be exempt from
returning all or a portion of the address space when 6rd is no longer
used if they can show justification for need of the 6rd address space
for other existing IPv6 addressing requirements.

The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:

SP IPv6 prefix: 2001:0DB8::/32
v4suffix-length: 24 (from 10/8, first octet (10) is excluded
from the encoding)
6rd CE router IPv4 address: 10.100.100.1
6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56

This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:

SP IPv6 prefix: 2001:0DB0::/28
v4suffix-length: 32 (unable to exclude common bits
due to non-contiguous IPv4 allocations)
6rd CE router IPv4 address: 192.0.2.1
6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60

Rationale:

6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet. The method provides a
native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.

Timetable for implementation: Immediate



#####


STAFF ASSESSMENT

Proposal: (113) IPv6 for 6rd
Proposal Version (Date): 29 June 2010
Date of Assessment:  13 July 2010

1. Proposal Summary (Staff Understanding)

This policy allows registrants with at least two blocks of on-contiguous
IPv4 address blocks to request a /32 or larger of IPv6 addresses to be
used for a 6rd deployment. The registration would be good for 3 years,
after which time it would be reviewed and reclaimed if not in use for
either the original 6rd deployment or some other v6 network technology.

2. Comments

A. ARIN Staff Comments

?  Neither the proposal, nor the rationale, provides any understanding
of why the first qualification criterion is "non contiguous IPv4
addresses". Why does the proposal exclude organizations with a single,
aggregated prefix registered to them?
?  The proposal sets a default allocation size of /32, but provides no
concrete criteria for ARIN staff to use when reviewing a request for a
larger initial size of addresses for 6rd deployment. For example, if an
organization says they need 32 bits for encapsulating the IPv4 address,
and wants to give a /48 to each customer, they would need a /16 of IPv6
address space. Current IPv6 policy provides guidance for determining the
initial allocation size using the organization?s existing network
infrastructure and customer base.   This policy would have staff
determining initial allocation requests larger than a /32 based on how
their end user customers are using multiple subnets. Should staff be
approving any request for initial IPv6 allocations for 6rd larger than a
/32 whenever the justification is ?end users with multiple subnets?
?  The last sentence of the proposal ("Justification for a subnet of a
/28 ...") seems to be out of place.  It might fit better as the third
sentence following and larger blocks will be granted based on
justification.  Additionally, it would be clearer if the text were
changed slightly to read ?for a subnet of /28 and larger ??

B. ARIN General Counsel
No comments at this time.  It is unlikely to pose any legal concerns.

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 statement:
If you have non-contiguous IPv4 addresses then you automatically qualify
for IPv6 space for 6rd.  Upon receipt of a 6rd request, A minimum of a
/32 will be automatically granted and larger blocks will be granted
based on justification.  An effort will be made to provide any
additional IPv6 allocations contiguous to any prior existing ones.  The
use of this address space will be used for 6rd and returned to ARIN when
6rd is no longer used on the network. Justification for use of IPv6 for
6rd will be reviewed every 3 years and reclaimed if it is not in use.
Requestor will be exempt from returning all or a portion of the address
space when 6rd is no longer used if they can show justification for need
of the 6rd address space for other existing IPv6 addressing requirements
be it Native V6 or some other V6 network technology.

Rationale:

6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet.  The method provides
a native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.
The 6rd prefix is an RIR delegated IPv6 prefix.  It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:

         SP IPv6 prefix: 2001:0DB8::/32
        v4suffix-length: 24 (from 10/8, first octet (10) is excluded
from the encoding)
        6rd CE router IPv4 address: 10.100.100.1
        6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56

This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:

         SP IPv6 prefix: 2001:0DB0::/28
         v4suffix-length: 32 (unable to exclude common bits
                              due to non-contiguous IPv4 allocations)
         6rd CE router IPv4 address: 192.0.2.1
         6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60

Justifications: Examples of how to display home networks using multiple
subnets is accomplished by providing a network plan that invloves the
use of routing opposed to bridging.  Such plans may involve the
reduction of NAT,next-gen services, media types, seperate L2 domains and
more.  The plan must simply show how the end user environment is not a
single LAN subscriber.









From info at arin.net  Tue Jul 20 14:11:57 2010
From: info at arin.net (Member Services)
Date: Tue, 20 Jul 2010 14:11:57 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global Policy
 for IPv4 Allocations by the IANA Post Exhaustion
Message-ID: <4C45E6ED.4070009@arin.net>

Draft Policy 2010-10 (Global Proposal)
Global Policy for IPv4 Allocations by the IANA Post Exhaustion

On 15 July 2010 the ARIN Advisory Council (AC) selected "Global Policy
for IPv4 Allocations by the IANA Post Exhaustion" as a draft policy for
adoption discussion on the PPML and at the Public Policy Meeting in
Atlanta in October.

The draft was developed by the AC from policy proposal "115. Global
Policy for IPv4 Allocations by the IANA Post Exhaustion". 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 receiving the
assessment the text was revised. Below the draft policy is the ARIN
staff and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-10 is below and can be found at:
https://www.arin.net/policy/proposals/2010_10.html

You are encouraged to discuss Draft Policy 2010-10 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 2010-10 (Global Proposal)
Global Policy for IPv4 Allocations by the IANA Post Exhaustion

Version/Date: 20 July 2010

Policy statement:

1. Reclamation Pool Upon adoption of this IPv4 address policy by the
ICANN Board of Directors, the IANA shall establish a Reclamation Pool to
be utilized post RIR IPv4 exhaustion as defined in Section 4. The
reclamation pool will initially contain any fragments that may be left
over in IANA inventory. As soon as the first RIR exhausts its inventory
of IP address space, this Reclamation Pool will be declared active. When
the Reclamation Pool is declared active, the Global Policy for the
Allocation of the Remaining IPv4 Address Space[3] and Policy for
Allocation of IPv4 Blocks to Regional Internet Registries[4] will be
formally deprecated.

2. Returning Address Space to the IANA The IANA will accept into the
Reclamation Pool all eligible IPv4 address space that are offered for
return. Eligible address space includes addresses that are not
designated as "special use" by an IETF RFC or addresses allocated to
RIR's unless they are being returned by the RIR that they were originally
allocated to. Legacy address holders may return address space directly
to the IANA if they so choose.

3. Address Allocations from the Reclamation Pool by the IANA Allocations
from the Reclamation Pool may begin once the pool is declared active.
Addresses in the Reclamation Pool will be allocated on a CIDR boundary
equal to or shorter than the longest minimum allocation unit of all RIRs
in order to complete these allocations.The Reclamation Pool will be
divided on CIDR boundaries and distributed evenly to all eligible RIR's.
Any remainder not evenly divisible by the number of eligible RIR's based
on a CIDR boundary equal to or shorter than the longest minimum
allocation unit of all RIRs will remain in the Reclamation Pool.
Addresses that are left over will be held in the Reclamation Pool until
additional IP addresses can be returned to rejoin addresses on CIDR
boundaries to the Reclamation Pool or a minimum allocation unit is set
to allow allocation from existing inventory.

4. RIR Eligibility for Receiving Allocations from the Reclamation Pool
Upon the exhaustion of an RIR's free space pool and after receiving
their final /8 from the IANA[3], an RIR will become eligible to request
address space from the IANA Reclamation Pool when it publicly announces
via its respective global announcements email list and by posting a
notice on its website that it has exhausted its supply of IPv4 address
space. Exhaustion is defined as an inventory of less than the equivalent
of a single /8 and the inability to further assign address space to its
customers in units equal to or shorter than the longest of any RIR's
policy defined minimum allocation unit. Any RIR that is formed after the
ICANN Board of Directors has ratified this policy is not eligible to
utilize this policy to obtain IPv4 address space from the IANA.

5. Reporting Requirements The IANA shall publish on at least a weekly
basis a report that is publicly available which at a minimum details all
address space that has been received and that has been allocated. The
IANA shall publish a Returned Address Space Report which indicates what
resources were returned, by whom and when. The IANA shall publish an
Allocations Report on at least a weekly basis which at a minimum
indicates what IPv4 address space has been allocated, which RIR received
the allocation and when. The IANA shall publish a public notice
confirming RIR eligibility subsequent to Section 4.

6. No Transfer Rights Address space assigned from the Reclamation Pool
may be transferred if there is either an ICANN Board ratified global
policy or globally coordinated RIR policy specifically written to deal
with transfers whether inter-RIR or from one entity to another.
Transfers must meet the requirements of such a policy. In the absence of
such a policy, no transfers of any kind related to address space
allocated or assigned from the reclamation pool is allowed.

7. Definitions

IANA - Internet Assigned Numbers Authority, or its successor

ICANN - Internet Corporation for Assigned Names and Numbers, or its
successor

RIR - Regional Internet Registry as recognized by ICANN

MOU - Memorandum of Understanding between ICANN and the RIRs

IPv4 - Internet Protocol Version Four(4), the target protocol of this
Global Policy

Free Space Pool - IPv4 Addresses that are in inventory at any RIR,
and/or the IANA

8. Contributors The following individuals donated their time, resources
and effort to develop this proposal on behalf of the Internet Community:

Steve Bertrand <steve at ipv6canada.com>

Chris Grundemann <cgrundemann at gmail.com>

Martin Hannigan <marty at akamai.com>

Aaron Hughes <ahughes at bind.com>

Louie Lee <louie at equinix.com>

Matt Pounsett <matt at conundrum.com>

Jason Schiller <schiller at uu.net>

9. References

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Global Policy for the Allocation of the Remaining IPv4 Address Space,
IANA, Retrieved 27 April 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html
ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Global Policy for the Allocation of the Remaining IPv4 Address Space

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy
for Allocation of IPv4 Blocks to Regional Internet Registries



#####


STAFF ASSESSMENT

Proposal: (115) Global Policy for IPv4 Allocations by the IANA Post
Exhaustion
Proposal Version (Date): 01 July 2010
Date of Assessment:  14 July 2010


1. Proposal Summary (Staff Understanding)

This policy establishes an IANA reclamation pool of IPv4 address space.
  This pool will be comprised of any ?eligible? IPv4 address space
returned to IANA. Once the pool is activated, the two existing IPv4
Global policies (NRPM policies 10.1 and 10.4) will be formally retired.
RIRs may request addresses from this pool upon exhaustion of their IPv4
inventory, as defined in the policy. The policy further requires IANA to
do weekly reporting on the address pool. The policy prohibits any
transfers of the address space issued from the reclamation pool.

2. Comments

A. ARIN Staff Comments

?  Should the retirement of existing 10.1 and 10.4 policies occur right
after the triggering of 10.4, since the triggering of 10.4 will occur
before any RIR suffers depletion?
?  Does the reclamation pool begin with all IANA number resource
remnants dumped into it?  Or is it only returns after the date of the
pool beginning?
?  Why does the last sentence of paragraph 4 exclude late-formed RIRs?
?  The proposal defines RIR exhaustion as ?an inventory of less
than the equivalent of a single /8 and the inability to further assign
address space to its customers in units equal to or shorter than the
longest of the RIR's policy defined minimum allocation unit.?   For
clarification, staff interprets this definition to mean that exhaustion
occurs at the point when ARIN has less than a /8 and no /24s (per policy
2010-2) available to issue.
?  Section 3 of the policy says that the reclamation pool will be
?divided and distributed evenly to all eligible RIRs?.   However, it
appears that any RIR can request additional address space from the
reclamation pool at any point in time when they have exhausted their
IPv4 inventory.  Because this will occur at different times for each
RIR, staff does not understand how the pool will be distributed evenly
amongst the 5 RIRs.
?  The first sentence says ?post-RIR IPv4 exhaustion as defined in
section 5?, however, the definition is actually contained in section 4.


B. ARIN General Counsel

	No comments at this time.

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 statement:
1. Reclamation Pool
Upon adoption of this IPv4 address policy by the ICANN Board of
Directors, the IANA shall establish a Reclamation Pool to be utilized
post RIR IPv4 exhaustion as defined in Section 5. As soon as the first
RIR exhausts its inventory of IP address space, this Reclamation Pool
will be declared active. When the Reclamation Pool is declared active,
the Global Policy for the Allocation of the Remaining IPv4 Address
Space[3] and Policy for Allocation of IPv4 Blocks to Regional Internet
Registries[4] will be formally deprecated.
2. Returning Address Space to the IANA
The IANA will accept into the Reclamation Pool all eligible IPv4 address
space that are offered for return. Eligible address space includes
addresses that are not designated as "special use" by an IETF RFC or
addresses allocated to RIR's unless they are being returned by the RIR
that they were originally allocated to. Legacy address holders may
return address space directly to the IANA if they so choose.
3. Address Allocations from the Reclamation Pool by the IANA
Allocations from the Reclamation Pool may begin once the pool is
declared active. Addresses in the Reclamation Pool will be allocated on
a CIDR boundary equal to or shorter than the longest minimum allocation
unit of all RIRs in order to complete these allocations.The Reclamation
Pool will be divided on CIDR boundaries and distributed evenly to all
eligible RIR's. Any remainder not evenly divisible by the number of
eligible RIR's based on a CIDR boundary equal to or shorter than the
longest minimum allocation unit of all RIRs will remain in the
Reclamation Pool. Addresses that are left over will be held in the
Reclamation Pool until additional IP addresses can be returned to rejoin
addresses on CIDR boundaries to the Reclamation Pool or a minumum
allocation unit is set to allow allocation from existing inventory.
4. RIR Eligibility for Receiving Allocations from the Reclamation Pool
Upon the exhaustion of an RIR's free space pool, an RIR will become
eligible to request address space from the IANA Reclamation Pool when it
publicly announces via its respective global announcements email list
and by posting a notice on its website that it has exhausted its supply
of IPv4 address space. Exhaustion is defined as an inventory of less
than the equivalent of a single /8 and the inability to further assign
address space to its customers in units equal to or shorter than the
longest of the RIR's policy defined minimum allocation unit. Any RIR
that is formed after the ICANN Board of Directors has ratified this
policy is not eligible to utilize this policy to obtain IPv4 address
space from the IANA.
5. Reporting Requirements
The IANA shall publish on at least a weekly basis a report that is
publicly available which at a minimum details all address space that has
been received and that has been allocated. The IANA shall publish a
Returned Address Space Report which indicates what resources were
returned, by whom and when. The IANA shall publish an Allocations Report
on at least a weekly basis which at a minimum indicates what IPv4
address space has been allocated, which RIR received the allocation and
when. The IANA shall publish a public notice confirming RIR eligibility
subsequent to Section 4.
6. No Transfer Rights
Address space assigned from the Reclamation Pool may be transferred if
there is either an ICANN Board ratified global policy or globally
coordinated RIR policy specifically written to deal with transfers
whether inter-RIR or from one entity to another. Transfers must meet the
requirements of such a policy. In the absence of such a policy, no
transfers of any kind related to address space allocated or assigned
from the reclamation pool is allowed.
7. Definitions
IANA - Internet Assigned Numbers Authority, or its successor
ICANN - Internet Corporation for Assigned Names and Numbers, or its
successor
RIR - Regional Internet Registry as recognized by ICANN
MOU - Memorandum of Understanding between ICANN and the RIRs
IPv4 - Internet Protocol Version Four(4), the target protocol of this
Global Policy
Free Space Pool - IPv4 Addresses that are in inventory at any RIR,
and/or the IANA
Rationale:
This policy defines the process for the allocation of IPv4 addresses
post "Exhaustion Phase"[1]. A global policy is required in order for the
IANA to be able to transparently continue to be able to allocate IPv4
addresses beyond exhaustion. In order to fulfill the requirements of
this policy, the IANA must set up a reclamation pool to hold addresses
in and distribute from in compliance with this policy. This policy
establishes the process by which IPv4 addresses can be returned to and
re-issued from the IANA post Exhaustion Phase.
This document does not stipulate performance requirements in the
provision of services by the IANA to an RIR in accordance with this
policy. Such requirements should be specified by appropriate agreements
among the RIRs and ICANN.
The intent of this policy is as follows:
*  To include all post Exhaustion Phase IPv4 address space returned to
the IANA.
*  Allows allocations by the IANA from the Reclamation Pool once the
Exhaustion Phase has been completed.
*  Defines "need" as the basis for further IPv4 allocations by the IANA.
*  Does not differentiate any class of IPv4 address space unless
otherwise defined by an RFC.
*  Encourage the return of IPv4 address space by making this allocation
process available.
*  Disallow transfers of addresses sourced from the Reclamation Pool in
the absence of an IPv4 Global Transfer Policy to neutralize transfer
process inequities across RIR regions.
*  Applies to legacy IPv4 Address Space initially allocated by the IANA
to users including the allocations to RIRs.
*  Includes any length of fragments currently held by the IANA now or in
the future.











From info at arin.net  Tue Jul 20 14:12:09 2010
From: info at arin.net (Member Services)
Date: Tue, 20 Jul 2010 14:12:09 -0400
Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
Message-ID: <4C45E6F9.8010207@arin.net>

Draft Policy 2010-11
Required Resource Reviews

On 15 July 2010 the ARIN Advisory Council (AC) selected "Required
Resource Reviews" as a draft policy for adoption discussion on the PPML
and at the Public Policy Meeting in Atlanta in October.

The draft was developed by the AC from policy proposal "117. Required
Resource Reviews". 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. Below the draft policy is the ARIN staff and legal
assessment, followed by the text that was submitted by the AC.

Draft Policy 2010-11 is below and can be found at:
https://www.arin.net/policy/proposals/2010_11.html

You are encouraged to discuss Draft Policy 2010-11 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 2010-11
Required Resource Reviews

Version/Date: 20 July 2010

Policy statement:

Replace the text "under sections 4-6" in section 12, paragraph 7 with
"under paragraphs 12.4 through 12.6"

Add to section 12 the following text:

10. Except as provided below, resource reviews are conducted at the
discretion of the ARIN staff. In any of the circumstances mentioned
below, a resource review must be initiated by ARIN staff:

a. Report or discovery of an acquisition, merger, transfer, trade or
sale in which the infrastructure and customer base of a network move
from one organization to another organization, but, the applicable IP
resources are not transferred. In this case, the organization retaining
the IP resources must be reviewed. The organization receiving the
customers may also be reviewed at the discretion of the ARIN staff.

b. Upon receipt by ARIN of one or more credible reports of fraud or
abuse of an IP address block. Abuse shall be defined as use of the block
in violation of the RSA or other ARIN policies and shall not extend to
include general reports of host conduct which are not within ARIN's scope.

c. In the case where an organization wishes to act as recipient of
resources pursuant to a transfer under section 8.3, unless otherwise
prohibited by paragraph 12.2(c).

d. An organization which submits a request for additional resources when
more than 25% of their existing resources are obscured in SWIP or RWHOIS
pursuant to section 4.2.3.7.6 (residential customer privacy).

e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
exempt organizations from the reviews required under section 12.10.

Rationale:

The first change is a minor correction which improves clarity and
consistency of the original policy without changing the meaning.

The addition of 12.10 (a) through (e) serves to create a set of
circumstances under which a resource review is required, rather than
optional and entirely at ARIN staff discretion.

The majority of early comments on this proposal focused on 12.10 (e).
Mostly it was confusion about the exact ramifications. This section will
cause ARIN to maintain greater scrutiny only in cases where a given ISP
issues more than 25% of their total space to residential customers who
wish to remain anonymous and receive network blocks of /29 or larger. To
the best of my knowledge, there are not currently any ISPs which meet
this criteria. Additionally, it would only apply that scrutiny to IPv4,
and will not carry forward into IPv6 residential assignments.

This policy should improve the compliance verification of ARIN policies
and may result in the improved reclamation of under-utilized IP address
space. It should also serve as a deterrent to certain address hoarding
tactics which have come to light in recent history.

Timetable for implementation: Immediately upon ratification by the Board


#####


STAFF ASSESSMENT

Proposal: (117) Required Resource Reviews
Proposal Version (Date): 07 July 2010
Date of Assessment:  14 July 2010

1. Proposal Summary (Staff Understanding)

This draft policy establishes new criteria to enact NRPM 12 resource
reviews. It requires ARIN staff to initiate resource reviews when M&A
activity occurs but IP addresses are not transferred to the acquirer;
when fraud or abuse is reported to ARIN, either about a specific IP
address range or about an OrgID; when any NRPM 8.3 transfer occurs; or
when staff are reviewing an additional IP address request and find that
more than a quarter of an OrgID's downstream SWIPs are covered under the
Residential Customer Privacy policy.

2. Comments

A. ARIN Staff Comments

?  This proposal could cause ARIN staff to conduct resource reviews on a
more frequent basis. Any prescription for prioritizing such reviews
could delay other important registration activities from being processed
in a timely manner.

B. ARIN General Counsel

Pending


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:

?  Resource reviews, audits, and fraud research require many man-hours.
  These new requirements to conduct audits on a much more regular basis
could necessitate hiring and training additional registration staff.
?  Changes to current business practices
?  Staff training
?  Updated guidelines


4. Proposal Text

Policy statement:

Replace the text "under sections 4-6" in section 12, paragraph 7 with
"under paragraphs 12.4 through 12.6"
Add to section 12 the following text:

10. Except as provided below, resource reviews are conducted at the
discretion of the ARIN staff. In any of the circumstances mentioned
below, a resource review must be initiated by ARIN staff:
a. Report or discovery of an acquisition, merger, transfer, trade or
sale in which the infrastructure and customer base of a network move
from one organization to another organization, but, the applicable IP
resources are not transferred. In this case, the organization retaining
the IP resources must be reviewed. The organization receiving the
customers may also be reviewed at the discretion of the ARIN staff.
b. Upon receipt by ARIN of one or more credible reports of fraud or
abuse of an IP address block. Abuse shall be defined as use of the block
in violation of the RSA or other ARIN policies and shall not extend to
include general reports of host conduct which are not within ARIN's scope.
c. In the case where an organization wishes to act as recipient of
resources pursuant to a transfer under section 8.3, unless otherwise
prohibited by paragraph 12.2(c).
d. An organization which submits a request for additional resources
when more than 25% of their existing resources are obscured in SWIP or
RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).
e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
exempt organizations from the reviews required under section 12.10.

Rationale:

The first change is a minor correction which improves clarity and
consistency of the original policy without changing the meaning.
The addition of 12.10 (a) through (e) serves to create a set of
circumstances under which a resource review is required, rather than
optional and entirely at ARIN staff discretion.

The majority of early comments on this proposal focused on 12.10 (e).
Mostly it was confusion about the exact ramifications. This section will
cause ARIN to maintain greater scrutiny only in cases where a given ISP
issues more than 25% of their total space to residential customers who
wish to remain anonymous and receive network blocks of /29 or larger. To
the best of my knowledge, there are not currently any ISPs which meet
this criteria. Additionally, it would only apply that scrutiny to IPv4,
and will not carry forward into IPv6 residential assignments.

This policy should improve the compliance verification of ARIN policies
and may result in the improved reclamation of under-utilized IP address
space. It should also serve as a deterrent to certain address hoarding
tactics which have come to light in recent history.








From info at arin.net  Tue Jul 20 14:12:21 2010
From: info at arin.net (Member Services)
Date: Tue, 20 Jul 2010 14:12:21 -0400
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation
Message-ID: <4C45E705.1060100@arin.net>

Draft Policy 2010-12
IPv6 Subsequent Allocation

On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 Subsequent
Allocation" as a draft policy for adoption discussion on the PPML and at
the Public Policy Meeting in Atlanta in October.

The draft was developed by the AC from policy proposal "118. IPv6
Subsequent Allocation". 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. Below the draft policy is the ARIN staff
and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-12 is below and can be found at:
https://www.arin.net/policy/proposals/2010_12.html

You are encouraged to discuss Draft Policy 2010-12 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 2010-12
IPv6 Subsequent Allocation

Version/Date: 20 July 2010

Policy statement:

Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
sentence: Subsequent allocations will also be considered for
transitional technologies that cannot be accommodated by, nor were
accounted for, under the initial allocation.

Justification for the subsequent subnet size will be based on the plan
and technology provided. Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use. Requester will
be exempt from returning all or a portion of the address space if they
can show justification for need of this allocation for other existing
IPv6 addressing requirements be it Native V6 or some other V6 network
technology.

Rationale: Current organizations cannot get an allocation for a IPv6
transitional technology if they have already received their initial
allocation of IPv6. The reason they cannot get an additional IPV6
allocation is because they don't meet the HD ratio for a subsequent
allocation and they don't want to use their initial assignment because
it is insufficient, mapped out for other long term plans, or already has
portions in use.

An alternative proposal to permit more allocations was submitted that
supported 6rd but since then community members have come forward with
concern that this should support not just one particular technology but
any that enable v6 deployment.

Justification Example: Below is an example of how the details for a
technology and its subnet requirements could be provided as
justification. This example is based of 6rd.

6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet. The method provides a
native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.

The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:

SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56

This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:

SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60

Timetable for implementation: Immediate


#####


STAFF ASSESSMENT

Proposal:  (118) IPv6 Subsequent Allocation
Proposal Version (Date): 21 June 2010
Date of Assessment:  14 July 2010

1. Proposal Summary (Staff Understanding)

This policy opens the IPv6 ISP additional allocation policy to allow for
subsequent allocations to be considered when a new technology is being
implemented which requires a separate block from existing IPv6
allocations. Subsequent allocations issued under this new language must
be reviewed with the registrant every 3 years by ARIN staff.

2. Comments

A. ARIN Staff Comments

?  The policy text provides no concrete criteria for ARIN staff to
determine when an organization does, or does not, qualify for a
subsequent IPv6 allocation.
?  Additionally, there are no criteria to be used to determine the size
of the allocation an organization qualifies for. For example, if an
organization says they need 32 bits for encapsulating the IPv4 address,
and wants to give a /48 to each customer, they would need a /16 of IPv6
space.    Current IPv6 policy provides clear criteria for judging the
subsequent allocation size by applying an hd ratio of .94, a criterion
which can be applied consistently across the board.  This policy would
have staff determining subsequent allocation based on ?some technical
documentation? without any real guidelines.  Should staff be approving
any request for subsequent IPv6 allocations of any size whenever the
justification is ?we?re using it for a transitional technology??

B. ARIN General Counsel

No comments at this time.  It is unlikely to raise legal issues.

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

Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
sentence: Subsequent allocations will also be considered for
transitional technologies that cannot be accommodated by, nor were
accounted for, under the initial allocation.
Justification for the subsequent subnet size will be based on the plan
and technology provided. Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use. Requester will
be exempt from returning all or a portion of the address space if they
can show justification for need of this allocation for other existing
IPv6 addressing requirements be it Native V6 or some other V6 network
technology.

Rationale:
Current organizations cannot get an allocation for a IPv6
transitional technology if they have already received their initial
allocation of IPv6. The reason they cannot get an additional IPV6
allocation is because they don't meet the HD ratio for a subsequent
allocation and they don't want to use their initial assignment because
it is insufficient, mapped out for other long term plans, or already has
portions in use.

An alternative proposal to permit more allocations was submitted that
supported 6rd but since then community members have come forward with
concern that this should support not just one particular technology but
any that enable v6 deployment.
Justification Example:
Below is an example of how the details for a technology and its subnet
requirements could be provided as justification. This example is based
of 6rd.

6rd is intended to be an incremental method for deploying IPv6 and
bridge the gap for End Users to the IPv6 Internet.  The method provides
a native dual-stack service to a subscriber site by leveraging existing
infrastructure. If an entity already has a /32 of IPv6 they can not use
the same /32 for native IPv6 as they do for the 6rd routing and a
separate minimum size of a /32 is required while a larger subnet like a
/28 may be needed based on a non-contiguous IPv4 addressing plan.
The 6rd prefix is an RIR delegated IPv6 prefix.  It must encapsulate an
IPv4 address and must be short enough so that a /56 or /60 can be given
to subscribers. This example shows how the 6rd prefix is created based
on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
        SP IPv6 prefix: 2001:0DB8::/32
        v4suffix-length: 24 (from 10/8, first octet (10) is excluded
                             from the encoding)
        6rd CE router IPv4 address: 10.100.100.1
        6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
This example shows how the 6rd prefix is created based on a /28 IPv6
prefix using one of several non-contiguous global address ranges:
         SP IPv6 prefix: 2001:0DB0::/28
         v4suffix-length: 32 (unable to exclude common bits
                              due to non-contiguous IPv4 allocations)
         6rd CE router IPv4 address: 192.0.2.1
         6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60





From tedm at ipinc.net  Tue Jul 20 14:39:53 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 20 Jul 2010 11:39:53 -0700
Subject: [arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation
In-Reply-To: <4C45E705.1060100@arin.net>
References: <4C45E705.1060100@arin.net>
Message-ID: <4C45ED79.6050005@ipinc.net>



On 7/20/2010 11:12 AM, Member Services wrote:
> Draft Policy 2010-12
> IPv6 Subsequent Allocation
>
> On 15 July 2010 the ARIN Advisory Council (AC) selected "IPv6 Subsequent
> Allocation" as a draft policy for adoption discussion on the PPML and at
> the Public Policy Meeting in Atlanta in October.
>
> The draft was developed by the AC from policy proposal "118. IPv6
> Subsequent Allocation". 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. Below the draft policy is the ARIN staff
> and legal assessment, followed by the text that was submitted by
> the AC.
>
> Draft Policy 2010-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2010_12.html
>
> You are encouraged to discuss Draft Policy 2010-12 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 2010-12
> IPv6 Subsequent Allocation
>
> Version/Date: 20 July 2010
>
> Policy statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
> sentence: Subsequent allocations will also be considered for
> transitional technologies that cannot be accommodated by, nor were
> accounted for, under the initial allocation.
>
> Justification for the subsequent subnet size will be based on the plan
> and technology provided. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. Requester will
> be exempt from returning all or a portion of the address space if they
> can show justification for need of this allocation for other existing
> IPv6 addressing requirements be it Native V6 or some other V6 network
> technology.
>
> Rationale: Current organizations cannot get an allocation for a IPv6
> transitional technology if they have already received their initial
> allocation of IPv6. The reason they cannot get an additional IPV6
> allocation is because they don't meet the HD ratio for a subsequent
> allocation and they don't want to use their initial assignment because
> it is insufficient, mapped out for other long term plans, or already has
> portions in use.
>
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
>
> Justification Example: Below is an example of how the details for a
> technology and its subnet requirements could be provided as
> justification. This example is based of 6rd.
>
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides a
> native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
>
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
>
> SP IPv6 prefix: 2001:0DB8::/32 v4suffix-length: 24 (from 10/8, first
> octet (10) is excluded from the encoding) 6rd CE router IPv4 address:
> 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
>
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
>
> SP IPv6 prefix: 2001:0DB0::/28 v4suffix-length: 32 (unable to exclude
> common bits due to non-contiguous IPv4 allocations) 6rd CE router IPv4
> address: 192.0.2.1 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>
> Timetable for implementation: Immediate
>
>
> #####
>
>
> STAFF ASSESSMENT
>
> Proposal: (118) IPv6 Subsequent Allocation
> Proposal Version (Date): 21 June 2010
> Date of Assessment: 14 July 2010
>
> 1. Proposal Summary (Staff Understanding)
>
> This policy opens the IPv6 ISP additional allocation policy to allow for
> subsequent allocations to be considered when a new technology is being
> implemented which requires a separate block from existing IPv6
> allocations. Subsequent allocations issued under this new language must
> be reviewed with the registrant every 3 years by ARIN staff.
>
> 2. Comments
>
> A. ARIN Staff Comments
>
> ? The policy text provides no concrete criteria for ARIN staff to
> determine when an organization does, or does not, qualify for a
> subsequent IPv6 allocation.
> ? Additionally, there are no criteria to be used to determine the size
> of the allocation an organization qualifies for. For example, if an
> organization says they need 32 bits for encapsulating the IPv4 address,
> and wants to give a /48 to each customer, they would need a /16 of IPv6
> space. Current IPv6 policy provides clear criteria for judging the
> subsequent allocation size by applying an hd ratio of .94, a criterion
> which can be applied consistently across the board. This policy would
> have staff determining subsequent allocation based on ?some technical
> documentation? without any real guidelines. Should staff be approving
> any request for subsequent IPv6 allocations of any size whenever the
> justification is ?we?re using it for a transitional technology??
>
> B. ARIN General Counsel
>
> No comments at this time. It is unlikely to raise legal issues.
>
> 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 statement:
>
> Modify 6.5.2.1 Subsequent allocation criteria. ADD the following
> sentence: Subsequent allocations will also be considered for
> transitional technologies that cannot be accommodated by, nor were
> accounted for, under the initial allocation.
> Justification for the subsequent subnet size will be based on the plan
> and technology provided. Justification for these allocations will be
> reviewed every 3 years and reclaimed if it is not in use. Requester will
> be exempt from returning all or a portion of the address space if they
> can show justification for need of this allocation for other existing
> IPv6 addressing requirements be it Native V6 or some other V6 network
> technology.
>
> Rationale:
> Current organizations cannot get an allocation for a IPv6
> transitional technology if they have already received their initial
> allocation of IPv6. The reason they cannot get an additional IPV6
> allocation is because they don't meet the HD ratio for a subsequent
> allocation and they don't want to use their initial assignment because
> it is insufficient, mapped out for other long term plans, or already has
> portions in use.
>
> An alternative proposal to permit more allocations was submitted that
> supported 6rd but since then community members have come forward with
> concern that this should support not just one particular technology but
> any that enable v6 deployment.
> Justification Example:
> Below is an example of how the details for a technology and its subnet
> requirements could be provided as justification. This example is based
> of 6rd.
>
> 6rd is intended to be an incremental method for deploying IPv6 and
> bridge the gap for End Users to the IPv6 Internet. The method provides
> a native dual-stack service to a subscriber site by leveraging existing
> infrastructure. If an entity already has a /32 of IPv6 they can not use
> the same /32 for native IPv6 as they do for the 6rd routing and a
> separate minimum size of a /32 is required while a larger subnet like a
> /28 may be needed based on a non-contiguous IPv4 addressing plan.
> The 6rd prefix is an RIR delegated IPv6 prefix. It must encapsulate an
> IPv4 address and must be short enough so that a /56 or /60 can be given
> to subscribers. This example shows how the 6rd prefix is created based
> on a /32 IPv6 prefix using RFC1918 address space from 10.0.0.0/8:
> SP IPv6 prefix: 2001:0DB8::/32
> v4suffix-length: 24 (from 10/8, first octet (10) is excluded
> from the encoding)
> 6rd CE router IPv4 address: 10.100.100.1
> 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56
> This example shows how the 6rd prefix is created based on a /28 IPv6
> prefix using one of several non-contiguous global address ranges:
> SP IPv6 prefix: 2001:0DB0::/28
> v4suffix-length: 32 (unable to exclude common bits
> due to non-contiguous IPv4 allocations)
> 6rd CE router IPv4 address: 192.0.2.1
> 6rd site IPv6 prefix: 2001:0DBC:0000:2010::/60
>

I do not like this proposal at all for 3 reasons:

1)the only language in it that even acknowledges that these allocations 
are intended to be temporary is the line:

"...Justification for these allocations will be
reviewed every 3 years and reclaimed if it is not in use...."

What your doing is allowing an org to request space for a band-aid and
by not putting a deadline on it your going to just allow them to
institutionalize the bandaid.  That's not what we should be encouraging.

I would prefer the proposal only allocated the temp space for a fixed
period of time, and then if it wasn't returned by the deadline of that
time, the space would then be added to their HD ratio calculation for
subsequent allocations.  No need to waste staff time at the RIR going
back and reviewing every 3 years.

2)  I would much prefer that instead of the RIR's allowing these
special allocations willy-nilly across the IPv6 space, that IANA
designate a special prefix for each transitional technology that is
worked out, and that special allocations be made from that prefix.
It would make things a lot easier 10 years from now when orgs want to
filter out some of these at-that-time-dead bandaid technologies.

I see no reason to commence "infill" activites on IPv6 now.  We are
not trying to build a city here.  And yes I realize 1 and 2 aren't
really compatible.  Pick one or the other..

If IANA won't setup to the plate for this then if ARIN is going to
adopt this then I would prefer ARIN designate a specific block for
IPv6 temporary special allocations and make all of them from that
prefix.

3) I feel that this proposal and the 6rd proposal are exclusive.
I would prefer multiple "transitional IPv6 technologies" proposals
that are like the 6rd proposal for each new "transitional technology"
that is invented, rather than a one-size-fits-all transitional
technology proposal.


Ted


From owen at delong.com  Wed Jul 21 02:19:23 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 20 Jul 2010 23:19:23 -0700
Subject: [arin-ppml] Petition for discussion of policy proposal 116
	(Permitted Uses of Space Reserved Under NRPM 4.10)
Message-ID: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>

> The AC abandoned the following proposal:
> 
>  116. Permitted Uses of space reserved under NRPM 4.10
> 
> The AC voted to abandon this proposal because of a lack of sufficient
> support to accept it as draft policy. Several AC members felt it not
> appropriate that ARIN policy dictate any specific architecture or method
> a network should use to transition from v4 to v6.

This is my formal request to initiate a discussion petition of proposal 116.

If you would like to sign this petition, please do the following:

	1.	Send a message stating "I support the petition for discussion of proposal 116"
		to arin-ppml at arin.net

	2.	Either include your contact information and organizational affiliation in
		the original message to ppml or send it in a separate message to
		petition at arin.net (use this address if you do not want your contact
		information disclosed to PPML).

Thank you.

I believe that the AC should not have abandoned this proposal for the following
reasons:

1.	I believe that there is community support for clarifying valid uses and
	preventing abuses of space reserved for transitional technologies under
	section 4.10.

2.	The language of 116 states examples of valid uses of space under 4.10
	but does not specify or dictate specific architecture or methods. It attempts
	to prevent space reserved for transition from being used in a business-as-
	usual method that is not in direct support of a transition to IPv6 because
	the author believes that is contrary to the community intent of 4.10.

	I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid
	technologies and includes specifically (e) etc. to cover any possible
	valid technologies not yet contemplated.

3.	The language in the existing 4.10 is not sufficiently specific to prevent
	a multitude of possible abuses of the reserved space that do not actually
	benefit a transition process.

For these reasons, I encourage anyone who feels that section 4.10 reflects the
good intent of the community to sign this discussion petition to get this policy
in front of the community in Atlanta. Even if you disagree with the specifics, those
can be addressed in the development of the policy. If you have comments on
those specifics, please direct them to ppml or to me.


Author contact information as required in the petition process:

Owen DeLong
owen at delong.com
+1.408.890.7992

Here is the text of the proposal in question as required in the petition
process:

Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
Proposal Originator: Owen DeLong
Proposal Version: 1
Date: 18 June 2010
Proposal type: modify
Policy term: permanent
Policy statement:
Add the following to section 4.10 of the NRPM
6. No organization may receive more than 16 /24 equivalents under this
section.
Add the following to section 4 of the NRPM
4.11 Required utilization for subsequent allocation under section 4.10
No organization shall receive more than one allocation or assignment
under section 4.10 unless all prior space issued under 4.10 meets the
utilization requirements of this section.
1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
2. All utilization must be permitted under section 4.12
3. All prior 4.10 allocation/assignments must be at least 90% utilized.
4.12 Permitted uses of allocations or assignments under section 4.10
No organization shall use space received under section 4.10 for any
purpose other than as specified in this section
1. To provide the required public IPv4 address(es) for transitional
technologies operated by the recipient organization.
a. Large scale or "Carrier Grade" NAT
b. NAT-PT
c. DS-LITE/AFTeR
d. DNS64 or other transitional DNS enablers
e. etc.
2. For other transitional technologies not envisioned at the time of
this proposal, but, in no case for general IPv4 addressing provided to
customers.
Rationale:
The current terminology in section 4.10 is vague and could allow a
variety of interpretations which could lead to allocations or
assignments being made to ISPs intending to misuse the space for general
deployment by using IPv6 overlay technologies as a "IPv6 deployments"
requiring IPv4 space for transition. For example, the current policy
could be interpreted to enable an ISP to require IPv4 addresses for all
IPv6 customers to roll IPv6 out as 6rd to customers who would be
otherwise unable to get IPv4 space. This is clearly outside of the
original intent of the proposal which created 4.10 (6rd was not yet
envisioned at the time that was written). This proposal seeks to clarify
that intent and tighten up the requirements for organizations seeking to
get space from this limited final resource so that it truly is available
to facilitate transitional technologies.
Timetable for implementation: immediate
For reference, here is the current text of 4.10
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.
In order to receive an allocation or assignment under this policy:
1. the applicant may not have received resources under this policy in
the preceding six months;
2. previous allocations/assignments under this policy must continue to
meet the justification requirements of this policy;
3. previous allocations/assignments under this policy must meet the
utilization requirements of end user assignments;
4. the applicant must demonstrate that no other allocations or
assignments will meet this need;
5. on subsequent allocation under this policy, ARIN staff may require
applicants to renumber out of previously allocated / assigned space
under this policy in order to minimize non-contiguous allocations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100720/faf24010/attachment.htm>

From info at arin.net  Wed Jul 21 12:50:01 2010
From: info at arin.net (Member Services)
Date: Wed, 21 Jul 2010 12:50:01 -0400
Subject: [arin-ppml] Petition for discussion of policy proposal 116
 (Permitted Uses of Space Reserved Under NRPM 4.10)
Message-ID: <4C472539.7080909@arin.net>

The message below started a petition regarding the ARIN Advisory
Council's decision to abandon "Policy Proposal 116. Permitted Uses of
space reserved under NRPM 4.10." ARIN staff posted on 20 July 2010 to
PPML that the ARIN Advisory Council (AC) had decided to abandon the
proposal.

If successful, this petition will change Proposal 116 into a Draft
Policy which will be published for adoption discussion on the PPML and
at the Public Policy Meeting in October. If the petition fails, the
proposal will be closed.

For this petition to be successful, the petition needs statements of
support from at least 10 different people from 10 different
organizations. If you wish to support this petition, post a statement of
support to PPML on this thread. Point of contact information is
required, either to the entire PPML or with a follow up post to
petition at arin.net with full POC information (name, organization, street
address, email, phone).

The duration of the petition is through five business days after the
AC's draft meeting minutes are published. ARIN staff will post the
result of the petition to PPML.

For more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


#####


> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Wednesday, July 21, 2010 2:19 AM
> To: arin-ppml at arin.net List; petition at arin.net
> Subject: Petition for discussion of policy proposal 116 (Permitted Uses
> of Space Reserved Under NRPM 4.10)
>
>     The AC abandoned the following proposal:
>
>      116. Permitted Uses of space reserved under NRPM 4.10
>
>     The AC voted to abandon this proposal because of a lack of
> sufficient
>     support to accept it as draft policy. Several AC members felt it
> not
>     appropriate that ARIN policy dictate any specific architecture or
> method
>     a network should use to transition from v4 to v6.
>
>
>
> This is my formal request to initiate a discussion petition of proposal
> 116.
>
> If you would like to sign this petition, please do the following:
>
> 1. Send a message stating "I support the petition for discussion of
> proposal 116"
> to arin-ppml at arin.net
>
> 2. Either include your contact information and organizational
> affiliation in
> the original message to ppml or send it in a separate message to
> petition at arin.net (use this address if you do not want your contact
> information disclosed to PPML).
>
> Thank you.
>
> I believe that the AC should not have abandoned this proposal for the
> following
> reasons:
>
> 1. I believe that there is community support for clarifying valid uses
> and
> preventing abuses of space reserved for transitional technologies under
> section 4.10.
>
> 2. The language of 116 states examples of valid uses of space under
> 4.10
> but does not specify or dictate specific architecture or methods. It
> attempts
> to prevent space reserved for transition from being used in a business-
> as-
> usual method that is not in direct support of a transition to IPv6
> because
> the author believes that is contrary to the community intent of 4.10.
>
> I refer specifically to 4.12(1)(a-e) which list a multitude of possible
> valid
> technologies and includes specifically (e) etc. to cover any possible
> valid technologies not yet contemplated.
>
> 3. The language in the existing 4.10 is not sufficiently specific to
> prevent
> a multitude of possible abuses of the reserved space that do not
> actually
> benefit a transition process.
>
> For these reasons, I encourage anyone who feels that section 4.10
> reflects the
> good intent of the community to sign this discussion petition to get
> this policy
> in front of the community in Atlanta. Even if you disagree with the
> specifics, those
> can be addressed in the development of the policy. If you have comments
> on
> those specifics, please direct them to ppml or to me.
>
>
> Author contact information as required in the petition process:
>
> Owen DeLong
> owen at delong.com
> +1.408.890.7992
>
> Here is the text of the proposal in question as required in the
> petition
> process:
>
> Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
> Proposal Originator: Owen DeLong
> Proposal Version: 1
> Date: 18 June 2010
> Proposal type: modify
> Policy term: permanent
> Policy statement:
> Add the following to section 4.10 of the NRPM
> 6. No organization may receive more than 16 /24 equivalents under this
> section.
> Add the following to section 4 of the NRPM
> 4.11 Required utilization for subsequent allocation under section 4.10
> No organization shall receive more than one allocation or assignment
> under section 4.10 unless all prior space issued under 4.10 meets the
> utilization requirements of this section.
> 1. The most recent 4.10 allocation/assignment must be at least 80%
> utilized.
> 2. All utilization must be permitted under section 4.12
> 3. All prior 4.10 allocation/assignments must be at least 90% utilized.
> 4.12 Permitted uses of allocations or assignments under section 4.10
> No organization shall use space received under section 4.10 for any
> purpose other than as specified in this section
> 1. To provide the required public IPv4 address(es) for transitional
> technologies operated by the recipient organization.
> a. Large scale or "Carrier Grade" NAT
> b. NAT-PT
> c. DS-LITE/AFTeR
> d. DNS64 or other transitional DNS enablers
> e. etc.
> 2. For other transitional technologies not envisioned at the time of
> this proposal, but, in no case for general IPv4 addressing provided to
> customers.
> Rationale:
> The current terminology in section 4.10 is vague and could allow a
> variety of interpretations which could lead to allocations or
> assignments being made to ISPs intending to misuse the space for
> general
> deployment by using IPv6 overlay technologies as a "IPv6 deployments"
> requiring IPv4 space for transition. For example, the current policy
> could be interpreted to enable an ISP to require IPv4 addresses for all
> IPv6 customers to roll IPv6 out as 6rd to customers who would be
> otherwise unable to get IPv4 space. This is clearly outside of the
> original intent of the proposal which created 4.10 (6rd was not yet
> envisioned at the time that was written). This proposal seeks to
> clarify
> that intent and tighten up the requirements for organizations seeking
> to
> get space from this limited final resource so that it truly is
> available
> to facilitate transitional technologies.
> Timetable for implementation: immediate
> For reference, here is the current text of 4.10
> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment. Allocations and assignments from this block must be
> justified by immediate IPv6 deployment requirements. Examples of such
> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-
> PT
> or NAT464 translators. ARIN staff will use their discretion when
> evaluating justifications.
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block.
> In order to receive an allocation or assignment under this policy:
> 1. the applicant may not have received resources under this policy in
> the preceding six months;
> 2. previous allocations/assignments under this policy must continue to
> meet the justification requirements of this policy;
> 3. previous allocations/assignments under this policy must meet the
> utilization requirements of end user assignments;
> 4. the applicant must demonstrate that no other allocations or
> assignments will meet this need;
> 5. on subsequent allocation under this policy, ARIN staff may require
> applicants to renumber out of previously allocated / assigned space
> under this policy in order to minimize non-contiguous allocations.








From jmaimon at chl.com  Fri Jul 23 00:39:42 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 23 Jul 2010 00:39:42 -0400
Subject: [arin-ppml] Petition for discussion of policy proposal
 116	(Permitted Uses of Space Reserved Under NRPM 4.10)
In-Reply-To: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
Message-ID: <4C491D0E.7030107@chl.com>



Owen DeLong wrote:
>> The AC abandoned the following proposal:
>>
>> 116. Permitted Uses of space reserved under NRPM 4.10
>>
>> The AC voted to abandon this proposal because of a lack of sufficient
>> support to accept it as draft policy. Several AC members felt it not
>> appropriate that ARIN policy dictate any specific architecture or method
>> a network should use to transition from v4 to v6.
>
> This is my formal request to initiate a discussion petition of proposal 116.
>
> If you would like to sign this petition, please do the following:
>
> 1. Send a message stating "I support the petition for discussion of
> proposal 116"
> to arin-ppml at arin.net <mailto:arin-ppml at arin.net>


I support the petition for discussion of proposal 116.

I would like to see it advance to Draft Policy.

Joe Maimon
CHL

>
> 2. Either include your contact information and organizational affiliation in
> the original message to ppml or send it in a separate message to
> petition at arin.net <mailto:petition at arin.net> (use this address if you do
> not want your contact
> information disclosed to PPML).
>
> Thank you.
>
> I believe that the AC should not have abandoned this proposal for the
> following
> reasons:
>
> 1. I believe that there is community support for clarifying valid uses and
> preventing abuses of space reserved for transitional technologies under
> section 4.10.

I believe that it was premature for the AC to come to that conclusion, 
especially considering what the difference between supported PP and 
unsupported PP based on ppml chatter seems to be.

Sampling size does not seem very large lately, especially compared to 
some of the more exciting times of the not to distant past.

I am of the opinion that the AC should modify course and attempt to rein 
in their opinions on the desirability of proposed policy in favor of 
fostering wider discussion and participation, as it appears to me that 
the opposite may be occurring.

I believe that at this time they are likely on the negative side of that 
delicate balance.

I recognize that my viewpoint on the matter is likely an outlier.

I view heated use of 4.10 as one of a few potential worse case 
scenarios, where IPv4 stewardship has failed to deliver in response to 
demand, either by choices made or by circumstances as they befall, 
leaving 4.10 among the last of the available dry land.

Additional restrictions and clarifications on 4.10 are either highly 
important or highly irrelevant. For the former, discussion should be 
fostered. For the latter, objections should be stilled.

Joe




From bill at herrin.us  Fri Jul 23 12:53:07 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 23 Jul 2010 06:53:07 -1000
Subject: [arin-ppml] Petition for discussion of policy proposal 116
	(Permitted Uses of Space Reserved Under NRPM 4.10)
In-Reply-To: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
Message-ID: <AANLkTim0XJgM2DWXj0GmZ9Exf+h9g0GLgtRfB=nATRwe@mail.gmail.com>

On Tue, Jul 20, 2010 at 8:19 PM, Owen DeLong <owen at delong.com> wrote:
> 3. The language in the existing 4.10 is not sufficiently specific to prevent
> a multitude of possible abuses of the reserved space that do not actually
> benefit a transition process.

I SUPPORT the petition to move proposal 116 forward to formal discussion.

Although I don't think the text of 116 completely captures its intent,
I believe that the likelihood of attempted misuse of the addresses
reserved for transition mechanisms merits further scrutiny. I believe
116 or similar proposals would both benefit from the more focused
discussion that an active proposal encourages and benefit from the
perspective offered by the folks at this fall's joint nanog-arin
meeting who don't camp PPML.


Speaking for myself. Address and particulars below.

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 cgrundemann at gmail.com  Fri Jul 23 13:50:51 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 23 Jul 2010 11:50:51 -0600
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP
	Reassignment Registration Requirements
Message-ID: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>

This post should act as my formal request to initiate a discussion
petition of proposal 109 and to request that it be moved to draft
policy status for discussion at ARIN XXVI.

> The AC decided not to select Proposal 109 as a draft policy at this time:
>
>  109. Standardize IP Reassignment Registration Requirements
>
> Regarding Proposal 109, the AC would really like to see the sentiments
> in this proposal re-surface in bite-size pieces. SWIP requirements, both
> IPv4 and IPv6, the distinction of residential customers, the utilization
> requirements for subsequent allocations, and customer privacy are all
> good topics, but agreement in some will be held up by any disagreements
> on the others when trying to address them as one.

Although I understand the sentiments of the AC, I am petitioning this
proposal as I feel strongly that it meets the basic requirements for
ARIN Policy and meets the immediate needs of the community. This
proposal was previously discussed at the open policy hour in Toronto
and I believe that the best next step is for the final (v4) text to be
discussed as a draft policy in Atlanta. If the petition is successful
I will continue to work with the AC in preparation for presenting it
at the PPM in Atlanta.

If you support this petition, please send the following:

I support the petition of proposal 109.
<Name, Organization, Contact info>

Either as a response to this thread or directly to petition at arin.net
if you do not want your information to be broadcast on the PPML.

--

Author contact information:

Chris Grundemann
cgrundemann at gmail.com
+1.303.351.1539

--

Policy statement (v4):

## Definitions ##

- Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, street address, city, state, zip code equivalent and at
least one valid technical and one valid abuse POC. Each POC shall be
designated by the organization and must include at least a verifiable
email address and phone number.

2.12. Residential Customer

End-users who are individual persons and not organizations and who
receive service at a place of residence for personal use only are
considered residential customers.

## IPv4 ##

- Rename 4.2.3.7. "Reassignment information" to "Registration" and add text:

ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but not
limited to assignment histories, showing their efficient use.

- Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:

Each IPv4 assignment containing a /29 or more addresses shall be
registered in the WHOIS directory via SWIP or a distributed service
which meets the standards set forth in section 3.2. Reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.

- Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.

- Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
visible within 7 days" and replace text with:

All assignments shall be made visible as required in section 4.2.3.7.1
within seven calendar days of assignment.

- Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.3. Residential Subscribers

4.2.3.7.3.1. Residential Market Area

ISPs that assign address space to the infrastructure to which their
customers connect rather than to individual subscribers must register
assignment information regarding each market area holding such an
address block. Market area reassignments shall be registered with the
network name used to identify each market area. Any assignment to
specific end-users holding /29 and larger blocks still requires
registration. A >50% utilization rate shall be considered efficient
for market area reassignments from the ISPs most recent allocation.

4.2.3.7.3.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /29 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS directory record for that
block.

- Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

- Replace Section 6.5.5. with:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but not
limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each IPv6 assignment containing a /64 or more addresses shall be
registered in the WHOIS directory via SWIP or a distributed service
which meets the standards set forth in section 3.2. Reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.

6.5.5.2. Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1
within seven calendar days of assignment.

6.5.5.3. Residential Subscribers

6.5.5.3.1. Residential Market Area

ISPs that assign address space to the infrastructure to which their
customers connect rather than to individual subscribers must register
assignment information regarding each market area holding such an
address block. Market area reassignments shall be registered with the
network name used to identify each market area. Any assignment to
specific end-users holding /64 and larger blocks still requires
registration. A >50% utilization rate shall be considered efficient
for market area reassignments from the ISPs most recent allocation.

6.5.5.3.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /64 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.

## Resource Review ##

- Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
the following:

c. whenever ARIN has reason to believe that an organization is not
complying with reassignment policies, or

--

Rationale:

#Changes in this version:
After many conversations both at and following the last public policy
meeting in Toronto, some revisions have been made. These all address
specific concerns raised by multiple interested parties:
1) Organizational Information ? Phone number, street address and abuse
POC now required.
2) Residential Customer ? Added ?for personal use only? to the definition.
3) Registration  (4.2.3.7 & 6.5.5) ? Added ?but not limited to? WRT
assignment histories.
4) IPv6 ? Requires all /64 and larger blocks to be registered.
5) Resource Review ? Added this section.

#Short Rational:
This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with - at least as it relates to
reassignment information.
2) Specifically define what organizational information is required to
be added to WHOIS when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the
POC of their choice for any/all WHOIS entries in policy. This includes
designating an upstream POC as their own preferred POC (which allows
for simple reassignments).
4) Expands the privileges previously reserved solely for IPv4 cable
ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
5) Specifically define the term "residential customer."
6) Allow ARIN to conduct resource reviews based on failure to comply
with registration / reassignment policies.

#Expanded Rational:
1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
a) The IPv4 section is renamed "registration."
b) The IPv4 policy is shortened and rewritten for clarity.
c) The IPv6 policy is totally rewritten in a format that matches the
IPv4 policy.
* These structural changes are meant to make it easier to compare the
two sections. I believe that having the IPv6 and IPv4 policies written
in completely different formats and structures (as they are in many
cases now) confuses the issues and makes it very hard to understand
what is different and what is the same across the two sections.
Bringing them into a similar format should help ease the migration to
IPv6 as folks can quickly and easily understand the differences and
the similarities.
d) The IPv6 policy is altered from a /56 minimum needing to be
registered to a /64. A /64 is a single IPv6 subnet where as a /56
contains many subnets (that should all be recorded in the WHOIS
directory if handed out to other organizations).

2) This policy adds a definition of "organizational information" which
is used in the existing policy but not currently defined anywhere in
the NRPM.
a) The definition states that legal name and physical address are
required for client organizations.
b) The definition states that POCs are required but can be designated
by the client organization - it spells out that the client org can
choose to use their upstream as a POC.
c) The definition requires that each POC have a valid email address
and phone number.

3) This policy takes the privileges granted specifically to IPv4 cable
operators in section 4.2.6. "Cable Address Space Policy" and grants
them to all ISPs who serve residential areas.
a) It allows all ISPs with residential coverage to
register/swip/rwhois an entire market area.
b) It retains the existing residential customer privacy policy for all
customers with larger IP blocks.
* This change removes the need for any ISP to enter residential
customers into whois at all.

4) This policy also extends the >50% utilization rate, currently
granted only to IPv4 cable operators, to all ISPs with a residential
footprint.
* This change offsets the ability to register/swip/rwhois market
areas. For all other allocation types, efficient utilization is based
on SWIPs, not on actual utilization. When an organization is able to
SWIP an entire market area, this must be checked against actual
utilization. This policy maintains the current line set at >50%.
**The 50% mark on the most recent allocation is because you can
quickly distribute most of your address space across your provisioning
footprint, leaving nothing left for growth while the lease count of
the provisioned customers catches up to the blocks allocated. (Dan
Alexander's words)


5) Current policy references "residential customers" but there is no
current definition of residential customers in the NRPM. This has
reportedly been an on-going problem for ARIN and it?s customers.

6) Not properly registering reassignment information could be a sign
of other improper or illicit behavior and should justify a resource
review (audit) by ARIN when necessary, regardless of when the last
review took place.

--

Thank you,
~Chris


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From aaron at wholesaleinternet.net  Fri Jul 23 15:22:21 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Fri, 23 Jul 2010 14:22:21 -0500
Subject: [arin-ppml] Petition for discussion of policy proposal
	116	(Permitted Uses of Space Reserved Under NRPM 4.10)
In-Reply-To: <AANLkTim0XJgM2DWXj0GmZ9Exf+h9g0GLgtRfB=nATRwe@mail.gmail.com>
References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
	<AANLkTim0XJgM2DWXj0GmZ9Exf+h9g0GLgtRfB=nATRwe@mail.gmail.com>
Message-ID: <010101cb2a9c$64afd1e0$2e0f75a0$@net>

I support the petition to bring 116 to the meeting in Atlanta.

Aaron Wendel
Wholesale Internet, Inc.
324 E. 11th St.  Suite 1000
Kansas City, MO 64106
816-256-3031




From info at arin.net  Fri Jul 23 16:31:43 2010
From: info at arin.net (ARIN)
Date: Fri, 23 Jul 2010 16:31:43 -0400
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
 IP Reassignment Registration Requirements
Message-ID: <4C49FC2F.5050206@arin.net>

The message below started a petition regarding the ARIN Advisory
Council's decision not to select "Policy Proposal 109. Standardize IP
Reassignment Registration Requirements" as a draft policy at this time.
The AC's decision was posted by ARIN staff to PPML on 20 July 2010.

If successful, this petition will change Proposal 109 into a Draft
Policy which will be published for adoption discussion on the PPML and
at the Public Policy Meeting in October. If the petition fails, the
proposal will remain on the AC's docket.

For this petition to be successful, the petition needs statements of
support from at least 10 different people from 10 different
organizations. If you wish to support this petition, post a statement of
support to PPML on this thread. Point of contact information is
required, either to the entire PPML or with a follow up post to
petition at arin.net with full POC information (name, organization, street
address, email, phone).

The duration of the petition is until through five business days after
the AC's draft meeting minutes are published. ARIN staff will post the
result of the petition to PPML.

For more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


#####


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 1:51 PM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
> IP Reassignment Registration Requirements
>
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
>
> > The AC decided not to select Proposal 109 as a draft policy at this
> time:
> >
> > 109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
> sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
> both
> > IPv4 and IPv6, the distinction of residential customers, the
> utilization
> > requirements for subsequent allocations, and customer privacy are all
> > good topics, but agreement in some will be held up by any
> disagreements
> > on the others when trying to address them as one.
>
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
>
> If you support this petition, please send the following:
>
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
>
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
>
> --
>
> Author contact information:
>
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
>
> --
>
> Policy statement (v4):
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
> text:
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> --
>
> Rationale:
>
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information ? Phone number, street address and abuse
> POC now required.
> 2) Residential Customer ? Added ?for personal use only? to the
> definition.
> 3) Registration (4.2.3.7 & 6.5.5) ? Added ?but not limited to? WRT
> assignment histories.
> 4) IPv6 ? Requires all /64 and larger blocks to be registered.
> 5) Resource Review ? Added this section.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
>
>
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it?s customers.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
> --
>
> Thank you,
> ~Chris
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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 Marla.Azinger at FTR.com  Fri Jul 23 16:47:32 2010
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Fri, 23 Jul 2010 16:47:32 -0400
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
 IP Reassignment Registration Requirements
In-Reply-To: <4C49FC2F.5050206@arin.net>
References: <4C49FC2F.5050206@arin.net>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10488B6BD215@ROCH-EXCH1.corp.pvt>

I support this petition.  The latest text in this petition is technically sound, makes sense and is needed.  Breaking it down into bite sizes could be done but I don't see it as necessary.  Put together as it is right now, actually creates connection and flow to the pieces within it.

Cheers
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Friday, July 23, 2010 1:32 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP Reassignment Registration Requirements

The message below started a petition regarding the ARIN Advisory Council's decision not to select "Policy Proposal 109. Standardize IP Reassignment Registration Requirements" as a draft policy at this time.
The AC's decision was posted by ARIN staff to PPML on 20 July 2010.

If successful, this petition will change Proposal 109 into a Draft Policy which will be published for adoption discussion on the PPML and at the Public Policy Meeting in October. If the petition fails, the proposal will remain on the AC's docket.

For this petition to be successful, the petition needs statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone).

The duration of the petition is until through five business days after the AC's draft meeting minutes are published. ARIN staff will post the result of the petition to PPML.

For more information on starting and participating in petitions, see PDP Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


#####


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 1:51 PM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 -
> Standardize IP Reassignment Registration Requirements
>
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
>
> > The AC decided not to select Proposal 109 as a draft policy at this
> time:
> >
> > 109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
> sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
> both
> > IPv4 and IPv6, the distinction of residential customers, the
> utilization
> > requirements for subsequent allocations, and customer privacy are
> > all good topics, but agreement in some will be held up by any
> disagreements
> > on the others when trying to address them as one.
>
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
>
> If you support this petition, please send the following:
>
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
>
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
>
> --
>
> Author contact information:
>
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
>
> --
>
> Policy statement (v4):
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
> text:
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> --
>
> Rationale:
>
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information - Phone number, street address and abuse
> POC now required.
> 2) Residential Customer - Added "for personal use only" to the
> definition.
> 3) Registration (4.2.3.7 & 6.5.5) - Added "but not limited to" WRT
> assignment histories.
> 4) IPv6 - Requires all /64 and larger blocks to be registered.
> 5) Resource Review - Added this section.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
>
>
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it's customers.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
> --
>
> Thank you,
> ~Chris
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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 mksmith at adhost.com  Fri Jul 23 17:06:52 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 23 Jul 2010 14:06:52 -0700
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
	IPReassignment Registration Requirements
In-Reply-To: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>
References: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>
Message-ID: <17838240D9A5544AAA5FF95F8D520316088A0B9B@ad-exh01.adhost.lan>

I support the petition of proposal 109.
Michael K. Smith, Adhost Internet LLC, Contact in Sig
--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 10:51 AM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 -
Standardize
> IPReassignment Registration Requirements
> 
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
> 
> > The AC decided not to select Proposal 109 as a draft policy at this
time:
> >
> >  109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
both
> > IPv4 and IPv6, the distinction of residential customers, the
utilization
> > requirements for subsequent allocations, and customer privacy are
all
> > good topics, but agreement in some will be held up by any
disagreements
> > on the others when trying to address them as one.
> 
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
> 
> If you support this petition, please send the following:
> 
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
> 
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
> 
> --
> 
> Author contact information:
> 
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
> 
> --
> 
> Policy statement (v4):
> 
> ## Definitions ##
> 
> - Add:
> 
> 2.3. Organizational Information
> 
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
> 
> 2.12. Residential Customer
> 
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
> 
> ## IPv4 ##
> 
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
text:
> 
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
> 
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
> 
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
> 
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
> 
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
> 
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
> 
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
> 
> 4.2.3.7.3. Residential Subscribers
> 
> 4.2.3.7.3.1. Residential Market Area
> 
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
> 
> 4.2.3.7.3.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
> 
> - Strike section 4.2.6. "Cable Address Space Policy"
> 
> ## IPv6 ##
> 
> - Replace Section 6.5.5. with:
> 
> 6.5.5. Registration
> 
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
> 
> 6.5.5.1. Reassignment information
> 
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
> 
> 6.5.5.2. Assignments visible within 7 days
> 
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
> 
> 6.5.5.3. Residential Subscribers
> 
> 6.5.5.3.1. Residential Market Area
> 
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
> 
> 6.5.5.3.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
> 
> ## Resource Review ##
> 
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
> 
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
> 
> --
> 
> Rationale:
> 
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information - Phone number, street address and abuse
> POC now required.
> 2) Residential Customer - Added "for personal use only" to the
definition.
> 3) Registration  (4.2.3.7 & 6.5.5) - Added "but not limited to" WRT
> assignment histories.
> 4) IPv6 - Requires all /64 and larger blocks to be registered.
> 5) Resource Review - Added this section.
> 
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
> 
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
> 
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
> 
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
> 
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
> 
> 
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it's customers.
> 
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
> 
> --
> 
> Thank you,
> ~Chris
> 
> 
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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  Sat Jul 24 14:09:26 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 24 Jul 2010 08:09:26 -1000
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
	IP Reassignment Registration Requirements
In-Reply-To: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>
References: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>
Message-ID: <AANLkTimz8SX-3RnS_kCXEyY=fQmX+Ti3Hnncdd_1f-mP@mail.gmail.com>

On Fri, Jul 23, 2010 at 7:50 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>> ?109. Standardize IP Reassignment Registration Requirements
>>
>> Regarding Proposal 109, the AC would really like to see the sentiments
>> in this proposal re-surface in bite-size pieces. SWIP requirements, both
>> IPv4 and IPv6, the distinction of residential customers, the utilization
>> requirements for subsequent allocations, and customer privacy are all
>> good topics, but agreement in some will be held up by any disagreements
>> on the others when trying to address them as one.
>
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.

Hi Chris,

As much as I favor moving proposals to the full community, I agree
with the AC's assessment. At the very least it should come back as
separate v4 and v6 proposals before moving forward.

Pushing heavy-handed documentation requirements on IPv6 doesn't seem
particularly timely to me. If anything, a little deliberate
inattention could help grease the deployment skids. I would not
support a proposal that placed additional documentation requirements
on the use of IPv6 right now.

On the other hand, I hold IPv4 reassignments from Sprint, Verizon,
Cox, Qwest and Twtelecom. Of the five, only TWTelecom has registered
all of my reassignments /28 and larger in whois. Too many of the
X-Larges aren't holding up their end of the bargain when it comes to
the privileges they've been granted as LIRs. Given the impending
shortage of IPv4 addresses, it makes good sense to me to shorten the
leash.

For these reasons, I OPPOSE the petition to move the proposal 109
forward as written. Split it up and if the AC still fails to act on
it, ask me again.

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  Sat Jul 24 14:23:28 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 24 Jul 2010 11:23:28 -0700
Subject: [arin-ppml] Possible amendment to proposal 116
Message-ID: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>

I have received some comments on proposal 116 (currently under petition for discussion)
in private email and want to get some community feedback on the idea.

Basically, it has been suggested that rather than the list of example technologies and
leaving the decision of what represents a valid transitional technology up to staff that
the proposal be amended to have the BoT create a panel of experts which will meet
monthly (likely via teleconference) to consider what should or should not qualify as a
transitional technology for purposes of NRPM 4.10 et. seq.

My current inclination is to think that is a lot of extra process and rather heavy compared
to the need at hand, but, the author makes a compelling enough case i private that
I thought the matter was worthy of additional discussion in public. I won't repost
the author's private emails. He is subscribed to PPML and can express himself here
if he chooses. However, I would like to know what others think. The proposal can
be amended accordingly if there is community support to do so.

Finally, I would like to encourage any of you who think proposal 116 merits discussion
by the community, even if you do not support it as written, to support the petition so that
we get the opportunity to discuss it and refine it in Atlanta. Remember, supporting the
petition merely means that you want to give the community the opportunity to discuss
the matter. It does not necessarily mean that you support the proposal.

Owen



From cgrundemann at gmail.com  Sat Jul 24 15:38:16 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sat, 24 Jul 2010 13:38:16 -0600
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
	IP Reassignment Registration Requirements
In-Reply-To: <AANLkTimz8SX-3RnS_kCXEyY=fQmX+Ti3Hnncdd_1f-mP@mail.gmail.com>
References: <AANLkTim6zMphFCzJ0b9UmsykKvDWsmYk3REJjpYp34aR@mail.gmail.com>
	<AANLkTimz8SX-3RnS_kCXEyY=fQmX+Ti3Hnncdd_1f-mP@mail.gmail.com>
Message-ID: <AANLkTinsg-F0A=PUXN4vX=dcGV1PFGgQS+d_kshoM34C@mail.gmail.com>

On Sat, Jul 24, 2010 at 12:09, William Herrin <bill at herrin.us> wrote:
>
> Hi Chris,
>
> As much as I favor moving proposals to the full community, I agree
> with the AC's assessment. At the very least it should come back as
> separate v4 and v6 proposals before moving forward.
>
> Pushing heavy-handed documentation requirements on IPv6 doesn't seem
> particularly timely to me. If anything, a little deliberate
> inattention could help grease the deployment skids. I would not
> support a proposal that placed additional documentation requirements
> on the use of IPv6 right now.

I see it slightly differently - I think that bringing the IPv4 and
IPv6 requirements and policy text in line with each other as a
facilitator of IPv6 deployment. To quote myself: "These structural
changes are meant to make it easier to compare the two sections. I
believe that having the IPv6 and IPv4 policies written in completely
different formats and structures (as they are in many cases now)
confuses the issues and makes it very hard to understand what is
different and what is the same across the two sections. Bringing them
into a similar format should help ease the migration to IPv6 as folks
can quickly and easily understand the differences and the
similarities."

> On the other hand, I hold IPv4 reassignments from Sprint, Verizon,
> Cox, Qwest and Twtelecom. Of the five, only TWTelecom has registered
> all of my reassignments /28 and larger in whois. Too many of the
> X-Larges aren't holding up their end of the bargain when it comes to
> the privileges they've been granted as LIRs. Given the impending
> shortage of IPv4 addresses, it makes good sense to me to shorten the
> leash.

I am glad to hear that my employer is doing it right! And I fully
agree that most are not (and that something should be done about
that).

> For these reasons, I OPPOSE the petition to move the proposal 109
> forward as written. Split it up and if the AC still fails to act on
> it, ask me again.

Thanks for the feedback Bill. I am still very hopeful that this
petition succeeds and we are allowed to have this conversation at
length in Atlanta. =)
~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Sat Jul 24 18:09:51 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 24 Jul 2010 15:09:51 -0700
Subject: [arin-ppml] Discussion Petition for proposal 109
Message-ID: <22343950-C559-4A9A-A8DC-1AF12B571AFB@delong.com>

After careful consideration, I support the petition. I agree that the proposal should be
split into smaller pieces. However, abandoning it was not the best way to achieve
that. The proposal can be discussed as a whole and then subdivided or discussed
as a whole and moved forward based on community input.

To meet the formal requirements:

I support the discussion petition for proposal 109. I encourage others to do so.

The above opinion is mine and mine alone. I have no idea what any of my affiliated
organizations think about it.

Owen DeLong
ARIN AC
Hurricane Electric
DeLong Consulting
408-890-7992
owen at delong.com



From bill at herrin.us  Sun Jul 25 12:59:57 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 25 Jul 2010 06:59:57 -1000
Subject: [arin-ppml] Possible amendment to proposal 116
In-Reply-To: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
Message-ID: <AANLkTi=h4SWu_eJx4BZnfD4D9yXyunvvZjQtraPsP4_0@mail.gmail.com>

On Sat, Jul 24, 2010 at 8:23 AM, Owen DeLong <owen at delong.com> wrote:
> Basically, it has been suggested that rather than the list of example technologies and
> leaving the decision of what represents a valid transitional technology up to staff that
> the proposal be amended to have the BoT create a panel of experts which will meet
> monthly (likely via teleconference) to consider what should or should not qualify as a
> transitional technology for purposes of NRPM 4.10 et. seq.

I fess up to being the unnamed. Basically, my point was that there's
going to be a certain degree of subjectivity involved in deciding
whether a plan involving a particular transitional technology is
"valid."

Asking staff to make a case-by-case subjective judgment may not be the
best idea. Staff generally exhibits excellent judgment, but how would
we get consistent results between different staff members and how
would we handle objections when an application was denied?

I looked for a way to convert that subjective judgment into an
objective one that's consistent and accountable. What I came up with
was an experts panel and a BoT vote to accept their latest
recommendations.

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 Jul 26 06:47:12 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 26 Jul 2010 11:47:12 +0100
Subject: [arin-ppml] Possible amendment to proposal 116
In-Reply-To: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423917F86A9A@EMV01-UKBR.domain1.systemhost.net>

> I have received some comments on proposal 116 (currently under petition
> for discussion)
> in private email and want to get some community feedback on the idea.
> 
> Basically, it has been suggested that rather than the list of example
> technologies and
> leaving the decision of what represents a valid transitional technology
> up to staff that
> the proposal be amended to have the BoT create a panel of experts which
> will meet
> monthly (likely via teleconference) to consider what should or should
> not qualify as a
> transitional technology for purposes of NRPM 4.10 et. seq.

Just leave it open-ended. 

The ARIN staff are going to rely on "panel of experts" style advice in 
any case. There is no need to codify this kind of detail.

We have a glut of IPv6 addresses. If the transition addresses are mismanaged
and it takes us 5 years of discussion and overthrow of the BoT in order
to get the addresses back, this is still a drop in the bucket and will
not affect regular IPv6 allocation activity.

We just have to get out of this darn scarcity mindset, in particular when
it comes to helping the world get through this awkward transitionary period.

--Michael Dillon



From bill at herrin.us  Mon Jul 26 12:44:37 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Jul 2010 06:44:37 -1000
Subject: [arin-ppml] Possible amendment to proposal 116
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423917F86A9A@EMV01-UKBR.domain1.systemhost.net>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com> 
	<0F29D1BA57992E4CAB5AD2C9AE7B423917F86A9A@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <AANLkTinV2A+5epMPbrXhBgoZGqFv1w9HMD2-Obxciw4O@mail.gmail.com>

On Mon, Jul 26, 2010 at 12:47 AM,  <michael.dillon at bt.com> wrote:
> We have a glut of IPv6 addresses. If the transition addresses are mismanaged
> and it takes us 5 years of discussion and overthrow of the BoT in order
> to get the addresses back, this is still a drop in the bucket and will
> not affect regular IPv6 allocation activity.
>
> We just have to get out of this darn scarcity mindset, in particular when
> it comes to helping the world get through this awkward transitionary period.

Michael,

116 has to do with allocating from a set-aside block of scarce IPv4
addresses for projects that facilitate the transition to IPv6. It does
not address the allocation or assignment of IPv6 addresses at all.

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 mahannig at akamai.com  Mon Jul 26 15:57:01 2010
From: mahannig at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 15:57:01 -0400
Subject: [arin-ppml] Possible amendment to proposal 116
In-Reply-To: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
Message-ID: <C87360CD.A7E2%marty@akamai.com>




On 7/24/10 2:23 PM, "Owen DeLong" <owen at delong.com> wrote:

> I have received some comments on proposal 116 (currently under petition for
> discussion)
> in private email and want to get some community feedback on the idea.
> 
> Basically, it has been suggested that rather than the list of example
> technologies and
> leaving the decision of what represents a valid transitional technology up to
> staff that
> the proposal be amended to have the BoT create a panel of experts which will
> meet
> monthly (likely via teleconference) to consider what should or should not
> qualify as a
> transitional technology for purposes of NRPM 4.10 et. seq.


The idea of the last /8 should be around transition and business v. uptake,
not process and vagueness. You've been writing policy that makes it harder
to conduBusiness doesn't handle vagueness very well. Can you explain why you
think that this would be better than an acceptable use list? Or perhaps the
author can explain it himself?

BTW, from your actual proposal:

> e. etc.


Really?


  
> My current inclination is to think that is a lot of extra process and rather
> heavy compared
> to the need at hand, but, the author makes a compelling enough case i private
> that
> I thought the matter was worthy of additional discussion in public.


See above...

[ clip ]

 
> Finally, I would like to encourage any of you who think proposal 116 merits
> discussion
> by the community, even if you do not support it as written, to support the
> petition so that
> we get the opportunity to discuss it and refine it in Atlanta. Remember,
> supporting the
> petition merely means that you want to give the community the opportunity to
> discuss
> the matter. It does not necessarily mean that you support the proposal.
> 


This is still not a good reason to support this proposal. It falls VERY
short in reach and in depth. It's similar to Joe Maimon's proposal which was
declined in the petition process and I am sorry, but I think that this
should be declined as well.



Best,

Martin





From mahannig at akamai.com  Mon Jul 26 15:57:30 2010
From: mahannig at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 15:57:30 -0400
Subject: [arin-ppml] Petition for discussion of policy proposal 116
 (Permitted Uses of Space Reserved Under NRPM 4.10)
Message-ID: <C8735EAC.A7A3%marty@akamai.com>



Hi Owen,

I don?t support this petition. The work the ideas are good, but they were germane twelve months ago, not now. There is sentiment to set aside an entire /8 and be use it for only transition purposes and to help defray post exhaustion costs. This doesn?t go far or wide enough IMHO and I don?t see what you could compromise to make it acceptable.

Best Regards,

Martin Hannigan






On 7/21/10 2:19 AM, "Owen DeLong" <owen at delong.com> wrote:

The AC abandoned the following proposal:

 116. Permitted Uses of space reserved under NRPM 4.10

The AC voted to abandon this proposal because of a lack of sufficient
support to accept it as draft policy. Several AC members felt it not
appropriate that ARIN policy dictate any specific architecture or method
a network should use to transition from v4 to v6.

This is my formal request to initiate a discussion petition of proposal 116.

If you would like to sign this petition, please do the following:

1. Send a message stating "I support the petition for discussion of proposal 116"
to arin-ppml at arin.net

2. Either include your contact information and organizational affiliation in
the original message to ppml or send it in a separate message to
petition at arin.net (use this address if you do not want your contact
information disclosed to PPML).

Thank you.

I believe that the AC should not have abandoned this proposal for the following
reasons:

1. I believe that there is community support for clarifying valid uses and
preventing abuses of space reserved for transitional technologies under
section 4.10.

2. The language of 116 states examples of valid uses of space under 4.10
but does not specify or dictate specific architecture or methods. It attempts
to prevent space reserved for transition from being used in a business-as-
usual method that is not in direct support of a transition to IPv6 because
the author believes that is contrary to the community intent of 4.10.

I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid
technologies and includes specifically (e) etc. to cover any possible
valid technologies not yet contemplated.

3. The language in the existing 4.10 is not sufficiently specific to prevent
a multitude of possible abuses of the reserved space that do not actually
benefit a transition process.

For these reasons, I encourage anyone who feels that section 4.10 reflects the
good intent of the community to sign this discussion petition to get this policy
in front of the community in Atlanta. Even if you disagree with the specifics, those
can be addressed in the development of the policy. If you have comments on
those specifics, please direct them to ppml or to me.


Author contact information as required in the petition process:

Owen DeLong
owen at delong.com
+1.408.890.7992

Here is the text of the proposal in question as required in the petition
process:

Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
Proposal Originator: Owen DeLong
Proposal Version: 1
Date: 18 June 2010
Proposal type: modify
Policy term: permanent
Policy statement:
Add the following to section 4.10 of the NRPM
6. No organization may receive more than 16 /24 equivalents under this
section.
Add the following to section 4 of the NRPM
4.11 Required utilization for subsequent allocation under section 4.10
No organization shall receive more than one allocation or assignment
under section 4.10 unless all prior space issued under 4.10 meets the
utilization requirements of this section.
1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
2. All utilization must be permitted under section 4.12
3. All prior 4.10 allocation/assignments must be at least 90% utilized.
4.12 Permitted uses of allocations or assignments under section 4.10
No organization shall use space received under section 4.10 for any
purpose other than as specified in this section
1. To provide the required public IPv4 address(es) for transitional
technologies operated by the recipient organization.
a. Large scale or "Carrier Grade" NAT
b. NAT-PT
c. DS-LITE/AFTeR
d. DNS64 or other transitional DNS enablers
e. etc.
2. For other transitional technologies not envisioned at the time of
this proposal, but, in no case for general IPv4 addressing provided to
customers.
Rationale:
The current terminology in section 4.10 is vague and could allow a
variety of interpretations which could lead to allocations or
assignments being made to ISPs intending to misuse the space for general
deployment by using IPv6 overlay technologies as a "IPv6 deployments"
requiring IPv4 space for transition. For example, the current policy
could be interpreted to enable an ISP to require IPv4 addresses for all
IPv6 customers to roll IPv6 out as 6rd to customers who would be
otherwise unable to get IPv4 space. This is clearly outside of the
original intent of the proposal which created 4.10 (6rd was not yet
envisioned at the time that was written). This proposal seeks to clarify
that intent and tighten up the requirements for organizations seeking to
get space from this limited final resource so that it truly is available
to facilitate transitional technologies.
Timetable for implementation: immediate
For reference, here is the current text of 4.10
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.
In order to receive an allocation or assignment under this policy:
1. the applicant may not have received resources under this policy in
the preceding six months;
2. previous allocations/assignments under this policy must continue to
meet the justification requirements of this policy;
3. previous allocations/assignments under this policy must meet the
utilization requirements of end user assignments;
4. the applicant must demonstrate that no other allocations or
assignments will meet this need;
5. on subsequent allocation under this policy, ARIN staff may require
applicants to renumber out of previously allocated / assigned space
under this policy in order to minimize non-contiguous allocations.


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

From marty at akamai.com  Mon Jul 26 16:22:03 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 16:22:03 -0400
Subject: [arin-ppml] Set aside round deux
Message-ID: <C87366AB.A7FA%marty@akamai.com>



Hello PPML:


Since it seemed to have been very helpful to vet the global policy idea on
the list, I thought it might be helpful to use it to frame my non-support
for 109. This is, just like the last time, very raw, but I expect to solicit
some time during open policy hour to discuss a more polished version.

A few points. 

- This idea takes us in the direction of actual transition
- Define an acceptable use list
- Seeks to address COSTS
- Levels the playing field between small and large
- Reserves an entire /8 for transition, not for business as usual
- Counters the high priced "market" that is emerging by deferring it's need

May not get us all the way through, but every month that we can avoid
sending people to markets is a month of reduced costs IMHO. And it is about
costs at this point. It's a given that it is going to happen.

Too soon for "for" or "against", but most definitely open to feedback. Don't
focus on the words, focus on the ideas. Feedback very much appreciated.


--draft, group working comments removed for ease of read

1. Transition Pool
 
ARIN will set-aside the final /8 allocated form the IANA to facilitate
transition from IPv4 to IPv6. The resulting "transition pool" will become
immediately available for allocations under this policy. This pool will be
known as the "transition pool".

 2. Minimum and Maximum Allocation Unit

The minimum allocation unit will be a /20. The maximum allocation unit will
be /15. 

 2. Allocation Method
 
ARIN will determine and utilize the best method possible for allocations
with the goal of maximizing what can be allocated balanced by minimum
deaggregation. 

 3. Eligibility
 
An applicant will become eligible to receive IPv4 addresses from this pool
when they meet the following requirements:

1. Applicant will provide a written plan detailing how the addresses will be
used and on what devices.

2. Previous allocations or assignments under this policy must continue to
meet the justification requirements of this policy.

3. Must have applied for, been approved, received and be utilizing an ARIN
allocated IPv6 allocation or assignment.

4. All allocations or assignments made under this policy must be efficiently
utilized to a rate of 80%.

5. Applicant must demonstrate that no other allocations or assignments that
they have received will meet their requirements.

6. Applicants must provide documentation that demonstrates that the
addresses received under this policy will be used only on dual stack devices
that will have both an IPv4 and IPv6 address that will both be reachable
natively.  

7. Be in compliance with Section 4, Acceptable Use of Addresses.
 

4. Acceptable Use of Addresses

1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
each layer 3 contagious v6 only customer networks thereby enabling IPv4
connectivity for an IPv6-only customer networks. Customers must not have
available IPv4 addresses.

2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
an IPv6-only customer networks.. Customers must not have available IPv4
addresses. 

3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
additional IPv4 address to meet multi-homing traffic engineering needs or to
address stand-alone NAT devices as specified below:

A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
contiguous customer network that requires traffic engineering. For example a
network with two interconnects to a single upstream provider can get one
IPv4 /32 for each of their two interconnects, and distribute their internal
hosts between the two outside NAT addresses for traffic engineering.

B. Customer networks that require stand-alone NAT devices (not integrated
into their CPE router) qualify for enough IPv4 addresses to number the
loopback addresses (if needed) for all edge routers that have one or more
connections to a transit provider, enough IPv4 addresses to number each of
the point-to-point links between those routers and their transit provider,
as well as the point to point links between those routers and directly
connected NAT appliances. As well as one IPv4 address for each of these
directly connected NAT appliances.


4. Loopback addresses for edge routers that have one or more connections to
transit providers and/or peers

5. Address for point to point links between edge routers and their transit
providers [why does it need to be unique v. 1918?] [that is an interesting
point... We use globally unique as a matter of not breaking routing by
accident. I have to think about if it would be generally acceptable to use
RFC-1918. Interesting question!]

7. A /32 for routers in a greenfield network that are dual stacked.
[redundant to 3/5?] [this is not redundant... In this case I need an IPv4
routerID to make BGP work. If I want to be a green-filed IPv6 transit
provider I need one IPv4 address for each router]

8. /32 for public facing name servers, NTP servers, SMTP servers and Web
servers which are dual stacked and reachable on IPv4 and IPv6 networks.

9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator


 5. Reservation Forecasting
 
An applicant may provide ARIN with a thirty-month forecast of IPv4 address
need. ARIN will reserve the requested size in compliance with Section 2 and
3. When a reservation forecast is approved by ARIN, the applicant will then
be authorized to draw down from the forecast quarterly. Prior to requesting
reserved addresses, applicant will provide documentation to ARIN that they
have maintained utilization requirements for previous allocation. If
applicant fails to meet utilization requirements for two consecutive
quarters, ARIN will cancel the reservation and return unused addresses to
the pool. 


Example: 

Applicant applies to ARIN under this policy and submits a thirty-month
forecast requesting a /16. Using criteria established in the NRPM and this
policy, ARIN will determine if applicant is eligible and has need. If the
applicant meets the requirements for the allocation, they will reserve a
/16. The applicant will then be allocated 3/30th of the forecasted
requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
will round down allocations or assignments to the closest CIDR single block.
Rounding errors will be applied to the last allocation of the last quarter
of the thirty month period and allocated then.


 6. Dual Stack Requirement
 
Addresses from this pool may only be used on dual stack devices that are to
be reachable via both IPv4 and IPv6 networks.


 7. Application Frequency
 
Applicants may apply for address space from the transition pool once per
quarter. If an applicant has an existing thirty-month forecast that has been
approved by ARIN, they are ineligible to apply for more address space until
their reservation has been exhausted. If an applicant has had a reservation
cancelled due to policy compliance issues including utilization, they are
not eligble to apply for addresses.
 

8. Post Exhaustion Refresh
>From the point of the issuance of the final /8 from the IANA, ARIN will
dispose of all address space that it may receive using this policy. 



From owen at delong.com  Mon Jul 26 16:31:57 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Jul 2010 13:31:57 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C87366AB.A7FA%marty@akamai.com>
References: <C87366AB.A7FA%marty@akamai.com>
Message-ID: <35806189-FB7C-426E-94F1-6D1135779AA8@delong.com>

Marty,
	How do you expect anyone but the largest of the large and extra large
organizations to qualify for a /20 of IPv4 space under this proposal?

	This is a really interesting way to attempt to reserve the last /8 for use
only by the largest organizations ARIN serves, but, I really don't think that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

> 
> 
> Hello PPML:
> 
> 
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to solicit
> some time during open policy hour to discuss a more polished version.
> 
> A few points. 
> 
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's need
> 
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is about
> costs at this point. It's a given that it is going to happen.
> 
> Too soon for "for" or "against", but most definitely open to feedback. Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
> 
> 
> --draft, group working comments removed for ease of read
> 
> 1. Transition Pool
> 
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
> 
> 2. Minimum and Maximum Allocation Unit
> 
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15. 
> 
> 2. Allocation Method
> 
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation. 
> 
> 3. Eligibility
> 
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
> 
> 1. Applicant will provide a written plan detailing how the addresses will be
> used and on what devices.
> 
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
> 
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
> 
> 4. All allocations or assignments made under this policy must be efficiently
> utilized to a rate of 80%.
> 
> 5. Applicant must demonstrate that no other allocations or assignments that
> they have received will meet their requirements.
> 
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.  
> 
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
> 
> 
> 4. Acceptable Use of Addresses
> 
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
> 
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses. 
> 
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or to
> address stand-alone NAT devices as specified below:
> 
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their internal
> hosts between the two outside NAT addresses for traffic engineering.
> 
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
> 
> 
> 4. Loopback addresses for edge routers that have one or more connections to
> transit providers and/or peers
> 
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
> 
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
> 
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
> 
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
> 
> 
> 5. Reservation Forecasting
> 
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2 and
> 3. When a reservation forecast is approved by ARIN, the applicant will then
> be authorized to draw down from the forecast quarterly. Prior to requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool. 
> 
> 
> Example: 
> 
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
> 
> 
> 6. Dual Stack Requirement
> 
> Addresses from this pool may only be used on dual stack devices that are to
> be reachable via both IPv4 and IPv6 networks.
> 
> 
> 7. Application Frequency
> 
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has been
> approved by ARIN, they are ineligible to apply for more address space until
> their reservation has been exhausted. If an applicant has had a reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
> 
> 
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy. 
> 
> _______________________________________________
> 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 packetgrrl at gmail.com  Mon Jul 26 16:37:35 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Mon, 26 Jul 2010 14:37:35 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <35806189-FB7C-426E-94F1-6D1135779AA8@delong.com>
References: <C87366AB.A7FA%marty@akamai.com>
	<35806189-FB7C-426E-94F1-6D1135779AA8@delong.com>
Message-ID: <AANLkTinLixHhbD_MAedZWpEGXnEf1PGKcZwN3KsMubrL@mail.gmail.com>

Owen,

So do you feel that this is bad all around or just the minimum allocation
unit needs to be changed to something smaller?  Others out there?  What are
your thoughts regarding a minimum/maximum allocation size for this last /8?


----Cathy

On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:

> Marty,
>        How do you expect anyone but the largest of the large and extra
> large
> organizations to qualify for a /20 of IPv4 space under this proposal?
>
>        This is a really interesting way to attempt to reserve the last /8
> for use
> only by the largest organizations ARIN serves, but, I really don't think
> that
> is good policy.
>
> Owen
>
> On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:
>
> >
> >
> > Hello PPML:
> >
> >
> > Since it seemed to have been very helpful to vet the global policy idea
> on
> > the list, I thought it might be helpful to use it to frame my non-support
> > for 109. This is, just like the last time, very raw, but I expect to
> solicit
> > some time during open policy hour to discuss a more polished version.
> >
> > A few points.
> >
> > - This idea takes us in the direction of actual transition
> > - Define an acceptable use list
> > - Seeks to address COSTS
> > - Levels the playing field between small and large
> > - Reserves an entire /8 for transition, not for business as usual
> > - Counters the high priced "market" that is emerging by deferring it's
> need
> >
> > May not get us all the way through, but every month that we can avoid
> > sending people to markets is a month of reduced costs IMHO. And it is
> about
> > costs at this point. It's a given that it is going to happen.
> >
> > Too soon for "for" or "against", but most definitely open to feedback.
> Don't
> > focus on the words, focus on the ideas. Feedback very much appreciated.
> >
> >
> > --draft, group working comments removed for ease of read
> >
> > 1. Transition Pool
> >
> > ARIN will set-aside the final /8 allocated form the IANA to facilitate
> > transition from IPv4 to IPv6. The resulting "transition pool" will become
> > immediately available for allocations under this policy. This pool will
> be
> > known as the "transition pool".
> >
> > 2. Minimum and Maximum Allocation Unit
> >
> > The minimum allocation unit will be a /20. The maximum allocation unit
> will
> > be /15.
> >
> > 2. Allocation Method
> >
> > ARIN will determine and utilize the best method possible for allocations
> > with the goal of maximizing what can be allocated balanced by minimum
> > deaggregation.
> >
> > 3. Eligibility
> >
> > An applicant will become eligible to receive IPv4 addresses from this
> pool
> > when they meet the following requirements:
> >
> > 1. Applicant will provide a written plan detailing how the addresses will
> be
> > used and on what devices.
> >
> > 2. Previous allocations or assignments under this policy must continue to
> > meet the justification requirements of this policy.
> >
> > 3. Must have applied for, been approved, received and be utilizing an
> ARIN
> > allocated IPv6 allocation or assignment.
> >
> > 4. All allocations or assignments made under this policy must be
> efficiently
> > utilized to a rate of 80%.
> >
> > 5. Applicant must demonstrate that no other allocations or assignments
> that
> > they have received will meet their requirements.
> >
> > 6. Applicants must provide documentation that demonstrates that the
> > addresses received under this policy will be used only on dual stack
> devices
> > that will have both an IPv4 and IPv6 address that will both be reachable
> > natively.
> >
> > 7. Be in compliance with Section 4, Acceptable Use of Addresses.
> >
> >
> > 4. Acceptable Use of Addresses
> >
> > 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for
> each
> > each layer 3 contagious v6 only customer networks thereby enabling IPv4
> > connectivity for an IPv6-only customer networks. Customers must not have
> > available IPv4 addresses.
> >
> > 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for
> each
> > each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> > addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity
> for
> > an IPv6-only customer networks.. Customers must not have available IPv4
> > addresses.
> >
> > 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> > additional IPv4 address to meet multi-homing traffic engineering needs or
> to
> > address stand-alone NAT devices as specified below:
> >
> > A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> > contiguous customer network that requires traffic engineering. For
> example a
> > network with two interconnects to a single upstream provider can get one
> > IPv4 /32 for each of their two interconnects, and distribute their
> internal
> > hosts between the two outside NAT addresses for traffic engineering.
> >
> > B. Customer networks that require stand-alone NAT devices (not integrated
> > into their CPE router) qualify for enough IPv4 addresses to number the
> > loopback addresses (if needed) for all edge routers that have one or more
> > connections to a transit provider, enough IPv4 addresses to number each
> of
> > the point-to-point links between those routers and their transit
> provider,
> > as well as the point to point links between those routers and directly
> > connected NAT appliances. As well as one IPv4 address for each of these
> > directly connected NAT appliances.
> >
> >
> > 4. Loopback addresses for edge routers that have one or more connections
> to
> > transit providers and/or peers
> >
> > 5. Address for point to point links between edge routers and their
> transit
> > providers [why does it need to be unique v. 1918?] [that is an
> interesting
> > point... We use globally unique as a matter of not breaking routing by
> > accident. I have to think about if it would be generally acceptable to
> use
> > RFC-1918. Interesting question!]
> >
> > 7. A /32 for routers in a greenfield network that are dual stacked.
> > [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> > routerID to make BGP work. If I want to be a green-filed IPv6 transit
> > provider I need one IPv4 address for each router]
> >
> > 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> > servers which are dual stacked and reachable on IPv4 and IPv6 networks.
> >
> > 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN
> aggregator
> >
> >
> > 5. Reservation Forecasting
> >
> > An applicant may provide ARIN with a thirty-month forecast of IPv4
> address
> > need. ARIN will reserve the requested size in compliance with Section 2
> and
> > 3. When a reservation forecast is approved by ARIN, the applicant will
> then
> > be authorized to draw down from the forecast quarterly. Prior to
> requesting
> > reserved addresses, applicant will provide documentation to ARIN that
> they
> > have maintained utilization requirements for previous allocation. If
> > applicant fails to meet utilization requirements for two consecutive
> > quarters, ARIN will cancel the reservation and return unused addresses to
> > the pool.
> >
> >
> > Example:
> >
> > Applicant applies to ARIN under this policy and submits a thirty-month
> > forecast requesting a /16. Using criteria established in the NRPM and
> this
> > policy, ARIN will determine if applicant is eligible and has need. If the
> > applicant meets the requirements for the allocation, they will reserve a
> > /16. The applicant will then be allocated 3/30th of the forecasted
> > requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> > will round down allocations or assignments to the closest CIDR single
> block.
> > Rounding errors will be applied to the last allocation of the last
> quarter
> > of the thirty month period and allocated then.
> >
> >
> > 6. Dual Stack Requirement
> >
> > Addresses from this pool may only be used on dual stack devices that are
> to
> > be reachable via both IPv4 and IPv6 networks.
> >
> >
> > 7. Application Frequency
> >
> > Applicants may apply for address space from the transition pool once per
> > quarter. If an applicant has an existing thirty-month forecast that has
> been
> > approved by ARIN, they are ineligible to apply for more address space
> until
> > their reservation has been exhausted. If an applicant has had a
> reservation
> > cancelled due to policy compliance issues including utilization, they are
> > not eligble to apply for addresses.
> >
> >
> > 8. Post Exhaustion Refresh
> >> From the point of the issuance of the final /8 from the IANA, ARIN will
> > dispose of all address space that it may receive using this policy.
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100726/b89115e0/attachment.htm>

From marty at akamai.com  Mon Jul 26 16:47:38 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 16:47:38 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinLixHhbD_MAedZWpEGXnEf1PGKcZwN3KsMubrL@mail.gmail.com>
Message-ID: <C8736CAA.A817%marty@akamai.com>



I?m not sure he read it close enough based on the off the cuff fear mongering.

I think that it comes down mostly to this:

>> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
>> need. ARIN will reserve the requested size in compliance with Section 2 and
>> 3. When a reservation forecast is approved by ARIN, the applicant will then
>> be authorized to draw down from the forecast quarterly. Prior to requesting
>> reserved addresses, applicant will provide documentation to ARIN that they
>> have maintained utilization requirements for previous allocation. If
>> applicant fails to meet utilization requirements for two consecutive
>> quarters, ARIN will cancel the reservation and return unused addresses to
>> the pool.

Based on that, an entity would need to qualify for a /20 over a $long time span. The time span noted does not perfectly match up to CIDR boundaries FWIW, but it will when everything is settled.

Qualifying for a /20 of transition address space over a 2 to 3 year period doesn?t exclude the little guys and coupling it to the same acceptable use for everyone seems to make it fair. In the case of someone who can?t qualify for roughly a /24 every quarter of $long time span, going to their upstream for help seems reasonable. In doing that we help to keep their costs down as well.



Best,

-M<



On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:

Owen,

So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?

----Cathy

On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
Marty,
        How do you expect anyone but the largest of the large and extra large
organizations to qualify for a /20 of IPv4 space under this proposal?

        This is a really interesting way to attempt to reserve the last /8 for use
only by the largest organizations ARIN serves, but, I really don't think that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

>
>
> Hello PPML:
>
>
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to solicit
> some time during open policy hour to discuss a more polished version.
>
> A few points.
>
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's need
>
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is about
> costs at this point. It's a given that it is going to happen.
>
> Too soon for "for" or "against", but most definitely open to feedback. Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
>
>
> --draft, group working comments removed for ease of read
>
> 1. Transition Pool
>
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
>
> 2. Minimum and Maximum Allocation Unit
>
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15.
>
> 2. Allocation Method
>
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation.
>
> 3. Eligibility
>
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
>
> 1. Applicant will provide a written plan detailing how the addresses will be
> used and on what devices.
>
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
>
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
>
> 4. All allocations or assignments made under this policy must be efficiently
> utilized to a rate of 80%.
>
> 5. Applicant must demonstrate that no other allocations or assignments that
> they have received will meet their requirements.
>
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.
>
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>
>
> 4. Acceptable Use of Addresses
>
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
>
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses.
>
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or to
> address stand-alone NAT devices as specified below:
>
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their internal
> hosts between the two outside NAT addresses for traffic engineering.
>
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
>
>
> 4. Loopback addresses for edge routers that have one or more connections to
> transit providers and/or peers
>
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
>
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
>
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>
>
> 5. Reservation Forecasting
>
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2 and
> 3. When a reservation forecast is approved by ARIN, the applicant will then
> be authorized to draw down from the forecast quarterly. Prior to requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool.
>
>
> Example:
>
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
>
>
> 6. Dual Stack Requirement
>
> Addresses from this pool may only be used on dual stack devices that are to
> be reachable via both IPv4 and IPv6 networks.
>
>
> 7. Application Frequency
>
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has been
> approved by ARIN, they are ineligible to apply for more address space until
> their reservation has been exhausted. If an applicant has had a reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
>
>
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


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

From marty at akamai.com  Mon Jul 26 16:49:02 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 16:49:02 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinLixHhbD_MAedZWpEGXnEf1PGKcZwN3KsMubrL@mail.gmail.com>
Message-ID: <C8736CFE.A81C%marty@akamai.com>



And a minor correction please. I meant proposal 116 v. 109 when I referenced it.


On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:

Owen,

So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?

----Cathy

On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
Marty,
        How do you expect anyone but the largest of the large and extra large
organizations to qualify for a /20 of IPv4 space under this proposal?

        This is a really interesting way to attempt to reserve the last /8 for use
only by the largest organizations ARIN serves, but, I really don't think that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

>
>
> Hello PPML:
>
>
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to solicit
> some time during open policy hour to discuss a more polished version.
>
> A few points.
>
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's need
>
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is about
> costs at this point. It's a given that it is going to happen.
>
> Too soon for "for" or "against", but most definitely open to feedback. Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
>
>
> --draft, group working comments removed for ease of read
>
> 1. Transition Pool
>
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
>
> 2. Minimum and Maximum Allocation Unit
>
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15.
>
> 2. Allocation Method
>
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation.
>
> 3. Eligibility
>
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
>
> 1. Applicant will provide a written plan detailing how the addresses will be
> used and on what devices.
>
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
>
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
>
> 4. All allocations or assignments made under this policy must be efficiently
> utilized to a rate of 80%.
>
> 5. Applicant must demonstrate that no other allocations or assignments that
> they have received will meet their requirements.
>
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.
>
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>
>
> 4. Acceptable Use of Addresses
>
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
>
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses.
>
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or to
> address stand-alone NAT devices as specified below:
>
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their internal
> hosts between the two outside NAT addresses for traffic engineering.
>
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
>
>
> 4. Loopback addresses for edge routers that have one or more connections to
> transit providers and/or peers
>
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
>
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
>
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>
>
> 5. Reservation Forecasting
>
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2 and
> 3. When a reservation forecast is approved by ARIN, the applicant will then
> be authorized to draw down from the forecast quarterly. Prior to requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool.
>
>
> Example:
>
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
>
>
> 6. Dual Stack Requirement
>
> Addresses from this pool may only be used on dual stack devices that are to
> be reachable via both IPv4 and IPv6 networks.
>
>
> 7. Application Frequency
>
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has been
> approved by ARIN, they are ineligible to apply for more address space until
> their reservation has been exhausted. If an applicant has had a reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
>
>
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


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

From cgrundemann at gmail.com  Mon Jul 26 16:49:07 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 26 Jul 2010 14:49:07 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C87366AB.A7FA%marty@akamai.com>
References: <C87366AB.A7FA%marty@akamai.com>
Message-ID: <AANLkTikEPBBB14DF9P5-RWRwJ3rC1N_JP=ujUsvf6c_N@mail.gmail.com>

On Mon, Jul 26, 2010 at 14:22, Hannigan, Martin <marty at akamai.com> wrote:
>
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 116.

I fixed your post - pp109 is about WHOIS and resource reservation,
pp116 is about the reservation of IPv4.

> ?2. Minimum and Maximum Allocation Unit
>
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15.

Why not a /24 minimum?


~Chris


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





-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Mon Jul 26 17:00:17 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Jul 2010 14:00:17 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C8736CAA.A817%marty@akamai.com>
References: <C8736CAA.A817%marty@akamai.com>
Message-ID: <7E05595B-4163-4594-9EDE-C794DA3568EE@delong.com>

I did read it... A little math...

Let's assume you're trying to use this for NAT64 boxes... At an estimated 5,000 customers per NAT64
box (most people I've talked to are talking between 8,000 and 80,000 per box), to qualify for a /20
using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of 20,480,000
which works out to 16,384,000 customers in order to justify a minimum allocation under this policy.

If you think that small providers have 16,000,000+ customers, we have radically different ideas
of what constitutes small.

Owen

On Jul 26, 2010, at 1:47 PM, Hannigan, Martin wrote:

> 
> 
> I?m not sure he read it close enough based on the off the cuff fear mongering. 
> 
> I think that it comes down mostly to this:
> 
> >> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> >> need. ARIN will reserve the requested size in compliance with Section 2 and
> >> 3. When a reservation forecast is approved by ARIN, the applicant will then
> >> be authorized to draw down from the forecast quarterly. Prior to requesting
> >> reserved addresses, applicant will provide documentation to ARIN that they
> >> have maintained utilization requirements for previous allocation. If
> >> applicant fails to meet utilization requirements for two consecutive
> >> quarters, ARIN will cancel the reservation and return unused addresses to
> >> the pool. 
> 
> Based on that, an entity would need to qualify for a /20 over a $long time span. The time span noted does not perfectly match up to CIDR boundaries FWIW, but it will when everything is settled. 
> 
> Qualifying for a /20 of transition address space over a 2 to 3 year period doesn?t exclude the little guys and coupling it to the same acceptable use for everyone seems to make it fair. In the case of someone who can?t qualify for roughly a /24 every quarter of $long time span, going to their upstream for help seems reasonable. In doing that we help to keep their costs down as well.
> 
> 
> 
> Best,
> 
> -M<
> 
> 
> 
> On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:
> 
>> Owen,
>> 
>> So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?  
>> 
>> ----Cathy
>> 
>> On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
>>> Marty,
>>>         How do you expect anyone but the largest of the large and extra large
>>> organizations to qualify for a /20 of IPv4 space under this proposal?
>>> 
>>>         This is a really interesting way to attempt to reserve the last /8 for use
>>> only by the largest organizations ARIN serves, but, I really don't think that
>>> is good policy.
>>> 
>>> Owen
>>> 
>>> On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:
>>> 
>>> >
>>> >
>>> > Hello PPML:
>>> >
>>> >
>>> > Since it seemed to have been very helpful to vet the global policy idea on
>>> > the list, I thought it might be helpful to use it to frame my non-support
>>> > for 109. This is, just like the last time, very raw, but I expect to solicit
>>> > some time during open policy hour to discuss a more polished version.
>>> >
>>> > A few points.
>>> >
>>> > - This idea takes us in the direction of actual transition
>>> > - Define an acceptable use list
>>> > - Seeks to address COSTS
>>> > - Levels the playing field between small and large
>>> > - Reserves an entire /8 for transition, not for business as usual
>>> > - Counters the high priced "market" that is emerging by deferring it's need
>>> >
>>> > May not get us all the way through, but every month that we can avoid
>>> > sending people to markets is a month of reduced costs IMHO. And it is about
>>> > costs at this point. It's a given that it is going to happen.
>>> >
>>> > Too soon for "for" or "against", but most definitely open to feedback. Don't
>>> > focus on the words, focus on the ideas. Feedback very much appreciated.
>>> >
>>> >
>>> > --draft, group working comments removed for ease of read
>>> >
>>> > 1. Transition Pool
>>> >
>>> > ARIN will set-aside the final /8 allocated form the IANA to facilitate
>>> > transition from IPv4 to IPv6. The resulting "transition pool" will become
>>> > immediately available for allocations under this policy. This pool will be
>>> > known as the "transition pool".
>>> >
>>> > 2. Minimum and Maximum Allocation Unit
>>> >
>>> > The minimum allocation unit will be a /20. The maximum allocation unit will
>>> > be /15.
>>> >
>>> > 2. Allocation Method
>>> >
>>> > ARIN will determine and utilize the best method possible for allocations
>>> > with the goal of maximizing what can be allocated balanced by minimum
>>> > deaggregation.
>>> >
>>> > 3. Eligibility
>>> >
>>> > An applicant will become eligible to receive IPv4 addresses from this pool
>>> > when they meet the following requirements:
>>> >
>>> > 1. Applicant will provide a written plan detailing how the addresses will be
>>> > used and on what devices.
>>> >
>>> > 2. Previous allocations or assignments under this policy must continue to
>>> > meet the justification requirements of this policy.
>>> >
>>> > 3. Must have applied for, been approved, received and be utilizing an ARIN
>>> > allocated IPv6 allocation or assignment.
>>> >
>>> > 4. All allocations or assignments made under this policy must be efficiently
>>> > utilized to a rate of 80%.
>>> >
>>> > 5. Applicant must demonstrate that no other allocations or assignments that
>>> > they have received will meet their requirements.
>>> >
>>> > 6. Applicants must provide documentation that demonstrates that the
>>> > addresses received under this policy will be used only on dual stack devices
>>> > that will have both an IPv4 and IPv6 address that will both be reachable
>>> > natively.
>>> >
>>> > 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>>> >
>>> >
>>> > 4. Acceptable Use of Addresses
>>> >
>>> > 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
>>> > each layer 3 contagious v6 only customer networks thereby enabling IPv4
>>> > connectivity for an IPv6-only customer networks. Customers must not have
>>> > available IPv4 addresses.
>>> >
>>> > 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
>>> > each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
>>> > addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
>>> > an IPv6-only customer networks.. Customers must not have available IPv4
>>> > addresses.
>>> >
>>> > 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
>>> > additional IPv4 address to meet multi-homing traffic engineering needs or to
>>> > address stand-alone NAT devices as specified below:
>>> >
>>> > A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
>>> > contiguous customer network that requires traffic engineering. For example a
>>> > network with two interconnects to a single upstream provider can get one
>>> > IPv4 /32 for each of their two interconnects, and distribute their internal
>>> > hosts between the two outside NAT addresses for traffic engineering.
>>> >
>>> > B. Customer networks that require stand-alone NAT devices (not integrated
>>> > into their CPE router) qualify for enough IPv4 addresses to number the
>>> > loopback addresses (if needed) for all edge routers that have one or more
>>> > connections to a transit provider, enough IPv4 addresses to number each of
>>> > the point-to-point links between those routers and their transit provider,
>>> > as well as the point to point links between those routers and directly
>>> > connected NAT appliances. As well as one IPv4 address for each of these
>>> > directly connected NAT appliances.
>>> >
>>> >
>>> > 4. Loopback addresses for edge routers that have one or more connections to
>>> > transit providers and/or peers
>>> >
>>> > 5. Address for point to point links between edge routers and their transit
>>> > providers [why does it need to be unique v. 1918?] [that is an interesting
>>> > point... We use globally unique as a matter of not breaking routing by
>>> > accident. I have to think about if it would be generally acceptable to use
>>> > RFC-1918. Interesting question!]
>>> >
>>> > 7. A /32 for routers in a greenfield network that are dual stacked.
>>> > [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
>>> > routerID to make BGP work. If I want to be a green-filed IPv6 transit
>>> > provider I need one IPv4 address for each router]
>>> >
>>> > 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
>>> > servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>>> >
>>> > 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>>> >
>>> >
>>> > 5. Reservation Forecasting
>>> >
>>> > An applicant may provide ARIN with a thirty-month forecast of IPv4 address
>>> > need. ARIN will reserve the requested size in compliance with Section 2 and
>>> > 3. When a reservation forecast is approved by ARIN, the applicant will then
>>> > be authorized to draw down from the forecast quarterly. Prior to requesting
>>> > reserved addresses, applicant will provide documentation to ARIN that they
>>> > have maintained utilization requirements for previous allocation. If
>>> > applicant fails to meet utilization requirements for two consecutive
>>> > quarters, ARIN will cancel the reservation and return unused addresses to
>>> > the pool.
>>> >
>>> >
>>> > Example:
>>> >
>>> > Applicant applies to ARIN under this policy and submits a thirty-month
>>> > forecast requesting a /16. Using criteria established in the NRPM and this
>>> > policy, ARIN will determine if applicant is eligible and has need. If the
>>> > applicant meets the requirements for the allocation, they will reserve a
>>> > /16. The applicant will then be allocated 3/30th of the forecasted
>>> > requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
>>> > will round down allocations or assignments to the closest CIDR single block.
>>> > Rounding errors will be applied to the last allocation of the last quarter
>>> > of the thirty month period and allocated then.
>>> >
>>> >
>>> > 6. Dual Stack Requirement
>>> >
>>> > Addresses from this pool may only be used on dual stack devices that are to
>>> > be reachable via both IPv4 and IPv6 networks.
>>> >
>>> >
>>> > 7. Application Frequency
>>> >
>>> > Applicants may apply for address space from the transition pool once per
>>> > quarter. If an applicant has an existing thirty-month forecast that has been
>>> > approved by ARIN, they are ineligible to apply for more address space until
>>> > their reservation has been exhausted. If an applicant has had a reservation
>>> > cancelled due to policy compliance issues including utilization, they are
>>> > not eligble to apply for addresses.
>>> >
>>> >
>>> > 8. Post Exhaustion Refresh
>>> >> From the point of the issuance of the final /8 from the IANA, ARIN will
>>> > dispose of all address space that it may receive using this policy.
>>> >
>>> > _______________________________________________
>>> > 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100726/28a9170d/attachment.htm>

From marty at akamai.com  Mon Jul 26 17:30:30 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 17:30:30 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <7E05595B-4163-4594-9EDE-C794DA3568EE@delong.com>
Message-ID: <C87376B6.A832%marty@akamai.com>




On 7/26/10 5:00 PM, "Owen DeLong" <owen at delong.com> wrote:

> I did read it... A little math...


> 
> Let's assume you're trying to use this for NAT64 boxes... At an estimated
> 5,000 customers per NAT64
> box (most people I've talked to are talking between 8,000 and 80,000 per box),
> to qualify for a /20
> using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of
> 20,480,000
> which works out to 16,384,000 customers in order to justify a minimum
> allocation under this policy.
> 
> If you think that small providers have 16,000,000+ customers, we have
> radically different ideas
> of what constitutes small.
> 


That would be some very fuzzy math from my perspective. If the same network
that only needs a /32 for a NAT device also needs a /20 to use for purposes
defined on the acceptable use list then I think that they're in good shape.
If a network is so small and not expecting to grow at all in $time, I'm not
so sure why it wouldn't make sense for them to scrounge up an address or ask
their upstream for "one" (both of which are much more likely to be routable
at least in the early stages of transition).

Alas, I'm not really in a position to argue the min/max until I receive some
constructive feedback, which was the main purpose of the post.


Best,

-M<




From scottleibrand at gmail.com  Mon Jul 26 17:45:05 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 26 Jul 2010 14:45:05 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C87376B6.A832%marty@akamai.com>
References: <C87376B6.A832%marty@akamai.com>
Message-ID: <4C4E01E1.6040708@gmail.com>

On Mon 7/26/2010 2:30 PM, Hannigan, Martin wrote:
> If the same network that only needs a /32 for a NAT device also needs a /20 to use
> for purposes defined on the acceptable use list then I think that they're in good
> shape. If a network is so small and not expecting to grow at all in $time, I'm not
> so sure why it wouldn't make sense for them to scrounge up an address or ask
> their upstream for "one" (both of which are much more likely to be routable
> at least in the early stages of transition).
>    
> Alas, I'm not really in a position to argue the min/max until I receive some
> constructive feedback, which was the main purpose of the post.
>    


So the current minimum allocation size (for singly-homed ISPs) of a /20 
is based on the assumption that every customer can get a public IP.  As 
I understand it, this proposal would change that assumption to only 
provide public IPv4 addresses for network infrastructure and translation 
gear.  (Is that correct?)  If so, the same sized ISP would need far 
fewer public IPv4 addresses. So it would seem to me that a much smaller 
minimum allocation size (like /24) would be more appropriate here...

-Scott


From marty at akamai.com  Mon Jul 26 18:17:56 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 26 Jul 2010 18:17:56 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C4E01E1.6040708@gmail.com>
Message-ID: <C87381D4.A846%marty@akamai.com>




On 7/26/10 5:45 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

> On Mon 7/26/2010 2:30 PM, Hannigan, Martin wrote:
>> If the same network that only needs a /32 for a NAT device also needs a /20
>> to use
>> for purposes defined on the acceptable use list then I think that they're in
>> good
>> shape. If a network is so small and not expecting to grow at all in $time,
>> I'm not
>> so sure why it wouldn't make sense for them to scrounge up an address or ask
>> their upstream for "one" (both of which are much more likely to be routable
>> at least in the early stages of transition).
>>    
>> Alas, I'm not really in a position to argue the min/max until I receive some
>> constructive feedback, which was the main purpose of the post.
>>    
> 
> 
> So the current minimum allocation size (for singly-homed ISPs) of a /20
> is based on the assumption that every customer can get a public IP.  As
> I understand it, this proposal would change that assumption to only
> provide public IPv4 addresses for network infrastructure and translation
> gear.  (Is that correct?)


That would be in-line with the intent.


> If so, the same sized ISP would need far
> fewer public IPv4 addresses. So it would seem to me that a much smaller
> minimum allocation size (like /24) would be more appropriate here...
> 

I can't immediately see a problem with a /24 as a minimum, but I currently
do not have enough information to agree. There is a balance though and I
don't see why I can't be found (and justified).


Best,

-M<






From owen at delong.com  Mon Jul 26 18:40:29 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 26 Jul 2010 15:40:29 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C87376B6.A832%marty@akamai.com>
References: <C87376B6.A832%marty@akamai.com>
Message-ID: <BC45F5EB-DA23-4620-96B1-8CB7F63877BA@delong.com>

OK... A little less fuzzy analysis of the policy and it's mathematical
implications...


The acceptable use list is (desirably in my opinion) pretty limited.
I can't imagine expanding any combination of the following:

	Router Loopbacks
	NAT Gateways
	Qualifying TE entries
	Point to Point links

Adding up to a /20 or even 80% of a /20 for any established network
even over 3 years unless they are VERY large and growing rather
quickly.

As to making IPv4 addresses available for business as usual assignments
to web, NTP, DNS, and other servers that happen to be dual-stacked, I think
this is a very bad idea and provides a huge loophole in the policy. It basically
allows hosting providers and certain others to get unlimited IPv4 as usual
from this pool. Admittedly, this makes it pretty easy for smaller organizations
to get IPv4 from this pool, but, it also makes it pretty unlikely that the pool
will last much longer than any other /8 which I think is counterproductive
to the stated intent of the policy.

However, if we reserve the pool to purposes of actual transition, for example,
eliminate the business-as-usual assignments for public facing servers and
restrict it to NAT-PT-style gateways, B4/AFTR implementations, DNS64
servers and other things actually designed to provide transitional interoperation
between IPv6-only and IPv4-only systems, then, I think you'll be hard
pressed to consume that much address space unless you are a very large
provider.

Owen

On Jul 26, 2010, at 2:30 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 7/26/10 5:00 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> I did read it... A little math...
> 
> 
>> 
>> Let's assume you're trying to use this for NAT64 boxes... At an estimated
>> 5,000 customers per NAT64
>> box (most people I've talked to are talking between 8,000 and 80,000 per box),
>> to qualify for a /20
>> using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of
>> 20,480,000
>> which works out to 16,384,000 customers in order to justify a minimum
>> allocation under this policy.
>> 
>> If you think that small providers have 16,000,000+ customers, we have
>> radically different ideas
>> of what constitutes small.
>> 
> 
> 
> That would be some very fuzzy math from my perspective. If the same network
> that only needs a /32 for a NAT device also needs a /20 to use for purposes
> defined on the acceptable use list then I think that they're in good shape.
> If a network is so small and not expecting to grow at all in $time, I'm not
> so sure why it wouldn't make sense for them to scrounge up an address or ask
> their upstream for "one" (both of which are much more likely to be routable
> at least in the early stages of transition).
> 
> Alas, I'm not really in a position to argue the min/max until I receive some
> constructive feedback, which was the main purpose of the post.
> 
> 
> Best,
> 
> -M<
> 



From bill at herrin.us  Mon Jul 26 19:31:05 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Jul 2010 13:31:05 -1000
Subject: [arin-ppml] Possible amendment to proposal 116
In-Reply-To: <C87360CD.A7E2%marty@akamai.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com> 
	<C87360CD.A7E2%marty@akamai.com>
Message-ID: <AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>

On Mon, Jul 26, 2010 at 9:57 AM, Hannigan, Martin <mahannig at akamai.com> wrote:
> On 7/24/10 2:23 PM, "Owen DeLong" <owen at delong.com> wrote:
>> the proposal be amended to have the BoT create a panel of experts which will
>> [] consider what should or should not qualify as a
>> transitional technology for purposes of NRPM 4.10 et. seq.
>
> The idea of the last /8 should be around transition and business v. uptake,
> not process and vagueness. You've been writing policy that makes it harder
> to conduBusiness doesn't handle vagueness very well. Can you explain why you
> think that this would be better than an acceptable use list?

Hi Martin,

Yes, I can explain.

First of all, an acceptable use list is the end result of the experts
panel. That's what they'd do: create an explicit list of acceptable
uses for for the addresses reserved by 4.10. Your plan isn't on the
list? No addresses for you until the experts panel reviews your
notion, decides to add it to the list and determines how many
addresses that plan justifies.

Why an experts panel? Why not hash it out here on PPML?

A. Hash it out on PPML? Really?

B. We don't yet have a good grasp on what the v6 transitional best
practices will be. Or any grasp really. We know there will be...
something.

As that picture clarifies, ARIN should be able to respond in a timely
manner. The 12 to 18 month cycle for policy changes is many things,
but timely isn't one of them. A small  experts panel, 3 to 5 people
that meet as needed, could amend the acceptable use list with a
turnaround time of weeks or even days.

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  Mon Jul 26 19:42:15 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 26 Jul 2010 13:42:15 -1000
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <BC45F5EB-DA23-4620-96B1-8CB7F63877BA@delong.com>
References: <C87376B6.A832%marty@akamai.com>
	<BC45F5EB-DA23-4620-96B1-8CB7F63877BA@delong.com>
Message-ID: <AANLkTi=StxcJkb_X-9MRduxQDxJ60hY3HLVb-FLCNHbh@mail.gmail.com>

On Mon, Jul 26, 2010 at 12:40 PM, Owen DeLong <owen at delong.com> wrote:
> The acceptable use list is (desirably in my opinion) pretty limited.
> I can't imagine expanding any combination of the following:
>
> ? ? ? ?Router Loopbacks
> ? ? ? ?NAT Gateways
> ? ? ? ?Qualifying TE entries
> ? ? ? ?Point to Point links

I don't think we even give 'em point to point links. For the last /8
the vendors can damn well fix their code to originate ICMP from the
loop0 address instead of the RFC1918 address on the interface.

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 schiller at uu.net  Mon Jul 26 22:22:09 2010
From: schiller at uu.net (Jason Schiller)
Date: Mon, 26 Jul 2010 22:22:09 -0400 (EDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTikEPBBB14DF9P5-RWRwJ3rC1N_JP=ujUsvf6c_N@mail.gmail.com>
References: <C87366AB.A7FA%marty@akamai.com>
	<AANLkTikEPBBB14DF9P5-RWRwJ3rC1N_JP=ujUsvf6c_N@mail.gmail.com>
Message-ID: <alpine.GSO.2.00.1007261703420.17216@peermon.argfrp.us.uu.net>

Chris,

I'm not sure I understand your why not a /24 comment... can you clarify?

|An applicant may provide ARIN with a thirty-month forecast of IPv4 
|address need. ... When a reservation forecast is approved by ARIN, the 
|applicant will then be authorized to draw down from the forecast 
|quarterly. 

Are you saying:

1. A customer with ten 3-month quarters (30 months) with a documented need 
of ten /24s should be able to reserve either:
 A] one /21 and one /23 
 B] one  /21 (rounded down to the nearest CIDR)
 C] one /20  (rounded up to the nearest CIDR)

This customer could then attempt to justify and draw down one /24 every 3 
months.


2. A customer with a 30 month documented need for one /24 should be able 
to reserve one /24.

This customer could then attempt to justify and draw down either:
 A] one /28 every 3 months for the first year 
    and a /27 every 3 months for the last 1.5 years
    (or some similar combination of the same number of /28s and /27s)
 
 B] one /28 every 3 months (allowing the extra six /28s for rounding up)

3. A customer with a 24 month documented need for one /24 should be able
to reserve one /24.

This customer could then attempt to justify and draw down one /27 every 3 
months (shortening their draw down to two years due to rounding down)


4. A customer with a 30 month documented need for one /24 should be able
to immediately draw down a single /24, but then get no additional 
transition space in the next 30 months. 

On Mon, 26 Jul 2010, Hannigan, Martin wrote:

|Based on that, an entity would need to qualify for a /20 over a $long
|time span. The time span noted does not perfectly match up to CIDR
|boundaries FWIW, but it will when everything is settled.

Maybe 32 months would be a more round number?  Thats is 2^5 months.  
Unfortunately that would give use 10 quarters (3 month periods) and one 
two month period at the end.  

__Jason
  


==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Mon, 26 Jul 2010, Chris Grundemann wrote:

|Date: Mon, 26 Jul 2010 14:49:07 -0600
|From: Chris Grundemann <cgrundemann at gmail.com>
|To: "Hannigan, Martin" <marty at akamai.com>
|Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
|Subject: Re: [arin-ppml] Set aside round deux
|
|On Mon, Jul 26, 2010 at 14:22, Hannigan, Martin <marty at akamai.com> wrote:
|>
|> Since it seemed to have been very helpful to vet the global policy idea on
|> the list, I thought it might be helpful to use it to frame my non-support
|> for 116.
|
|I fixed your post - pp109 is about WHOIS and resource reservation,
|pp116 is about the reservation of IPv4.
|
|> ?2. Minimum and Maximum Allocation Unit
|>
|> The minimum allocation unit will be a /20. The maximum allocation unit will
|> be /15.
|
|Why not a /24 minimum?
|
|
|~Chris
|
|
|> _______________________________________________
|> 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.
|>
|
|
|
|
|
|-- 
|@ChrisGrundemann
|weblog.chrisgrundemann.com
|www.burningwiththebush.com
|www.coisoc.org
|_______________________________________________
|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 cgrundemann at gmail.com  Mon Jul 26 22:55:36 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 26 Jul 2010 20:55:36 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <alpine.GSO.2.00.1007261703420.17216@peermon.argfrp.us.uu.net>
References: <C87366AB.A7FA%marty@akamai.com>
	<AANLkTikEPBBB14DF9P5-RWRwJ3rC1N_JP=ujUsvf6c_N@mail.gmail.com>
	<alpine.GSO.2.00.1007261703420.17216@peermon.argfrp.us.uu.net>
Message-ID: <AANLkTikT=wseVxX1uaXjR-c5yqTfmbvqQNu6oFNrBdUw@mail.gmail.com>

On Mon, Jul 26, 2010 at 20:22, Jason Schiller <schiller at uu.net> wrote:
> Chris,
>
> I'm not sure I understand your why not a /24 comment... can you clarify?
>
> Are you saying:
>
> 1. A customer with ten 3-month quarters (30 months) with a documented need
> of ten /24s should be able to reserve either:
> ?A] one /21 and one /23
> ?B] one ?/21 (rounded down to the nearest CIDR)
> ?C] one /20 ?(rounded up to the nearest CIDR)
>
> This customer could then attempt to justify and draw down one /24 every 3
> months.

I think that 1C is definitely valid, and probably where the original
/20 minimum came from.

> 4. A customer with a 30 month documented need for one /24 should be able
> to immediately draw down a single /24, but then get no additional
> transition space in the next 30 months.

Scenario 4 is what I was thinking of when I made the comment. I think
that this would open the door for smaller operators to get needed
addresses (without potentially being held over the coals by an
upstream) without opening any dangerous loopholes or introducing any
bias towards any particular type of Org.

> On Mon, 26 Jul 2010, Hannigan, Martin wrote:
>
> |Based on that, an entity would need to qualify for a /20 over a $long
> |time span. The time span noted does not perfectly match up to CIDR
> |boundaries FWIW, but it will when everything is settled.
>
> Maybe 32 months would be a more round number? ?Thats is 2^5 months.
> Unfortunately that would give use 10 quarters (3 month periods) and one
> two month period at the end.

If the addresses are to be handed out quarterly, then I think either a
24 or 48 month reservation period is better. A choice between the two
might be ideal but may also be more complicated than needed.

48 months obviously works with the /24 each quarter to a /20 minimum
reservation over the 48 month period. You could drop the minimum to
/21 and make it a 24 month period (maybe drop the maximum in this case
as well) in that scenario too...

32 months would favor a bimonthly dole.

Either way, I still think that we need a relief valve for small
operators who get stuck in a place where they can not reasonably go to
their upstream for any number of potential reasons and can not justify
a /20 (even over the given period).

~Chris

>
> __Jason
>
>
>
> ==========================================================================
> Jason Schiller ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (703)886.6648
> Senior Internet Network Engineer ? ? ? ? ? ? ? ? ? ? ? ? fax:(703)886.0512
> Public IP Global Network Engineering ? ? ? ? ? ? ? ? ? ? ? schiller at uu.net
> UUNET / Verizon ? ? ? ? ? ? ? ? ? ? ? ? jason.schiller at verizonbusiness.com
>
> The good news about having an email address that is twice as long is that
> it increases traffic on the Internet.
> |_______________________________________________
> |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.
> |
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From schiller at uu.net  Mon Jul 26 23:25:49 2010
From: schiller at uu.net (Jason Schiller)
Date: Mon, 26 Jul 2010 23:25:49 -0400 (EDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C87376B6.A832%marty@akamai.com>
References: <C87376B6.A832%marty@akamai.com>
Message-ID: <alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>

Owen, Martin,

It sounds to me like you are both missing each other.

>From Owen's perspective the only acceptable transition solution is a CGN 
approach with 8,000 (or more) customers share a single IP address.  With 
this limited definition, only the very largest transit providers would be 
able to justify a /20 over 30 months.

>From my perspective, it would certainly be best if all exiting IPv4-only 
networks (at least for their Internet facing content) went dual-stack 
prior to any transit provider running outof IPv4 addresses for their new 
customers.  

This policy seeks to cover the ground in between these two extreems.  

For many CGNs are too costly.  And I am not just referring to the cost of 
purchasing and installing CGN boxes.  I am mostly refering to the problems 
it creates such as breaking geolocation, breaking content acceleration, 
breaking advertising decision systems, is difficult to support, 
scales poorly, requires logging of all session level transactions for 
CALEA, performs sub-optmially as traffic must be forwarded through the 
translation node, and creates large anounts of collateral damage when one 
IP address is taken off line, or placed in the penelty box.

The next best solution is to move this problem to the end-site edge where 
many of these issues are minamized.  In this case a single IPv4 /32 is 
required for NAT64.  Likewise, and IPv6-only network could use a single 
IPv4 /32 for NAT44 allowing them reachability the IPv4 Internet through 
NAT and the IPv6 Internet natively.

Do people think such a transition mechanism is acceptable? And if so 
should ARIN support it by making IPv4 addresses available for it?

Additionally current dual-stacked Internet facing services may have need 
for continued growth.  In some cases it may not be possible to simply cap 
the IPv4 growth and growth only in IPv6.  To continue to make this service 
viable, it may require equalivent growth in both address families.

It is important to note in neither case is this business as usual.  For 
business customers they can no longer get the IPv4 addresses they can 
justify, instead they get only enough to build a NAT infrastructure.  This 
represents a significant reduction in address usage.  

For consumer customers that are typically behind NAT, their address usage 
doesn't change.  One could argue that this policy would not curb their 
consumption.  One could also argue that they are already being as efficent 
as possible while avoiding the pain of CGNs.  

In all cases it is not business as usual in that they have to make a real 
comitment to deploy IPv6 in parity with the IPv4 addresses that they 
receive.


__Jason
  



==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Mon, 26 Jul 2010, Hannigan, Martin wrote:

|Date: Mon, 26 Jul 2010 17:30:30 -0400
|From: "Hannigan, Martin" <marty at akamai.com>
|To: Owen DeLong <owen at delong.com>
|Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
|Subject: Re: [arin-ppml] Set aside round deux
|
|
|
|
|On 7/26/10 5:00 PM, "Owen DeLong" <owen at delong.com> wrote:
|
|> I did read it... A little math...
|
|
|> 
|> Let's assume you're trying to use this for NAT64 boxes... At an estimated
|> 5,000 customers per NAT64
|> box (most people I've talked to are talking between 8,000 and 80,000 per box),
|> to qualify for a /20
|> using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of
|> 20,480,000
|> which works out to 16,384,000 customers in order to justify a minimum
|> allocation under this policy.
|> 
|> If you think that small providers have 16,000,000+ customers, we have
|> radically different ideas
|> of what constitutes small.
|> 
|
|
|That would be some very fuzzy math from my perspective. If the same network
|that only needs a /32 for a NAT device also needs a /20 to use for purposes
|defined on the acceptable use list then I think that they're in good shape.
|If a network is so small and not expecting to grow at all in $time, I'm not
|so sure why it wouldn't make sense for them to scrounge up an address or ask
|their upstream for "one" (both of which are much more likely to be routable
|at least in the early stages of transition).
|
|Alas, I'm not really in a position to argue the min/max until I receive some
|constructive feedback, which was the main purpose of the post.
|
|
|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 owen at delong.com  Tue Jul 27 14:35:16 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Jul 2010 11:35:16 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
Message-ID: <4A7F128E-4669-4110-8413-7BC43ECDC090@delong.com>


On Jul 26, 2010, at 8:25 PM, Jason Schiller wrote:

> Owen, Martin,
> 
> It sounds to me like you are both missing each other.
> 
>> From Owen's perspective the only acceptable transition solution is a CGN 
> approach with 8,000 (or more) customers share a single IP address.  With 
> this limited definition, only the very largest transit providers would be 
> able to justify a /20 over 30 months.
> 
Not at all... I think that there are many acceptable solutions. However, for
space we set aside specifically for transitional technology only, it seems
to me that the point is to keep it available for transitional usage that has
higher than normal value (more users served per address). Otherwise,
what is the point of setting it aside or marking it separate?

>> From my perspective, it would certainly be best if all exiting IPv4-only 
> networks (at least for their Internet facing content) went dual-stack 
> prior to any transit provider running outof IPv4 addresses for their new 
> customers.  
> 
Of course. On that, we are in complete agreement and I'm doing everything
I can think of to encourage and support that. If you have ideas on other
things I can do, I'm open to them.

> This policy seeks to cover the ground in between these two extreems.  
> 
That may be what it seeks, but, the reality is that I think this suggestion preserves
business as usual for the largest consumers of address space for a very
short time (since it will get used up just about as fast as any other /8 as
it applies virtually no limits on the utilization) while raising the barrier for
smaller organizations.

> For many CGNs are too costly.  And I am not just referring to the cost of 
> purchasing and installing CGN boxes.  I am mostly refering to the problems 
> it creates such as breaking geolocation, breaking content acceleration, 
> breaking advertising decision systems, is difficult to support, 
> scales poorly, requires logging of all session level transactions for 
> CALEA, performs sub-optmially as traffic must be forwarded through the 
> translation node, and creates large anounts of collateral damage when one 
> IP address is taken off line, or placed in the penelty box.
> 
I completely agree. I think CGN/LSN is an absolutely abysmal state of
affairs for all concerned.  I'd hate to see it become widespread, although
if it does, I can think of few better motivators for transition towards IPv6.

> The next best solution is to move this problem to the end-site edge where 
> many of these issues are minamized.  In this case a single IPv4 /32 is 
> required for NAT64.  Likewise, and IPv6-only network could use a single 
> IPv4 /32 for NAT44 allowing them reachability the IPv4 Internet through 
> NAT and the IPv6 Internet natively.
> 
Correct. This is the part of this suggestion that I agree with and would be
allowed under proposal 116 as well. That's not the part I am objecting
to.

> Do people think such a transition mechanism is acceptable? And if so 
> should ARIN support it by making IPv4 addresses available for it?
> 
The bigger question is at what rate and on what basis ARIN should make
those addresses available. If we hand out a /8 in chunks of /20 or larger
as this proposal suggests, organizations that are adding fewer than
200+ customers per quarter would be essentially excluded under this
suggestion as written.

> Additionally current dual-stacked Internet facing services may have need 
> for continued growth.  In some cases it may not be possible to simply cap 
> the IPv4 growth and growth only in IPv6.  To continue to make this service 
> viable, it may require equalivent growth in both address families.
> 
If we had the numbers available, that seems perfectly reasonable. However,
the reality is that if this suggestion were to become active policy, then,
by the time it kicks in, such a provision would ensure that the set-aside
space evaporated at a rate very near to all prior space, making it
essentially a no-op.

> It is important to note in neither case is this business as usual.  For 
> business customers they can no longer get the IPv4 addresses they can 
> justify, instead they get only enough to build a NAT infrastructure.  This 
> represents a significant reduction in address usage.  
> 
It is business as usual for the majority of business customers. The majority
of business customers are small-medium sized businesses that currently
enjoy a /29 or less of IPv4 space. Reducing allocations to them from /29
to /32 will not slow consumption significantly. Yes, this will be harmful
to the large enterprises that don't have staff smart enough to put SSL
terminations on lots of dual-stacked machines or do appropriate
TE gymnastics to manipulate their networks into this suggestion.
I'm not inclined to believe that this represents a significant portion
of large enterprises.

It is business as usual for public-facing servers/services as it places no
restrictions whatsoever on address consumption there.

> For consumer customers that are typically behind NAT, their address usage 
> doesn't change.  One could argue that this policy would not curb their 
> consumption.  One could also argue that they are already being as efficent 
> as possible while avoiding the pain of CGNs.  
> 
Correct. This is also true of small and many medium sized enterprise
customers. That is why this would not change under proposal 116, either.

> In all cases it is not business as usual in that they have to make a real 
> comitment to deploy IPv6 in parity with the IPv4 addresses that they 
> receive.
> 
Putting reachable IPv6 addresses on machines is not a real
commitment to deploy IPv6 in parity with IPv4. It is all that is required
under this proposal. The parity of services is not required as this
suggestion is currently written. If it were, that would make the
suggestion more palatable, but, I still believe it would not sufficiently
curb consumption to make this much more than a no-op as a
policy.

Owen



From spence at commandinformation.com  Tue Jul 27 17:20:53 2010
From: spence at commandinformation.com (Spence, John)
Date: Tue, 27 Jul 2010 17:20:53 -0400
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
 IP Reassignment Registration Requirements
In-Reply-To: <4C49FC2F.5050206@arin.net>
References: <4C49FC2F.5050206@arin.net>
Message-ID: <3D94AC8453ABFD4C9504DFBE27043B0F2693B59773@sfed07>

I support this proposal.

John Spence
Spence at commandinformation.com

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of ARIN
Sent: Friday, July 23, 2010 4:32 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
IP Reassignment Registration Requirements

The message below started a petition regarding the ARIN Advisory
Council's decision not to select "Policy Proposal 109. Standardize IP
Reassignment Registration Requirements" as a draft policy at this time.
The AC's decision was posted by ARIN staff to PPML on 20 July 2010.

If successful, this petition will change Proposal 109 into a Draft
Policy which will be published for adoption discussion on the PPML and
at the Public Policy Meeting in October. If the petition fails, the
proposal will remain on the AC's docket.

For this petition to be successful, the petition needs statements of
support from at least 10 different people from 10 different
organizations. If you wish to support this petition, post a statement of
support to PPML on this thread. Point of contact information is
required, either to the entire PPML or with a follow up post to
petition at arin.net with full POC information (name, organization, street
address, email, phone).

The duration of the petition is until through five business days after
the AC's draft meeting minutes are published. ARIN staff will post the
result of the petition to PPML.

For more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


#####


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 1:51 PM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
> IP Reassignment Registration Requirements
>
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
>
> > The AC decided not to select Proposal 109 as a draft policy at this
> time:
> >
> > 109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
> sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
> both
> > IPv4 and IPv6, the distinction of residential customers, the
> utilization
> > requirements for subsequent allocations, and customer privacy are all
> > good topics, but agreement in some will be held up by any
> disagreements
> > on the others when trying to address them as one.
>
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
>
> If you support this petition, please send the following:
>
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
>
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
>
> --
>
> Author contact information:
>
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
>
> --
>
> Policy statement (v4):
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
> text:
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> --
>
> Rationale:
>
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information - Phone number, street address and abuse
> POC now required.
> 2) Residential Customer - Added "for personal use only" to the
> definition.
> 3) Registration (4.2.3.7 & 6.5.5) - Added "but not limited to" WRT
> assignment histories.
> 4) IPv6 - Requires all /64 and larger blocks to be registered.
> 5) Resource Review - Added this section.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
>
>
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it's customers.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
> --
>
> Thank you,
> ~Chris
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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: 4213 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100727/3726a46d/attachment.bin>

From marty at akamai.com  Tue Jul 27 18:23:02 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 27 Jul 2010 18:23:02 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4A7F128E-4669-4110-8413-7BC43ECDC090@delong.com>
Message-ID: <C874D486.AC23%marty@akamai.com>




On 7/27/10 2:35 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Jul 26, 2010, at 8:25 PM, Jason Schiller wrote:
> 
> I think this suggestion preserves business as usual for the largest consumers
> of address space 


If you can think of anything else that could be added, that would be superb.
You can also feel free to contribute anything additional in terms of
solutions related to this idea that may be incorporated to make it a good
proposal, if it ever gets there.

The offer that I made to you last week to participate in building this is
still open. Let me know if you are interested.


Best Regards,

-M<



From jcurran at arin.net  Tue Jul 27 22:02:53 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 27 Jul 2010 22:02:53 -0400
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
 panel)
In-Reply-To: <AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
Message-ID: <CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>

On Jul 26, 2010, at 4:31 PM, William Herrin wrote:
> As that picture clarifies, ARIN should be able to respond in a timely
> manner. The 12 to 18 month cycle for policy changes is many things,
> but timely isn't one of them. A small  experts panel, 3 to 5 people
> that meet as needed, could amend the acceptable use list with a
> turnaround time of weeks or even days.

Bill - 

The challenge with this approach in that filling in the list of acceptable 
uses amounts to filling in the blanks on existing policy.  ARIN's Policy 
Development process is fairly specific on how policy is developed, i.e.
(per <https://www.arin.net/policy/pdp.html>):

   "3. Policy Development Principles
    All policies are developed following three principles: open, 
    transparent, and bottom-up.

The panel of experts would need to make use of processes which are 
comparably open, transparent, and bottom-up in nature while developing
its recommended list of acceptable uses for these transition allocations,
if we want the the resulting changes are set to be compatible with the 
current Policy Development Process.

Interestingly enough, we have an elected body of experts (the ARIN 
Advisory Council) which follows the existing open, transparent, and
bottom-up PDP process.  If indeed the community feels that there is
an immediate risk that requires faster action than the normal PDP 
flow, the PDP already provides for Special Policy Actions which allow
emergency policy to be made very rapidly with appropriate notification 
and review by the elected experts which make up the Advisory Council.

To be clear, I am not saying that creation of a small panel of experts
to determine acceptable transition uses is not possible nor implementable, 
only that such an panel could develop changes to number allocation policy 
in such a manner that Board might find it difficult to ratify while still 
following the ARIN's Policy Development Process.

/John

John Curran
President and CEO
ARIN





From bill at herrin.us  Tue Jul 27 23:29:00 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 27 Jul 2010 17:29:00 -1000
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
Message-ID: <AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>

On Mon, Jul 26, 2010 at 5:25 PM, Jason Schiller <schiller at uu.net> wrote:
> For many CGNs are too costly.

No price is too high if you can sell it for more. No cost is low
enough if you can't.

I can sell "security enhanced Internet service for your protection,"
that sits behind a NAT firewall.  I prepared this email using such a
service in my hotel room. Doubtless you've used a few such services
yourself. There's no fundamental reason it wouldn't be valid in other
eyeball networks, not just hotels and hot spots.

Will you be able to sell Ipv6 only service, or IPv6 service with
hacked-up DNS that lets you do v6 to v4 gatewaying? Is that what your
customers tell you they want to buy?


Let me offer a rude viewpoint to gauge reaction: the 4.10 addresses
shouldn't be available to the X-larges at all. Period. The X-larges
have vast tracts of IPv4 addresses from which they can find a few to
facilitate IPv4 function during the v6 transition. 4.10 addresses
should be for folks who didn't have a lot of v4 addresses to start
with and need just a few more to carry them through to v6 ubiiquity.

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 bill at herrin.us  Tue Jul 27 23:27:11 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 27 Jul 2010 17:27:11 -1000
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
	panel)
In-Reply-To: <CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com> 
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com> 
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
Message-ID: <AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>

On Tue, Jul 27, 2010 at 4:02 PM, John Curran <jcurran at arin.net> wrote:
> The panel of experts would need to make use of processes which are
> comparably open, transparent, and bottom-up in nature while developing
> its recommended list of acceptable uses for these transition allocations,
> if we want the the resulting changes are set to be compatible with the
> current Policy Development Process.

Hi John,

You make excellent points. Let me throw a straw man out there and see
if we can beat it up:

Experts panel to recommend acceptable uses for the reserved 4.10 space
Uses not explicitly acceptable are rejected
Recommendations by panel active only upon ratification by the BoT

3 individuals on the panel (keep it small and nimble):
1 from ARIN staff
1 AC member selected by the AC
1 from academia selected by the board (specifically not affiliated
with an IR or any ARIN members)

Use plans (including number of addresses justified by the plan)
crafted by members of the general public. Fill out and post a standard
form to PPML.
1 week discussion and debate. If the author changes the proposal based
on the feedback, the clock starts over at 1 week.
Panel discusses privately following public discussion (conference call
and email). Votes when ready but no later than 1 week following public
discussion.

Unanimous vote needed to recommend a new acceptable use.
Majority vote needed to withdraw a previously accepted use.
(we want to be very cautious with these addresses, so intentionally
make it hard to get new uses approved but relatively easy to remove
obsoleted or abused ones.)

BoT must ratify new acceptable uses. Will reject any recommended use
that fails to fit within the broad definitions selected by the
community in policy 4.10.

No single-entity tailored uses. Panel should reject and BoT should
refuse to ratify uses that are obviously tailored to fit only one
possible organization.

ARIN staff authorized to allocate addresses from 4.10 when presented
with a request containing a use plan that matches one of the ratified
acceptable uses.

Withdrawal only applies to address requests not already filled at the
time the withdrawal proposal was made to PPML. (good faith)

Vote of no confidence - petition of 10 people on the PPML compels the
AC to hold a confidence vote. If the majority of the AC votes no
confidence, the panel is disbanded and must reformed from the same
sources with different individuals. Vote confidence for the entire
panel, not specific individuals.

Panel's recommendations apply only to the /10 set aside by section
4.10. Panel disbands when the last of the /10 set aside by section
4.10 is allocated.

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 jcurran at arin.net  Tue Jul 27 23:44:01 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 27 Jul 2010 23:44:01 -0400
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
 panel)
In-Reply-To: <AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
Message-ID: <C08AC999-F9FF-488B-82E7-AD2336106127@arin.net>

On Jul 27, 2010, at 8:27 PM, William Herrin wrote:
> 
> Hi John,
> 
> You make excellent points. Let me throw a straw man out there and see
> if we can beat it up:
> 
> ...
> Thoughts?

Would you consider the straw man to follow the three principles of open, 
transparent, and bottom-up policy development?  This will be a prominent
question asked by each Board member when considering it, and will be very
closely scrutinized by parties that have their proposed use application
declined by such a panel.

/John

John Curran
President and CEO
ARIN



From cgrundemann at gmail.com  Wed Jul 28 00:00:59 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 27 Jul 2010 22:00:59 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
Message-ID: <AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>

On Tue, Jul 27, 2010 at 21:29, William Herrin <bill at herrin.us> wrote:
> Let me offer a rude viewpoint to gauge reaction: the 4.10 addresses
> shouldn't be available to the X-larges at all. Period. The X-larges
> have vast tracts of IPv4 addresses from which they can find a few to
> facilitate IPv4 function during the v6 transition. 4.10 addresses
> should be for folks who didn't have a lot of v4 addresses to start
> with and need just a few more to carry them through to v6 ubiiquity.
>
> Thoughts?

I think that any policy that intentionally favors or disfavors any
particular organization or group of organizations is not in the
interest of Internet stewardship.

If we want the Orgs with IP addresses to be fair, than mustn't we be
fair to them?

There are some (if not many) Orgs with a glut of addresses that are
not X-Large ISPs. Do they get a pass because they are not "XL?" The
problem with this kind of discrimination is that it is discrimination.
What we should focus on is efficient utilization, not organizational
size.

As a completely arbitrary example: If a "smaller" Org serves 2500 end
users with a /20 and a "larger" Org serves 50,000 customers with a /16
who should be banned from getting new addresses? The smaller Org at
around 60% actual utilization or the larger Org who is over 75%?

If you are worried about vast tracts of IPs ripe for the plucking,
then let's write policy to find and recover those tracts - Or at least
to stop Orgs with those unused/underused resources from getting more.
Size, type, industry are not the issues here; efficient utilization
is.

$.02
~Chris


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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Wed Jul 28 00:45:18 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Jul 2010 21:45:18 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C874D486.AC23%marty@akamai.com>
References: <C874D486.AC23%marty@akamai.com>
Message-ID: <561506B7-49FC-4714-B854-05D423AD8FBC@delong.com>


On Jul 27, 2010, at 3:23 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 7/27/10 2:35 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> 
>> On Jul 26, 2010, at 8:25 PM, Jason Schiller wrote:
>> 
>> I think this suggestion preserves business as usual for the largest consumers
>> of address space 
> 
> 
> If you can think of anything else that could be added, that would be superb.
> You can also feel free to contribute anything additional in terms of
> solutions related to this idea that may be incorporated to make it a good
> proposal, if it ever gets there.
> 
I thought I had already made clear what I thought needed to be removed
from the suggestion. It is a question of the permitted uses I feel should be
removed rather than anything I think should be added.

A set aside policy should limit address utilization to those uses which provide
the largest number of subscriber transitional service per address and not
given to anyone with just any public accessible server.

Additionally, the very high bar (justification of a /20 for purely transitional
purposes over 3 years) should be much, much lower and the minimum
allocation unit should probably be no larger than /24, probably smaller.

I understand the concern about aggregation, but, frankly, IPv4 is running
out of addresses and the tradeoff is efficient utilization of what is left vs.
aggregation. If we're going to have a meaningful set-aside, then, that
set-aside will have to be used in a manner that is not consistent with
maximizing aggregation if we are to avoid giving a huge unfair advantage
to very large organizations.

I suspect my opinion in this matter is directly in opposition to the opinion
of some of the other authors of the document and I accept that. I look
forward to a lively discussion in any case.

> The offer that I made to you last week to participate in building this is
> still open. Let me know if you are interested.
> 
Thank you. I am attempting to contribute where I can, perhaps that was not
clear from my earlier messages.

Owen



From owen at delong.com  Wed Jul 28 00:57:05 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Jul 2010 21:57:05 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
Message-ID: <22722409-A13F-40A3-956F-ECA8B519D7C6@delong.com>


On Jul 27, 2010, at 8:29 PM, William Herrin wrote:

> On Mon, Jul 26, 2010 at 5:25 PM, Jason Schiller <schiller at uu.net> wrote:
>> For many CGNs are too costly.
> 
> No price is too high if you can sell it for more. No cost is low
> enough if you can't.
> 
> I can sell "security enhanced Internet service for your protection,"
> that sits behind a NAT firewall.  I prepared this email using such a
> service in my hotel room. Doubtless you've used a few such services
> yourself. There's no fundamental reason it wouldn't be valid in other
> eyeball networks, not just hotels and hot spots.
> 
Indeed I have used such services. They have always caused so many
problems that after a couple of hours on the phone with technical
support, my charges for the service are refunded.

Does that count as a sale?

> Will you be able to sell Ipv6 only service, or IPv6 service with
> hacked-up DNS that lets you do v6 to v4 gatewaying? Is that what your
> customers tell you they want to buy?
> 
Customers for the most part do not care how you provide it, they merely
want access to the "full internet" where the definition of "full internet" means
whatever combination of content and services said user considers
meaningful.

That can be done with hacked-up DNS doing v6 to v4 gatewaying on
pure IPv6 service, B4/AFTR (DS-LITE), or several other less optimal solutions
during the transition.

Bottom line, we'll run out of IPv4 addresses. Depending how many
things we allow the set-aside pool to be fed into, we'll run out of that
sooner or later, too. 
> 
> Let me offer a rude viewpoint to gauge reaction: the 4.10 addresses
> shouldn't be available to the X-larges at all. Period. The X-larges
> have vast tracts of IPv4 addresses from which they can find a few to
> facilitate IPv4 function during the v6 transition. 4.10 addresses
> should be for folks who didn't have a lot of v4 addresses to start
> with and need just a few more to carry them through to v6 ubiiquity.
> 

> Thoughts?
> 
While I understand the sentiment, and am personally sypmathetic
to it, I cannot agree from a policy perspective. I no more think it is
right to prohibit the x-larges from getting space if they need it for
transitional technologies than to prohibit the small and x-small
organizations from getting it.

> 

Owen




From owen at delong.com  Wed Jul 28 01:03:46 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Jul 2010 22:03:46 -0700
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
	panel)
In-Reply-To: <AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
Message-ID: <06206E3F-9EBA-48C2-AD26-1E81FBEF704F@delong.com>


On Jul 27, 2010, at 8:27 PM, William Herrin wrote:

> On Tue, Jul 27, 2010 at 4:02 PM, John Curran <jcurran at arin.net> wrote:
>> The panel of experts would need to make use of processes which are
>> comparably open, transparent, and bottom-up in nature while developing
>> its recommended list of acceptable uses for these transition allocations,
>> if we want the the resulting changes are set to be compatible with the
>> current Policy Development Process.
> 
> Hi John,
> 
> You make excellent points. Let me throw a straw man out there and see
> if we can beat it up:
> 
> Experts panel to recommend acceptable uses for the reserved 4.10 space
> Uses not explicitly acceptable are rejected
> Recommendations by panel active only upon ratification by the BoT
> 
> 3 individuals on the panel (keep it small and nimble):
> 1 from ARIN staff
> 1 AC member selected by the AC
> 1 from academia selected by the board (specifically not affiliated
> with an IR or any ARIN members)
> 
Panel member 3 will be distinctly difficult to find. It is hard to find someone
in academia not affiliated with an ARIN member as most academic
institutions are ARIN members.

Also, I question a panel which specifically includes a representative
from academia while eschewing the idea of any representatives from
industry.

> Use plans (including number of addresses justified by the plan)
> crafted by members of the general public. Fill out and post a standard
> form to PPML.
> 1 week discussion and debate. If the author changes the proposal based
> on the feedback, the clock starts over at 1 week.
> Panel discusses privately following public discussion (conference call
> and email). Votes when ready but no later than 1 week following public
> discussion.
> 
I think getting the panel to meet more often than monthly is asking a
lot of these volunteers.

> Unanimous vote needed to recommend a new acceptable use.
> Majority vote needed to withdraw a previously accepted use.
> (we want to be very cautious with these addresses, so intentionally
> make it hard to get new uses approved but relatively easy to remove
> obsoleted or abused ones.)
> 
> BoT must ratify new acceptable uses. Will reject any recommended use
> that fails to fit within the broad definitions selected by the
> community in policy 4.10.
> 
One would hope that the panel would reject these prior to them reaching
the board, but, I agree the board should be a safety valve here.

> No single-entity tailored uses. Panel should reject and BoT should
> refuse to ratify uses that are obviously tailored to fit only one
> possible organization.
> 
> ARIN staff authorized to allocate addresses from 4.10 when presented
> with a request containing a use plan that matches one of the ratified
> acceptable uses.
> 
Should the request have to identify the acceptable use in their submitted
plan?

> Withdrawal only applies to address requests not already filled at the
> time the withdrawal proposal was made to PPML. (good faith)
> 
I would argue that withdrawl should apply to requests not yet acknowledged
by the ARIN ticketing system at the time the withdrawl proposal is ratified
by the panel. Otherwise you have unfair issues of ex post facto.

> Vote of no confidence - petition of 10 people on the PPML compels the
> AC to hold a confidence vote. If the majority of the AC votes no
> confidence, the panel is disbanded and must reformed from the same
> sources with different individuals. Vote confidence for the entire
> panel, not specific individuals.
> 
This seems particularly vulnerable to a DOS attack.

> Panel's recommendations apply only to the /10 set aside by section
> 4.10. Panel disbands when the last of the /10 set aside by section
> 4.10 is allocated.
> 
> Thoughts?
> 
In line.

Owen



From owen at delong.com  Wed Jul 28 01:07:26 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 27 Jul 2010 22:07:26 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
Message-ID: <A971B8D2-28E8-4C9A-A6E2-03D7358ABE68@delong.com>

> 
> If you are worried about vast tracts of IPs ripe for the plucking,
> then let's write policy to find and recover those tracts - Or at least
> to stop Orgs with those unused/underused resources from getting more.
> Size, type, industry are not the issues here; efficient utilization
> is.
> 
I believe that section 12 of the NRPM provides about as much policy
as is possible in this area for the actions of recovery and prohibition
from getting additional space. If you have ideas to improve upon this
I am open to them.

There is an additional draft policy which will be discussed in Atlanta
which provides the potential for policy to compel ARIN staff to make
more active use of section 12 under certain circumstances.

I would encourage everyone following this thread to review that
proposal and comment on any circumstances you feel should be
added to or removed from that list.

Owen



From mysidia at gmail.com  Wed Jul 28 01:21:33 2010
From: mysidia at gmail.com (James Hess)
Date: Wed, 28 Jul 2010 00:21:33 -0500
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
	panel)
In-Reply-To: <AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
Message-ID: <AANLkTi=Qp=3vDQaeisUEo2PzVdbfrrd4qU7Djwtd8+FC@mail.gmail.com>

On Tue, Jul 27, 2010 at 10:27 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Jul 27, 2010 at 4:02 PM, John Curran <jcurran at arin.net> wrote:
> Recommendations by panel active only upon ratification by the BoT
> 3 individuals on the panel (keep it small and nimble):
> 1 from ARIN staff
> 1 AC member selected by the AC
> 1 from academia selected by the board (specifically not affiliated
> with an IR or any ARIN members)

Is this really a suitable way of making a panel of experts?   What
criteria would they be required to use in determining if something is
an eligible transition technology, and  how do we determine how much
space  is warranted to be needed to use the technology, AND  what
organization(s) can apply.....
as in,  the requirements/justifications  required to use a transition
technology  ?

> Use plans (including number of addresses justified by the plan)
> crafted by members of the general public. Fill out and post a standard
> form to PPML. 1 week discussion and debate. If the author changes the proposal based
> on the feedback, the clock starts over at 1 week.
> Panel discusses privately following public discussion (conference call
> and email). Votes when ready but no later than 1 week following public

So  why not just let the   BoT  discuss any PPML discussion for
proposed uses,   appoint  some member of the AC or ARIN staff    to
propose when an old acceptable use should be removed,   and  to decide
 if a proposal has enough public input to be considered?

I would say,  public involvement removes the need for the 'panel'  to
be  a 'panel of experts',  since there are experts from the public who
would comment on the discussion.

Use the normal petition process,  to allow any decision 'not to
include' a proposal in what the BoT will consider, to be overridden by
the public.

Why allow private discussion,   what is the reason for allowing any
information at all
about how the 'list'  or other policy  was developed,  to be hidden
from the public?

--
-JH


From bill at herrin.us  Wed Jul 28 01:57:58 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 27 Jul 2010 19:57:58 -1000
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net> 
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com> 
	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
Message-ID: <AANLkTi=4KEz+6UJ1k+P7Ri-cJvk11CW9yAvjiwX4byBr@mail.gmail.com>

On Tue, Jul 27, 2010 at 6:00 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> I think that any policy that intentionally favors or disfavors any
> particular organization or group of organizations is not in the
> interest of Internet stewardship.

We can't have that, Chris. Just imagine... what if there was a region,
say the Caribbean, which had to meet different standards than everyone
else? What if we arbitrarily divided ISPs and non-ISPs and gave them
different rules, even gave some of them the right to vote and some
not? What if, and this one's a doozy, what if the fee for an address
was orders of magnitude different depending on how many addresses you
held?

No, we can't have favoritism in the process, that would be wrong. So
let me adjust my unreasonable notion:

Perhaps any registrant requesting 4.10 addresses should first show
cause why aggressive compression of their existing allocation (via
NAT, v6-only deployments, etc.) can not be made to supply the needed
addresses.

Thoughts?


On Tue, Jul 27, 2010 at 6:57 PM, Owen DeLong <owen at delong.com> wrote:
> On Jul 27, 2010, at 8:29 PM, William Herrin wrote:
>> I can sell "security enhanced Internet service for your protection,"
>> that sits behind a NAT firewall.  I prepared this email using such a
>> service in my hotel room. Doubtless you've used a few such services
>> yourself. There's no fundamental reason it wouldn't be valid in other
>> eyeball networks, not just hotels and hot spots.
>>
> Indeed I have used such services. They have always caused so many
> problems that after a couple of hours on the phone with technical
> support, my charges for the service are refunded.
>
> Does that count as a sale?

You're special, Owen, one of a single-digit percentage of all the
Internet consumers out there who just can seem to function with NAT.
Special is good, but if we can get the other 90%+ of the eyeballs, the
ones who aren't so special, to share IPv4 addresses via large scale
NAT and v6 to v4 translation processes, there will be plenty of IPv4
addresses left over for special people for quite some time to come.

-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  Wed Jul 28 02:39:17 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 27 Jul 2010 20:39:17 -1000
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
	panel)
In-Reply-To: <C08AC999-F9FF-488B-82E7-AD2336106127@arin.net>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com> 
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com> 
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com> 
	<C08AC999-F9FF-488B-82E7-AD2336106127@arin.net>
Message-ID: <AANLkTinSfPdTHX_+ROoTPhHkxjCg62kKjpfh=652w5ZO@mail.gmail.com>

On Tue, Jul 27, 2010 at 5:44 PM, John Curran <jcurran at arin.net> wrote:
> Would you consider the straw man to follow the three principles of open,
> transparent, and bottom-up policy development?

Hi John,

That was my target. If I missed, point and shout.



On Tue, Jul 27, 2010 at 7:03 PM, Owen DeLong <owen at delong.com> wrote:
> On Jul 27, 2010, at 8:27 PM, William Herrin wrote:
>> 3 individuals on the panel (keep it small and nimble):
>> 1 from academia selected by the board (specifically not affiliated
>> with an IR or any ARIN members)
>
> Panel member 3 will be distinctly difficult to find. It is hard to find someone
> in academia not affiliated with an ARIN member as most academic
> institutions are ARIN members.

That's why I picked him. He's a counterbalance -- everything ARIN's
business as usual is not.

> Also, I question a panel which specifically includes a representative
> from academia while eschewing the idea of any representatives from
> industry.

When I first wrote this I had five members, including one from
industry (defined as an ARIN member) and one at-large. But I think 5
is too many people. Large groups find it difficult to quickly make
hard choices. So I whittled it down to 3 and industry was at least
partially represented by the selection of an AC member, whose presence
I considered more important.

> Should the request have to identify the acceptable use in their submitted
> plan?

Makes sense to me.

> I would argue that withdrawl should apply to requests not yet acknowledged
> by the ARIN ticketing system at the time the withdrawl proposal is ratified
> by the panel. Otherwise you have unfair issues of ex post facto.

I can see advantages and disadvantages either way. If the withdrawal
backdates to when the withdrawal proposal is posted to PPML then
there's a chance to stop abuse in progress.


>> Vote of no confidence - petition of 10 people on the PPML compels the
>> AC to hold a confidence vote. If the majority of the AC votes no
> This seems particularly vulnerable to a DOS attack.

Because the AC might be repeatedly required to vote that they still
have confidence in the panel?


On Tue, Jul 27, 2010 at 7:21 PM, James Hess <mysidia at gmail.com> wrote:
> What criteria would they be required to use in determining if something
> is an eligible transition technology, and  how do we determine how much
> space  is warranted to be needed to use the technology, AND  what
> organization(s) can apply..... as in,  the requirements/justifications
> required to use a transition technology  ?

Hi James,

That's the point of picking a panel of experts: they're experts. Given
broad goals and guidelines (mostly already in 4.10) they're capable of
making these decisions based on their expertise.


> So  why not just let the   BoT  discuss any PPML discussion for
> proposed uses,   appoint  some member of the AC or ARIN staff    to
> propose when an old acceptable use should be removed,   and  to decide
>  if a proposal has enough public input to be considered?

Because the BoT and AC already have enough on their plates and given
the likely controversial nature of the panel's proposed work, it would
be healthy if the blame didn't spill over too much.


> I would say,  public involvement removes the need for the 'panel'  to
> be  a 'panel of experts',  since there are experts from the public who
> would comment on the discussion.

The process of building public consensus is necessarily slow. When
there aren't any more IPv4 addresses except what's in this pool, slow
to react is likely to be damaging to the very activities 4.10 is
intended to assist.


> Why allow private discussion,   what is the reason for allowing any
> information at all
> about how the 'list'  or other policy  was developed,  to be hidden
> from the public?

In a public discussion, you speak to the public as much as you speak
to the person you're replying to. I'm doing it now. In a
consensus-building process, that's a good thing. If you're trying to
quickly get to the bottom of a matter and make a decision, it's not so
good. You need to be able to open your mouth and not be held
accountable for every indelicate turn of phrase.

As I suggested for the AC, though, I do think it would be valuable for
anyone voting "no" to write a couple paragraphs explaining to the
public why.

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  Wed Jul 28 04:32:28 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 28 Jul 2010 09:32:28 +0100
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213B6@EMV01-UKBR.domain1.systemhost.net>

> Let me offer a rude viewpoint to gauge reaction: the 4.10 addresses
> shouldn't be available to the X-larges at all. Period. The X-larges
> have vast tracts of IPv4 addresses from which they can find a few to
> facilitate IPv4 function during the v6 transition. 4.10 addresses
> should be for folks who didn't have a lot of v4 addresses to start
> with and need just a few more to carry them through to v6 ubiiquity.

What's rude about it? This is reality. All large ISPs have enough
existing IPv4 space to keep their businesses humming even if they
can't get more from ARIN.

That doesn't mean that they currently have spare addresses stashed
away, although I would expect that most do have sloppy decommissioning
processes with the end result that they have addresses lost in the
system. But the main source of IP addresses for these large ISPs is
their existing customers. They will have high margin customers and
low margin customers. It is not unusual for a large company to identify
its low margin customers, and then contact them all to say that 
their service contracts will not be renewed and if the customer
wants to cancel the contracts at any time, no penalty will be 
charged. 

Therefore, the large ISPs are able to mine their low margin customer
base to recover IP addresses which can be used for continued growth
of high margin customers. In some cases this kind of process will have
other benefits. For instance, consider an ISP who installed lots of
75xx edge routers to sell T1 access. Over the years, the high margin
customers have all upgraded. By shedding certain low margin customers
they not only recover IP addresses, but they can get rid of those
75xx boxes freeing up rack space for 10Ks with a higher port density
and greater flexibility. 

I believe that address recovery through internal churn is viable for 
all of the larger ISPs therefore I think that a policy which intends
to limit the disruptive effect of IPv4 exhaustion would do better to
focus exclusively on the smaller businesses who often have less 
flexible business models. I'm not saying that ARIN has a responsibility
to protect these businesses from bankruptcy or buyout, but that a
policy focused on lengthening the period of time during which these
businesses can get IPv4 addresses, will generally ease the process
of IPv6 transition. For one thing, it will make it more likely that
these smaller businesses can buy IPv6 routers on the used market.
And it will allow them to spread their investment in transition
over a longer period which makes it more financially feasible.

The basic principle of set-aside policies is that ARIN will impose
pain on certain organizations in order to protect others. The goal
is to make the IPv6 transition a bit smoother. Which orgs can handle
the pain? The big ones. Which orgs would get most of the pain anyway
if ARIN does nothing. The big ones. The Robin Hood strategy works
for me.

--Michael Dillon



From michael.dillon at bt.com  Wed Jul 28 04:39:11 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 28 Jul 2010 09:39:11 +0100
Subject: [arin-ppml] Possible amendment to proposal 116 (small
	experts	panel)
In-Reply-To: <AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213C1@EMV01-UKBR.domain1.systemhost.net>

> 3 individuals on the panel (keep it small and nimble):
> 1 from ARIN staff
> 1 AC member selected by the AC
> 1 from academia selected by the board (specifically not affiliated
> with an IR or any ARIN members)

No ARIN staff. No AC members.
ARIN already has the expert opinions of all of its staff, as well
as the expert opinions of all of its AC members. No need to elevate
one of these above the others.

If there is to be some kind of panel giving opinions into the process,
then we need to maximize external inputs.
1 academic with PhD and teaching position at a university
1 network manager from non profit sector
1 network manager from large enterprise
1 person connected with SBA or SCORE
1 technology journalist

No former ARIN staff or AC or BoT

> Vote of no confidence - petition of 10 people on the PPML compels the
> AC to hold a confidence vote. If the majority of the AC votes no
> confidence, the panel is disbanded and must reformed from the same
> sources with different individuals. Vote confidence for the entire
> panel, not specific individuals.

In general, the idea of getting a panel to come up with a solution,
followed by a vote seems to be a workable and interesting idea as
long as it has a time limit which fits between two ARIN meetings.

--Michael Dillon



From michael.dillon at bt.com  Wed Jul 28 04:43:08 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 28 Jul 2010 09:43:08 +0100
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213CD@EMV01-UKBR.domain1.systemhost.net>

> If you are worried about vast tracts of IPs ripe for the plucking,
> then let's write policy to find and recover those tracts - Or at least
> to stop Orgs with those unused/underused resources from getting more.
> Size, type, industry are not the issues here; efficient utilization
> is.

Find and recover is a non-starter because it costs too much money
for ARIN to do this kind of detailed audit.

Efficient utilization is unknown without audits. 

Therefore, make the set-aside policy only available for orgs whose
address allocations are less than a certain threshold.

--Michael Dillon

P.S. Fairness is irrelevant. Any set aside policy is unfair. Doing nothing is unfair.
Life is unfair. We aren't here to change the world, just to reduce the chaos and
disorder of the IPv6 transition.

Period.



From owen at delong.com  Wed Jul 28 05:15:12 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 Jul 2010 02:15:12 -0700
Subject: [arin-ppml] Possible amendment to proposal 116 (small experts
	panel)
In-Reply-To: <AANLkTinSfPdTHX_+ROoTPhHkxjCg62kKjpfh=652w5ZO@mail.gmail.com>
References: <B0DBF5A3-DA57-4EA8-92C0-17257F9E8518@delong.com>
	<C87360CD.A7E2%marty@akamai.com>
	<AANLkTimZFJ1mjq=zMeuT0nZyyuLNGR3+u4HcR8yCs7bn@mail.gmail.com>
	<CFE1B088-BA17-4C9C-A01A-A4926A7C36F3@arin.net>
	<AANLkTikVZL0MuDrLsAJRT4Xwrt9nYwFWFNgA+9AFjaKW@mail.gmail.com>
	<C08AC999-F9FF-488B-82E7-AD2336106127@arin.net>
	<AANLkTinSfPdTHX_+ROoTPhHkxjCg62kKjpfh=652w5ZO@mail.gmail.com>
Message-ID: <E1AA1781-29D8-4677-9474-49B30937E6A1@delong.com>


On Jul 27, 2010, at 11:39 PM, William Herrin wrote:

> On Tue, Jul 27, 2010 at 5:44 PM, John Curran <jcurran at arin.net> wrote:
>> Would you consider the straw man to follow the three principles of open,
>> transparent, and bottom-up policy development?
> 
> Hi John,
> 
> That was my target. If I missed, point and shout.
> 
> 
> 
> On Tue, Jul 27, 2010 at 7:03 PM, Owen DeLong <owen at delong.com> wrote:
>> On Jul 27, 2010, at 8:27 PM, William Herrin wrote:
>>> 3 individuals on the panel (keep it small and nimble):
>>> 1 from academia selected by the board (specifically not affiliated
>>> with an IR or any ARIN members)
>> 
>> Panel member 3 will be distinctly difficult to find. It is hard to find someone
>> in academia not affiliated with an ARIN member as most academic
>> institutions are ARIN members.
> 
> That's why I picked him. He's a counterbalance -- everything ARIN's
> business as usual is not.
> 
That may well be a good theory, but, my point is that if you can't find a
qualified person to fill the slot, you have a rather dysfunctional panel.

>> Also, I question a panel which specifically includes a representative
>> from academia while eschewing the idea of any representatives from
>> industry.
> 
> When I first wrote this I had five members, including one from
> industry (defined as an ARIN member) and one at-large. But I think 5
> is too many people. Large groups find it difficult to quickly make
> hard choices. So I whittled it down to 3 and industry was at least
> partially represented by the selection of an AC member, whose presence
> I considered more important.
> 
An interesting statement given that at least three AC members are
from academia, not industry. Some quick math says that's at least
20% of the AC.

>> Should the request have to identify the acceptable use in their submitted
>> plan?
> 
> Makes sense to me.
> 
>> I would argue that withdrawl should apply to requests not yet acknowledged
>> by the ARIN ticketing system at the time the withdrawl proposal is ratified
>> by the panel. Otherwise you have unfair issues of ex post facto.
> 
> I can see advantages and disadvantages either way. If the withdrawal
> backdates to when the withdrawal proposal is posted to PPML then
> there's a chance to stop abuse in progress.
> 
Yes, but, if the "abuse" is legitimately within the policy prior to the change,
then, it is not abuse by the good faith definition of the community and the
change is literally the type of change intended to be prohibited by the
ex post facto provisions of the constitution. While I realize that the US
constitution is not particularly related to ARIN policy, perhaps due to my
American upbringing, I do feel that making ex post facto changes to
policies and applying them retroactively is unfair and just plain wrong.

> 
>>> Vote of no confidence - petition of 10 people on the PPML compels the
>>> AC to hold a confidence vote. If the majority of the AC votes no
>> This seems particularly vulnerable to a DOS attack.
> 
> Because the AC might be repeatedly required to vote that they still
> have confidence in the panel?
> 
Because the AC could, at least in theory repeatedly vote no confidence.
Because it's a very low threshold of disgruntled community members to
bring about a no-confidence vote for a panel which as you point out
is likely to make itself unpopular if it is living up to its duties.


Owen



From cgrundemann at gmail.com  Wed Jul 28 08:32:22 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 28 Jul 2010 06:32:22 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTi=4KEz+6UJ1k+P7Ri-cJvk11CW9yAvjiwX4byBr@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
	<AANLkTi=4KEz+6UJ1k+P7Ri-cJvk11CW9yAvjiwX4byBr@mail.gmail.com>
Message-ID: <AANLkTimMrUywnd+dvW4a9+T3J76TdK+Vh=QQ78FStQF0@mail.gmail.com>

On Tue, Jul 27, 2010 at 23:57, William Herrin <bill at herrin.us> wrote:
> On Tue, Jul 27, 2010 at 6:00 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>> I think that any policy that intentionally favors or disfavors any
>> particular organization or group of organizations is not in the
>> interest of Internet stewardship.
>
> We can't have that, Chris. Just imagine... what if there was a region,
> say the Caribbean, which had to meet different standards than everyone
> else? What if we arbitrarily divided ISPs and non-ISPs and gave them
> different rules, even gave some of them the right to vote and some
> not? What if, and this one's a doozy, what if the fee for an address
> was orders of magnitude different depending on how many addresses you
> held?

Point well made. However, I believe that in the first case, folks from
the Caribbean requested the different standards. If a consortium of
X-Larges (or any other group) brings a proposal to the table to
exclude themselves from a certain block of addresses, then perhaps we
should consider it.

It is very true that ISP vs. non-ISP policy is very different, and
probably needs to be. So let me take the liberty of hindsight and
rephrase: Policy that *intentionally* favors or disfavors any
particular organization or group of organizations without sound
technical justification is not in the interest of Internet
stewardship.

Fees are not a policy matter (and nothing that I can change att) so I
will conveniently skip over that discrepancy. ;)

Finally, the argument that bad decisions should be allowed because
someone else already made bad decisions is not one that I am easily
persuaded by. If there is favoritism in the system, let's work to
address it specifically, rather than introduce new favoratisms
elsewhere.

> No, we can't have favoritism in the process, that would be wrong. So
> let me adjust my unreasonable notion:
>
> Perhaps any registrant requesting 4.10 addresses should first show
> cause why aggressive compression of their existing allocation (via
> NAT, v6-only deployments, etc.) can not be made to supply the needed
> addresses.
>
> Thoughts?

I think that this is a much more reasonable proposal.

~Chris

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




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From cgrundemann at gmail.com  Wed Jul 28 09:24:23 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 28 Jul 2010 07:24:23 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213CD@EMV01-UKBR.domain1.systemhost.net>
References: <C87376B6.A832%marty@akamai.com>
	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>
	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239180213CD@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <AANLkTi=kNwJ4jtgzXKJ_wH-UREYgwE0ypOa9drAn6_VG@mail.gmail.com>

On Wed, Jul 28, 2010 at 02:43,  <michael.dillon at bt.com> wrote:
>> If you are worried about vast tracts of IPs ripe for the plucking,
>> then let's write policy to find and recover those tracts - Or at least
>> to stop Orgs with those unused/underused resources from getting more.
>> Size, type, industry are not the issues here; efficient utilization
>> is.
>
> Find and recover is a non-starter because it costs too much money
> for ARIN to do this kind of detailed audit.
>
> Efficient utilization is unknown without audits.

There are usually at least two ways to overcome an obstacle; you can
take it on and overcome it directly, or you can find a way to bypass
it. Over it or Around it.

Over it: We can write policy that lowers the level of effort for such
audits. Cleaning up WHOIS data is the best first step I believe (hence
my work to get 2008-7 adopted and my current work with pp109). Think
of this as building stairs to go over the "audit wall."

Around it: We can write policy that encourages Orgs to do their own
auditing and to find and recover their own space. Requiring more
efficient utilization of space and better proof of that utilization
when an Org comes to the troff are key plays here. Any suggestions on
how to make the ideas that Marty started this thread with better at
this are probably more on topic than either of our recent posts =).

>
> Therefore, make the set-aside policy only available for orgs whose
> address allocations are less than a certain threshold.

When we point fingers at X-Larges (or away from them) I think we often
miss an important point. Internet stewardship is not about protecting
any class of ISP, it is about protecting the Internet. The Internet
basically needs two things to remain effective; eyeballs and content.
What is really important is that the two can reach each other.

If a larger ISP provides Internet access to 1,000 pairs of eyeballs
and 10 smaller Orgs provide access to 100 pairs of eyeballs each, who
serves more eyeballs? Now what if the larger ISP serves those 1,000
customers using a single /22 and each of those smaller ISPs use a /24
to serve their 100 customers. Where should we look to limit access to
the transition pool? Who is more deserving of additional addresses and
who less?

My point is not that all X-Larges are extremely efficient with their
address usage (they are probably not), my point is that if we focus on
excluding one group (any group) we are missing the point; which is
getting those addresses into use, connecting as much content to as
many eyeballs as we can with the resources available to us.

>
> --Michael Dillon
>
> P.S. Fairness is irrelevant. Any set aside policy is unfair. Doing nothing is unfair.
> Life is unfair. We aren't here to change the world, just to reduce the chaos and
> disorder of the IPv6 transition.

Fairness aside, how can we make the potential proposal being discussed
here reduce that chaos and disorder more?

~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From jmaimon at chl.com  Wed Jul 28 11:20:16 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 28 Jul 2010 11:20:16 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213CD@EMV01-UKBR.domain1.systemhost.net>
References: <C87376B6.A832%marty@akamai.com>	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>	<AANLkTinEhvEK=qovHCRrHhrULrgyK55VY9ZuDRDL3-eY@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239180213CD@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4C504AB0.5040804@chl.com>



michael.dillon at bt.com wrote:
>> If you are worried about vast tracts of IPs ripe for the plucking,
>> then let's write policy to find and recover those tracts - Or at least
>> to stop Orgs with those unused/underused resources from getting more.
>> Size, type, industry are not the issues here; efficient utilization
>> is.
>
> Find and recover is a non-starter because it costs too much money
> for ARIN to do this kind of detailed audit.
>
> Efficient utilization is unknown without audits.
>
> Therefore, make the set-aside policy only available for orgs whose
> address allocations are less than a certain threshold.
>
> --Michael Dillon
>
> P.S. Fairness is irrelevant. Any set aside policy is unfair. Doing nothing is unfair.
> Life is unfair. We aren't here to change the world, just to reduce the chaos and
> disorder of the IPv6 transition.
>
> Period.
>


On these and on other points I find myself in agreement with Bill and 
Michael, reminding me of why I chose this size related viewpoint as an 
explicit portion of abandoned policy proposal 110, which I remain 
partial to.

The maximum resources available to any sized organization under any set 
aside policy is quite relevant. It is possible to make large enough 
resources available so that even the larger organizations cannot match 
it through increased internal efficiencies. Blatant exclusivity would 
then be unnecessarily unfair.

I am in favor of any set aside policy that expands 4.10, as it has a 
similar effect as abandoned policy proposal 112, details regardless.

I tend toward neutrality or disfavor for any policy that nitpicks 4.10 
without expansion.

I am in favor of maximum allocation limits and I am in favor of 
structuring a set aside policy so that those who can easily come up with 
the same resources available under the policy will either tend not to 
apply or will be specifically excluded.

Without a fairly strict maximum limit on allocation size, I would 
advocate that increasingly larger allocations require an increasingly 
larger burden of proof on the actual unavailability of equivalent 
resources from any other internal mechanism. This is likely to be overly 
burdensome and subjective to both the requester and to ARIN

I therefore consider relatively small maximum allocation limits along 
with either explicit or implicit restrictions based on the size of 
current holdings to be the superior approach.

I feel very uncomfortable with increasing nitpicks and dictates as to 
what uses are appropriate and which are not for resources. The deeper we 
embroil ourselves there the deeper my discomfort. Creating process for 
ongoing nitpicking would be an interesting exercise, but still the wrong 
idea, and I would not support that.

Further, I do not support restricting set aside policy to transition 
mechanisms alone. Transition space is all well and good if that is what 
everyone is doing and where the needs actually are, in which case that 
is what set aside resources will be used for, naturally, without 
burdensome and process heavy explicit restrictions.

However, it would be quite unfortunate if organizations who can realize 
economy of scale from efficiency improvements and can utilize market 
clout continue with business as usual while everyone else goes into 
decline and gets the shaft.

These and similarly bleak scenarios are certainly possible and we cannot 
give odds good enough against their unfolding so as to blithely ignore them.

Making resources available solely for transitioning to IPv6 even if 
doing so does not put bread on the table for the hoi polloi brings to my 
mind an uncomfortable potential for resemblance to a well known if 
historically vague phrase.

"Let them use IPv6" must not be our epitaph.


Joe


From jmaimon at chl.com  Wed Jul 28 11:21:57 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 28 Jul 2010 11:21:57 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTi=StxcJkb_X-9MRduxQDxJ60hY3HLVb-FLCNHbh@mail.gmail.com>
References: <C87376B6.A832%marty@akamai.com>	<BC45F5EB-DA23-4620-96B1-8CB7F63877BA@delong.com>
	<AANLkTi=StxcJkb_X-9MRduxQDxJ60hY3HLVb-FLCNHbh@mail.gmail.com>
Message-ID: <4C504B15.1070906@chl.com>



William Herrin wrote:
> On Mon, Jul 26, 2010 at 12:40 PM, Owen DeLong<owen at delong.com>  wrote:
>> The acceptable use list is (desirably in my opinion) pretty limited.
>> I can't imagine expanding any combination of the following:
>>
>>         Router Loopbacks
>>         NAT Gateways
>>         Qualifying TE entries
>>         Point to Point links
>
> I don't think we even give 'em point to point links. For the last /8
> the vendors can damn well fix their code to originate ICMP from the
> loop0 address instead of the RFC1918 address on the interface.
>
> Regards,
> Bill Herrin
>


I completely agree. That feature would be really lovely along with other 
control plane traffic handling improvements and wider availability of 
proper address abstraction off of the physical interface.

Joe


From Wesley.E.George at sprint.com  Wed Jul 28 16:30:13 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Wed, 28 Jul 2010 15:30:13 -0500
Subject: [arin-ppml] Draft Policy 2010-11: Required Resource Reviews
In-Reply-To: <4C45E6F9.8010207@arin.net>
References: <4C45E6F9.8010207@arin.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A898F7CCA4@PLSWM01C.ad.sprint.com>

I support this proposal, with the exception of item d, which I believe needs to be reworded.

The rationale (which refers to it as section E) makes sense to me, but I don't think that the wording stands on its own to convey that intent. It's too easy to misinterpret. A reference simply to 4.2.3.7.6 does not clarify this enough in my opinion, and should also include references to 4.2.3.7.2 and 4.2.3.7.5, possibly even explicitly stating "larger than /29" so that it's much clearer that you're referring specifically to closing a loophole (allocations larger than /29 for privacy as a means to hide/hoard addresses) without dramatically increasing the likelihood of audit for ISPs whose primary customers are residential.

Thanks,
Wes George
-----Original Message-----

Draft Policy 2010-11
Required Resource Reviews

Version/Date: 20 July 2010

Policy statement:

Replace the text "under sections 4-6" in section 12, paragraph 7 with
"under paragraphs 12.4 through 12.6"

Add to section 12 the following text:

10. Except as provided below, resource reviews are conducted at the
discretion of the ARIN staff. In any of the circumstances mentioned
below, a resource review must be initiated by ARIN staff:

a. Report or discovery of an acquisition, merger, transfer, trade or
sale in which the infrastructure and customer base of a network move
from one organization to another organization, but, the applicable IP
resources are not transferred. In this case, the organization retaining
the IP resources must be reviewed. The organization receiving the
customers may also be reviewed at the discretion of the ARIN staff.

b. Upon receipt by ARIN of one or more credible reports of fraud or
abuse of an IP address block. Abuse shall be defined as use of the block
in violation of the RSA or other ARIN policies and shall not extend to
include general reports of host conduct which are not within ARIN's scope.

c. In the case where an organization wishes to act as recipient of
resources pursuant to a transfer under section 8.3, unless otherwise
prohibited by paragraph 12.2(c).

d. An organization which submits a request for additional resources when
more than 25% of their existing resources are obscured in SWIP or RWHOIS
pursuant to section 4.2.3.7.6 (residential customer privacy).

e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
exempt organizations from the reviews required under section 12.10.

Rationale:

The first change is a minor correction which improves clarity and
consistency of the original policy without changing the meaning.

The addition of 12.10 (a) through (e) serves to create a set of
circumstances under which a resource review is required, rather than
optional and entirely at ARIN staff discretion.

The majority of early comments on this proposal focused on 12.10 (e).
Mostly it was confusion about the exact ramifications. This section will
cause ARIN to maintain greater scrutiny only in cases where a given ISP
issues more than 25% of their total space to residential customers who
wish to remain anonymous and receive network blocks of /29 or larger. To
the best of my knowledge, there are not currently any ISPs which meet
this criteria. Additionally, it would only apply that scrutiny to IPv4,
and will not carry forward into IPv6 residential assignments.

This policy should improve the compliance verification of ARIN policies
and may result in the improved reclamation of under-utilized IP address
space. It should also serve as a deterrent to certain address hoarding
tactics which have come to light in recent history.

Timetable for implementation: Immediately upon ratification by the Board


#####


STAFF ASSESSMENT

Proposal: (117) Required Resource Reviews
Proposal Version (Date): 07 July 2010
Date of Assessment:  14 July 2010

1. Proposal Summary (Staff Understanding)

This draft policy establishes new criteria to enact NRPM 12 resource
reviews. It requires ARIN staff to initiate resource reviews when M&A
activity occurs but IP addresses are not transferred to the acquirer;
when fraud or abuse is reported to ARIN, either about a specific IP
address range or about an OrgID; when any NRPM 8.3 transfer occurs; or
when staff are reviewing an additional IP address request and find that
more than a quarter of an OrgID's downstream SWIPs are covered under the
Residential Customer Privacy policy.

2. Comments

A. ARIN Staff Comments

*  This proposal could cause ARIN staff to conduct resource reviews on a
more frequent basis. Any prescription for prioritizing such reviews
could delay other important registration activities from being processed
in a timely manner.

B. ARIN General Counsel

Pending


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:

*  Resource reviews, audits, and fraud research require many man-hours.
  These new requirements to conduct audits on a much more regular basis
could necessitate hiring and training additional registration staff.
*  Changes to current business practices
*  Staff training
*  Updated guidelines


4. Proposal Text

Policy statement:

Replace the text "under sections 4-6" in section 12, paragraph 7 with
"under paragraphs 12.4 through 12.6"
Add to section 12 the following text:

10. Except as provided below, resource reviews are conducted at the
discretion of the ARIN staff. In any of the circumstances mentioned
below, a resource review must be initiated by ARIN staff:
a. Report or discovery of an acquisition, merger, transfer, trade or
sale in which the infrastructure and customer base of a network move
from one organization to another organization, but, the applicable IP
resources are not transferred. In this case, the organization retaining
the IP resources must be reviewed. The organization receiving the
customers may also be reviewed at the discretion of the ARIN staff.
b. Upon receipt by ARIN of one or more credible reports of fraud or
abuse of an IP address block. Abuse shall be defined as use of the block
in violation of the RSA or other ARIN policies and shall not extend to
include general reports of host conduct which are not within ARIN's scope.
c. In the case where an organization wishes to act as recipient of
resources pursuant to a transfer under section 8.3, unless otherwise
prohibited by paragraph 12.2(c).
d. An organization which submits a request for additional resources
when more than 25% of their existing resources are obscured in SWIP or
RWHOIS pursuant to section 4.2.3.7.6 (residential customer privacy).
e. Other than as specified in 12.10(c), paragraph 12.2(c) does not
exempt organizations from the reviews required under section 12.10.

Rationale:

The first change is a minor correction which improves clarity and
consistency of the original policy without changing the meaning.
The addition of 12.10 (a) through (e) serves to create a set of
circumstances under which a resource review is required, rather than
optional and entirely at ARIN staff discretion.

The majority of early comments on this proposal focused on 12.10 (e).
Mostly it was confusion about the exact ramifications. This section will
cause ARIN to maintain greater scrutiny only in cases where a given ISP
issues more than 25% of their total space to residential customers who
wish to remain anonymous and receive network blocks of /29 or larger. To
the best of my knowledge, there are not currently any ISPs which meet
this criteria. Additionally, it would only apply that scrutiny to IPv4,
and will not carry forward into IPv6 residential assignments.

This policy should improve the compliance verification of ARIN policies
and may result in the improved reclamation of under-utilized IP address
space. It should also serve as a deterrent to certain address hoarding
tactics which have come to light in recent history.






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


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 Wesley.E.George at sprint.com  Wed Jul 28 17:54:57 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Wed, 28 Jul 2010 16:54:57 -0500
Subject: [arin-ppml] Policies 2010-12 and 2010-9
Message-ID: <F7EB0A7C707E39409A73CD0353242551A898FF698D@PLSWM01C.ad.sprint.com>

Since these two policies are covering overlapping ground, I'm responding to them together. I generally support the concept behind both policies of providing the flexibility to get additional IPv6 allocations for justifiable implementations, but I would prefer a more generalized policy change for any appropriate transition technology (like -12) than I would something specific to 6RD (like -9).

Therefore, I support 2010-12 and I do not support 2010-9 as a standalone policy.

However, I think that the staff concerns raised in 2010-12 are valid as they regard definition of valid transition technologies that can be used as justification, rather than simply leaving it open-ended. There are probably a couple of ways to provide additional guidance to ARIN staff, either through updates to the policy proposal itself or via AC feedback to ARIN staff
1) by specifically referencing the appropriate IETF RFCs (or drafts?) that are considered transition technologies along with a brief explanation of why they may require additional allocations of IPv6 space to implement, and what questions/plans ARIN staff should request when validating a submission. This would require continuing to update the policy to incorporate additional technologies as they come about.
The problem with this would be the fact that people often implement things like this while they are still in draft form in the IETF, and the PDP may not be responsive enough to make changes as rapidly as required. It's possible that some of these uses could be treated as Section 11 Experimental and just allocate the blocks in such a way that they can be converted to normal allocations without return/renumbering once the policy is updated to cover the appropriate transition technology. Alternatively, the policy could provide a way to get provisional approval for technologies not explicitly defined in the current policy, perhaps by coupling the request for address space with a policy proposal submitted by the requestor to cover their particular use. This would provide incentive to participate in the PDP, and also ensure that any of the provisional (eg not explicitly covered by current policy) technologies are in front of the community for input as soon as is possible.
2) Formalize a method to provide direct consultation to ARIN staff on technical matters that are not explicitly covered in the NRPM, either via the AC or the community. There are other threads now talking about small expert review panels (proposal 116) to provide technical guidance to ARIN staff, which I think is probably not the right way to go, but I do think that there may be a need for this type of guidance outside of a formal policy change. If the concern is that ARIN staff is not equipped to make decisions on certain technical matters without additional guidance, either the AC could weigh in, or it could be pushed to one of the discussion lists for community input (perhaps ARIN-consult?). I would think that the number of exceptions that would require this additional guidance could be limited so that it doesn't represent a drain on the resources involved nor an unacceptable delay in processing new requests for address space.

There are those who would say, IPv6 address space is virtually limitless, why are we so worried about a couple of additional /32 allocations? That may be a fair point, but I personally think it's worth ensuring that we expect proper justification for allocations to strike that balance between being stingy with a freely-available resource and being wasteful.

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 scottleibrand at gmail.com  Wed Jul 28 18:19:13 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 28 Jul 2010 15:19:13 -0700
Subject: [arin-ppml] Policies 2010-12 and 2010-9
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A898FF698D@PLSWM01C.ad.sprint.com>
References: <F7EB0A7C707E39409A73CD0353242551A898FF698D@PLSWM01C.ad.sprint.com>
Message-ID: <4C50ACE1.9070406@gmail.com>

On Wed 7/28/2010 2:54 PM, George, Wes E IV [NTK] wrote:
> I think that the staff concerns raised in 2010-12 are valid as they regard definition of valid transition technologies that can be used as justification, rather than simply leaving it open-ended. There are probably a couple of ways to provide additional guidance to ARIN staff, either through updates to the policy proposal itself or via AC feedback to ARIN staff
> 1) by specifically referencing the appropriate IETF RFCs (or drafts?) that are considered transition technologies along with a brief explanation of why they may require additional allocations of IPv6 space to implement, and what questions/plans ARIN staff should request when validating a submission. This would require continuing to update the policy to incorporate additional technologies as they come about.
>    

A similar approach was just introduced in APNIC 
(http://www.apnic.net/__data/assets/text_file/0004/22594/prop-087-v001.txt):

> It is proposed that:
>
> 4.1 In the IPv6 deployment phase (til 2013), networks using an IPv6
>      deployment protocol specified in an Standard track RFC are eligible
>      for initial allocations larger than a /32.
>
>      Requestors must specifically refer to the deployment protocol they
>      are using and the number of the RFC describing it.
>    

That has the same potential problem you outline below, of course:

> The problem with this would be the fact that people often implement things like this while they are still in draft form in the IETF, and the PDP may not be responsive enough to make changes as rapidly as required. It's possible that some of these uses could be treated as Section 11 Experimental and just allocate the blocks in such a way that they can be converted to normal allocations without return/renumbering once the policy is updated to cover the appropriate transition technology. Alternatively, the policy could provide a way to get provisional approval for technologies not explicitly defined in the current policy, perhaps by coupling the request for address space with a policy proposal submitted by the requestor to cover their particular use. This would provide incentive to participate in the PDP, and also ensure that any of the provisional (eg not explicitly covered by current policy) technologies are in front of the community for input as soon as is possible.
>    

That may work, except the current NRPM 11.1 text on experimental 
allocations (https://www.arin.net/policy/nrpm.html#eleven) says:
> Applicants for an experimental allocation are expected to demonstrate 
> an understanding that when the experiment ends, the allocation will be 
> returned; a successful experiment may need a new allocation under 
> normal policies in order to continue in production or commercial use, 
> but will not retain the experimental allocation.
So unless we write in a policy exception to that, you couldn't count on 
keeping the same space if you converted it to a normal allocation...


-Scott



From marquis at roble.com  Wed Jul 28 22:18:40 2010
From: marquis at roble.com (Roger Marquis)
Date: Wed, 28 Jul 2010 19:18:40 -0700 (PDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <mailman.7.1280332802.12030.arin-ppml@arin.net>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
Message-ID: <20100729021840.B101E2B2135@mx5.roble.com>

>> If you are worried about vast tracts of IPs ripe for the plucking,
>> then let's write policy to find and recover those tracts - Or at least
>> to stop Orgs with those unused/underused resources from getting more.
>> Size, type, industry are not the issues here; efficient utilization
>> is.
>
> Find and recover is a non-starter because it costs too much money
> for ARIN to do this kind of detailed audit.

One FTE is too much money for ARIN?  Considering the ROI I have to
disagree.

> Efficient utilization is unknown without audits.

Agreed, however, this sort of audit is not only feasible it is actually
pretty straightforward.  It would have to be done in two phases, the
first automated ie., collecting statistics, the second manual and
personal.  Phase two would be much like what we think of as "management
by walking around" requiring face time, on-site visits, meetings, and a
fair bit of travel by the auditor.  There's just too much detailed
understanding and communication required to leave anything other than a
small percent of this job to emails, phone calls, or anything other than
face to face discussion.

Tech audits are never easy, however, these would be different in some
respects.  One difference would be with regards to stonewalling.  Every
auditor and project manager has to deal with stonewalling, but in this
scenario the case for treating such responses as strong indications of
hoarding and waste would be compelling, and should result in raising the
profile of that particular org's audit and also raising its requirements
for keeping old and requesting new addresses.

As with any audit this one should be based on pre-defined policies to the
extent possible.  Those policies would have to insure confidentiality,
indemnification (for auditors and whistle-blowers), and strong
disincentives for failing to facilitate the auditor's task at a minimum.

I can think of a number of individuals on this list would would excel
at such an audit, and I'd love to do it myself (for the right
compensation).  It would also be a great way around many of the
disagreements and misunderstanding we continually deal with on this list
which are solely due to the limitations of email.

> P.S. Fairness is irrelevant. Any set aside policy is unfair. Doing nothing
> is unfair. Life is unfair. We aren't here to change the world, just to
> reduce the chaos and disorder of the IPv6 transition.

That's probably not a productive motivation for an IPv4 audit.  An
auditor would have to be equally aware of both the need for an IPv6
transition and the real-world barriers to that transition.  Agendas like
some (including myself) have expressed with regards to IPv6, NAT, GUA,
etc. would have to take a back seat to understanding and appreciation of
day-to-day operational realities and, most importantly, organizational
budgeting and politics.

If my experience working at orgs who have and continue to hoard /8s and
/16s is representative, the amount of recoverable address space using
this methodology would be upwards of 20% of all IPv4 addresses.

IMO,
Roger Marquis


From owen at delong.com  Thu Jul 29 00:09:35 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 28 Jul 2010 21:09:35 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100729021840.B101E2B2135@mx5.roble.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
Message-ID: <031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>


On Jul 28, 2010, at 7:18 PM, Roger Marquis wrote:

>>> If you are worried about vast tracts of IPs ripe for the plucking,
>>> then let's write policy to find and recover those tracts - Or at least
>>> to stop Orgs with those unused/underused resources from getting more.
>>> Size, type, industry are not the issues here; efficient utilization
>>> is.
>> 
>> Find and recover is a non-starter because it costs too much money
>> for ARIN to do this kind of detailed audit.
> 
> One FTE is too much money for ARIN?  Considering the ROI I have to
> disagree.
> 
Likely return is very close to zero. Given that, the amount of investment
possible for a decent ROI is well below one FTE.

>> Efficient utilization is unknown without audits.
> 
> Agreed, however, this sort of audit is not only feasible it is actually
> pretty straightforward.  It would have to be done in two phases, the
> first automated ie., collecting statistics, the second manual and
> personal.  Phase two would be much like what we think of as "management
> by walking around" requiring face time, on-site visits, meetings, and a
> fair bit of travel by the auditor.  There's just too much detailed
> understanding and communication required to leave anything other than a
> small percent of this job to emails, phone calls, or anything other than
> face to face discussion.
> 
You assume that all valid uses of address space are publicly visible
for automated statistics to gather. That simply isn't true.

Additionally, much of the space to be audited is legacy space where
it is not entirely clear ARIN can do much about the situation after the
audit anyway.

> Tech audits are never easy, however, these would be different in some
> respects.  One difference would be with regards to stonewalling.  Every
> auditor and project manager has to deal with stonewalling, but in this
> scenario the case for treating such responses as strong indications of
> hoarding and waste would be compelling, and should result in raising the
> profile of that particular org's audit and also raising its requirements
> for keeping old and requesting new addresses.
> 
Auditing is already done to some extent for each new request. There is
a draft policy in place to expand this. However, there is a big leap of
faith in between beginning to audit and actually reclaiming significant
amounts of address space.

Do you have any evidence that there are significant quantities of
non-legacy address space available to be reclaimed at the end of
an audit process? Even a basis for credible suspicion?

> As with any audit this one should be based on pre-defined policies to the
> extent possible.  Those policies would have to insure confidentiality,
> indemnification (for auditors and whistle-blowers), and strong
> disincentives for failing to facilitate the auditor's task at a minimum.
> 
ARIN really doesn't have any ability to protect whistle-blowers or to
provide much in the way of disincentives for failure to cooperate.
That would require legislation, not just ARIN policy. Since ARIN
deals with resources in at least 24 national jurisdictions, legislation
would be complicated at best.
> 
> That's probably not a productive motivation for an IPv4 audit.  An
> auditor would have to be equally aware of both the need for an IPv6
> transition and the real-world barriers to that transition.  Agendas like
> some (including myself) have expressed with regards to IPv6, NAT, GUA,
> etc. would have to take a back seat to understanding and appreciation of
> day-to-day operational realities and, most importantly, organizational
> budgeting and politics.
> 
An auditor as you are describing shouldn't actually bring any opinions
on IPv6 transition or any of the other factors to the table at all. To the
extent possible, the auditor should be strictly looking at whether the
address utilization is sufficiently efficient according to ARIN policy to
justify the address space held and making a report of that fact or of
the extent to which the organization in question is out of compliance
with ARIN policy.

The next step would be for staff to institute voluntary or forced reclamation
procedures as required under section 12 after the audit, if the organization
is significantly out of compliance.

> If my experience working at orgs who have and continue to hoard /8s and
> /16s is representative, the amount of recoverable address space using
> this methodology would be upwards of 20% of all IPv4 addresses.
> 
Are those orgs hoarding ARIN-issued space or legacy space? If it's legacy
space, how, exactly do you expect ARIN with no contract and tenuous at
best RFC-based policy to actually reclaim such addresses?

Additionally, 20% is a pretty bold claim. That would require no less
than 51 /8s available to reclaim. Of the 221 available unicast /8s
issued by or available to be issued by IANA, ARIN has received 51.

Accordingly, for ARIN to achieve the return of 20% of all IPv4 addresses,
they would need to prove that 71% of all addresses under ARIN
stewardship, legacy and RSA-bound together, are un-utilized and
subject to reclamation. They would then need to successfully
reclaim them.

First, I think your premise is flawed and that it is very unlikely that
71% of IP addresses in the ARIN region are wasted. I don't think
the number even approaches 20%, but, 71% is an outrageous
claim.

Second, even if we assume that 50% of all legacy addresses are
un-utilized, reclaiming them may well be an impossible legal
battle.

On a theoretical level, if there is demand for address space, then
NRPM 8.3 should lead to the majority of the possible reclamations
without need for massive resources invested into auditing as there
will be available financial incentives to organizations to make
space they do not need available to organizations that need it.

I don't expect NRPM 8.3 to be particularly effective. I do expect it
to be much more effective than any such forced reclamation
effort could possibly be and on a much more timely basis.

Owen



From warren at wholesaleinternet.com  Thu Jul 29 01:06:55 2010
From: warren at wholesaleinternet.com (Warren Wholesale.com)
Date: Wed, 28 Jul 2010 23:06:55 -0600
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100729021840.B101E2B2135@mx5.roble.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
Message-ID: <08e301cb2edb$dece2b00$9c6a8100$@com>

I don't think this is as straight forward as you think. For one thing,
there are privacy concerns about data and information. For another, no
one-person may have complete knowledge of where everything is and orgs
aren't going to want to accidentally lose IPs that are being used. 

Because you can't get anymore ipv4 allocations organizations are going to be
super paranoid about these kind of audits and will proceed through them at a
slow-meticulous pace and only after being coerced into it.  And even if the
auditor person thinks they found something amiss and tries to take back IP
space, you're going to find yourself entangled in all sorts of legal
wrangling.  

Is that really worth the effort to maybe recover a few million IPs?  Imagine
how long even 10 or 20 million IP addresses would last when you have months
upon months of backlogged requests.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Roger Marquis
Sent: Wednesday, July 28, 2010 8:19 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Set aside round deux

>> If you are worried about vast tracts of IPs ripe for the plucking,
>> then let's write policy to find and recover those tracts - Or at least
>> to stop Orgs with those unused/underused resources from getting more.
>> Size, type, industry are not the issues here; efficient utilization
>> is.
>
> Find and recover is a non-starter because it costs too much money
> for ARIN to do this kind of detailed audit.

One FTE is too much money for ARIN?  Considering the ROI I have to
disagree.

> Efficient utilization is unknown without audits.

Agreed, however, this sort of audit is not only feasible it is actually
pretty straightforward.  It would have to be done in two phases, the
first automated ie., collecting statistics, the second manual and
personal.  Phase two would be much like what we think of as "management
by walking around" requiring face time, on-site visits, meetings, and a
fair bit of travel by the auditor.  There's just too much detailed
understanding and communication required to leave anything other than a
small percent of this job to emails, phone calls, or anything other than
face to face discussion.

Tech audits are never easy, however, these would be different in some
respects.  One difference would be with regards to stonewalling.  Every
auditor and project manager has to deal with stonewalling, but in this
scenario the case for treating such responses as strong indications of
hoarding and waste would be compelling, and should result in raising the
profile of that particular org's audit and also raising its requirements
for keeping old and requesting new addresses.

As with any audit this one should be based on pre-defined policies to the
extent possible.  Those policies would have to insure confidentiality,
indemnification (for auditors and whistle-blowers), and strong
disincentives for failing to facilitate the auditor's task at a minimum.

I can think of a number of individuals on this list would would excel
at such an audit, and I'd love to do it myself (for the right
compensation).  It would also be a great way around many of the
disagreements and misunderstanding we continually deal with on this list
which are solely due to the limitations of email.

> P.S. Fairness is irrelevant. Any set aside policy is unfair. Doing nothing
> is unfair. Life is unfair. We aren't here to change the world, just to
> reduce the chaos and disorder of the IPv6 transition.

That's probably not a productive motivation for an IPv4 audit.  An
auditor would have to be equally aware of both the need for an IPv6
transition and the real-world barriers to that transition.  Agendas like
some (including myself) have expressed with regards to IPv6, NAT, GUA,
etc. would have to take a back seat to understanding and appreciation of
day-to-day operational realities and, most importantly, organizational
budgeting and politics.

If my experience working at orgs who have and continue to hoard /8s and
/16s is representative, the amount of recoverable address space using
this methodology would be upwards of 20% of all IPv4 addresses.

IMO,
Roger Marquis
_______________________________________________
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: winmail.dat
Type: application/ms-tnef
Size: 4638 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100728/69120fad/attachment.bin>

From michael.dillon at bt.com  Thu Jul 29 09:03:46 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 29 Jul 2010 14:03:46 +0100
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918021AA0@EMV01-UKBR.domain1.systemhost.net>

> Do you have any evidence that there are significant quantities of
> non-legacy address space available to be reclaimed at the end of
> an audit process? Even a basis for credible suspicion?

Even where there is credible suspicion, you need to balance it with
the organizations pending requests to ARIN for additional space. The
orgs which are most likely to be able to free up a large chunk of addresses
are also highly likely to come to ARIN within 3 months for a similar sized
chunk. All they have to do is get a court order to delay things for a
few months (childsplay for a beginning lawyer fresh out of law school)
and they can demonstrate technical justification to a judge, for keeping
those addresses.

In fact, most of the so-called wastage is not in big chunks, but in
little scattered chunks which can only be effectively used in the same
provider's network. If you force them to renumber in order to aggregate
chunks, then by the time that is done, months have passed and they have
a new technical justification for keeping the addresses.

There is no pot of gold out there. IPv4 exhaustion really does mean
that the set of numbers known as IPv4 addresses, really are mostly used
up. Any chunks that are in a questionable state are small and scattered,
and may actually be in use but just lost in play due to recordkeeping
issues. Having bad records is not a technical justification for taking
addresses away from an org.

> The next step would be for staff to institute voluntary or forced
> reclamation
> procedures as required under section 12 after the audit, if the
> organization
> is significantly out of compliance.

Big, big, big, IF.
Most orgs that are out of compliance are not significantly out of
compliance, and if they knew about it, they would get in compliance
by reusing addresses rather than asking for more.

> > If my experience working at orgs who have and continue to hoard /8s
> and
> > /16s is representative, the amount of recoverable address space using
> > this methodology would be upwards of 20% of all IPv4 addresses.

If releasing the hoard requires network redesign, then it would not take
much to convince a judge to delay any ARIN action until the org deploys
IPv6 given the major importance of the IPv6 transition. 

There really is not much that ARIN can do to change the way that IPv4
exhaustion impacts us. It is too late. About the only thing that would
help us through the IPv6 transition would be a massive educational 
program by ARIN, starting with sessions for New York stock market analysts
who ask CEOs the tough questions when they present their quarterly
results.

--Michael Dillon



From Wesley.E.George at sprint.com  Thu Jul 29 12:51:47 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Thu, 29 Jul 2010 11:51:47 -0500
Subject: [arin-ppml] Petition for discussion of policy proposal 116
 (Permitted Uses of Space Reserved Under NRPM 4.10)
In-Reply-To: <9D340498-48D7-4EF4-B770-5CA009CF6640@delong.com>
References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
	<F7EB0A7C707E39409A73CD0353242551A898FF6D6C@PLSWM01C.ad.sprint.com>
	<9D340498-48D7-4EF4-B770-5CA009CF6640@delong.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A898FF6EA3@PLSWM01C.ad.sprint.com>


I support this petition. I'm not necessarily in favor of the current proposal as written, but I think it raises a valid point and should be discussed further, especially in light of the discussions around 6RD and other transition technologies referenced in 2010-9 and 12. Petition has my contact info in a separate message.
Thanks,
Wes George


From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, July 21, 2010 2:19 AM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net> List; petition at arin.net<mailto:petition at arin.net>
Subject: [arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10)

The AC abandoned the following proposal:

 116. Permitted Uses of space reserved under NRPM 4.10

The AC voted to abandon this proposal because of a lack of sufficient
support to accept it as draft policy. Several AC members felt it not
appropriate that ARIN policy dictate any specific architecture or method
a network should use to transition from v4 to v6.

This is my formal request to initiate a discussion petition of proposal 116.

If you would like to sign this petition, please do the following:

            1.         Send a message stating "I support the petition for discussion of proposal 116"
                        to arin-ppml at arin.net<mailto:arin-ppml at arin.net>

            2.         Either include your contact information and organizational affiliation in
                        the original message to ppml or send it in a separate message to
                        petition at arin.net<mailto:petition at arin.net> (use this address if you do not want your contact
                        information disclosed to PPML).

Thank you.

I believe that the AC should not have abandoned this proposal for the following
reasons:

1.         I believe that there is community support for clarifying valid uses and
            preventing abuses of space reserved for transitional technologies under
            section 4.10.

2.         The language of 116 states examples of valid uses of space under 4.10
            but does not specify or dictate specific architecture or methods. It attempts
            to prevent space reserved for transition from being used in a business-as-
            usual method that is not in direct support of a transition to IPv6 because
            the author believes that is contrary to the community intent of 4.10.

            I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid
            technologies and includes specifically (e) etc. to cover any possible
            valid technologies not yet contemplated.

3.         The language in the existing 4.10 is not sufficiently specific to prevent
            a multitude of possible abuses of the reserved space that do not actually
            benefit a transition process.

For these reasons, I encourage anyone who feels that section 4.10 reflects the
good intent of the community to sign this discussion petition to get this policy
in front of the community in Atlanta. Even if you disagree with the specifics, those
can be addressed in the development of the policy. If you have comments on
those specifics, please direct them to ppml or to me.


Author contact information as required in the petition process:

Owen DeLong
owen at delong.com<mailto:owen at delong.com>
+1.408.890.7992

Here is the text of the proposal in question as required in the petition
process:

Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10
Proposal Originator: Owen DeLong
Proposal Version: 1
Date: 18 June 2010
Proposal type: modify
Policy term: permanent
Policy statement:
Add the following to section 4.10 of the NRPM
6. No organization may receive more than 16 /24 equivalents under this
section.
Add the following to section 4 of the NRPM
4.11 Required utilization for subsequent allocation under section 4.10
No organization shall receive more than one allocation or assignment
under section 4.10 unless all prior space issued under 4.10 meets the
utilization requirements of this section.
1. The most recent 4.10 allocation/assignment must be at least 80% utilized.
2. All utilization must be permitted under section 4.12
3. All prior 4.10 allocation/assignments must be at least 90% utilized.
4.12 Permitted uses of allocations or assignments under section 4.10
No organization shall use space received under section 4.10 for any
purpose other than as specified in this section
1. To provide the required public IPv4 address(es) for transitional
technologies operated by the recipient organization.
a. Large scale or "Carrier Grade" NAT
b. NAT-PT
c. DS-LITE/AFTeR
d. DNS64 or other transitional DNS enablers
e. etc.
2. For other transitional technologies not envisioned at the time of
this proposal, but, in no case for general IPv4 addressing provided to
customers.
Rationale:
The current terminology in section 4.10 is vague and could allow a
variety of interpretations which could lead to allocations or
assignments being made to ISPs intending to misuse the space for general
deployment by using IPv6 overlay technologies as a "IPv6 deployments"
requiring IPv4 space for transition. For example, the current policy
could be interpreted to enable an ISP to require IPv4 addresses for all
IPv6 customers to roll IPv6 out as 6rd to customers who would be
otherwise unable to get IPv4 space. This is clearly outside of the
original intent of the proposal which created 4.10 (6rd was not yet
envisioned at the time that was written). This proposal seeks to clarify
that intent and tighten up the requirements for organizations seeking to
get space from this limited final resource so that it truly is available
to facilitate transitional technologies.
Timetable for implementation: immediate
For reference, here is the current text of 4.10
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.
This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.
In order to receive an allocation or assignment under this policy:
1. the applicant may not have received resources under this policy in
the preceding six months;
2. previous allocations/assignments under this policy must continue to
meet the justification requirements of this policy;
3. previous allocations/assignments under this policy must meet the
utilization requirements of end user assignments;
4. the applicant must demonstrate that no other allocations or
assignments will meet this need;
5. on subsequent allocation under this policy, ARIN staff may require
applicants to renumber out of previously allocated / assigned space
under this policy in order to minimize non-contiguous allocations.

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


________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100729/e7c07427/attachment.htm>

From bill at herrin.us  Thu Jul 29 14:21:27 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 08:21:27 -1000
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net> 
	<20100729021840.B101E2B2135@mx5.roble.com>
	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
Message-ID: <AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>

On Wed, Jul 28, 2010 at 6:09 PM, Owen DeLong <owen at delong.com> wrote:
> Do you have any evidence that there are significant quantities of
> non-legacy address space available to be reclaimed at the end of
> an audit process? Even a basis for credible suspicion?

Hi Owen,

Didn't we hear an anecdote last week about someone who quit Verizon a
decade ago but the addresses are still reassigned to them? Didn't one
of the academics do a peer-reviewed study and a scan of the Internet
last year with results suggesting (among other things) that about
2/3rds of the allocated address space is not employed on the public
Internet?

Meaningful audits would be incredibly expensive and manpower
intensive, no doubt about it. The odds of the POC for any given SWIP
being correct, reachable, willing to talk and knowledgeable enough to
confirm both their specific addresses and qualifications for that size
of address bank is, well, not great. Working past that would be really
hard. We could easily find that getting an accurate census requires
sending someone into the field to knock on doors.

But let's not kid ourselves: there are plenty of credible reasons to
believe there are lots of mislaid addresses waiting to be found. The
question is whether finding them would be really expensive or
impossibly expensive.


Even if expensive, I think there are a couple cases where thorough
audits would serve the community well:

1. Reports of fraud or undue carelessness. This should trigger a
stochastic audit where a subset of the address space gets carefully
checked to estimate the error rate. If the error rate looks high, give
the registrant a chance to fix it and the do a new stochastic audit.
If still high, proceed to a full audit.

2. Prior to receiving 4.10 addresses, the organization and its
affiliates should complete a full audit, including their legacy
address space. ARIN may or may not have any rights to an org's legacy
address space, but we're certainly not obligated to give the org more
addresses if it can't prove a cautious and thorough use of its
existing addresses.

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  Thu Jul 29 14:34:29 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 08:34:29 -1000
Subject: [arin-ppml] Ending point to point links as a justification for a
	/30?
Message-ID: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>

On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon <jmaimon at chl.com> wrote:
> William Herrin wrote:
>> I don't think we even give 'em point to point links. For the last /8
>> the vendors can damn well fix their code to originate ICMP from the
>> loop0 address instead of the RFC1918 address on the interface.
>
> I completely agree. That feature would be really lovely along with other
> control plane traffic handling improvements and wider availability of proper
> address abstraction off of the physical interface.

How much support would there be for a policy proposal to exclude point
to point links as a justification for any global IP addresses
effective, say, 1/1/2012? Along with a stern recommendation from ARIN
to the routing vendors that they update their software to prevent the
non-availability of of addresses for point to point links from causing
malfunctions with ICMP warnings and errors?

You'd still be able to justify an IP address for the router, of
course, but you wouldn't be able to justify any addresses for the
individual point to point links, regardless of technology employed. So
you'd end up using unnumbered serial interfaces and RFC1918 addresses
on the point to point ethernets.

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 dsd at carpathiahost.com  Thu Jul 29 14:46:29 2010
From: dsd at carpathiahost.com (David Divins)
Date: Thu, 29 Jul 2010 14:46:29 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a	/30?
In-Reply-To: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
Message-ID: <46D17940F4B3C84AB02E7D5BFC0588CC0EEE6AAA@EX2K7VS04.4emm.local>

I'm going to disagree on this one.  I think /30's must be a valid use and I will let others explain (or explode) why 1918 on the ptop may be a bad idea.

-dsd

David S. Divins
Principal Engineer
Carpathia Hosting, Inc.
43480 Yukon Dr., #200
Ashburn, VA ?20147
(703) 652-5955
www.carpathiahost.com

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Thursday, July 29, 2010 2:34 PM
To: Joe Maimon
Cc: arin-ppml at arin.net List
Subject: [arin-ppml] Ending point to point links as a justification for a /30?

On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon <jmaimon at chl.com> wrote:
> William Herrin wrote:
>> I don't think we even give 'em point to point links. For the last /8
>> the vendors can damn well fix their code to originate ICMP from the
>> loop0 address instead of the RFC1918 address on the interface.
>
> I completely agree. That feature would be really lovely along with other
> control plane traffic handling improvements and wider availability of proper
> address abstraction off of the physical interface.

How much support would there be for a policy proposal to exclude point
to point links as a justification for any global IP addresses
effective, say, 1/1/2012? Along with a stern recommendation from ARIN
to the routing vendors that they update their software to prevent the
non-availability of of addresses for point to point links from causing
malfunctions with ICMP warnings and errors?

You'd still be able to justify an IP address for the router, of
course, but you wouldn't be able to justify any addresses for the
individual point to point links, regardless of technology employed. So
you'd end up using unnumbered serial interfaces and RFC1918 addresses
on the point to point ethernets.

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 bill at herrin.us  Thu Jul 29 15:06:56 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 09:06:56 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <46D17940F4B3C84AB02E7D5BFC0588CC0EEE6AAA@EX2K7VS04.4emm.local>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<46D17940F4B3C84AB02E7D5BFC0588CC0EEE6AAA@EX2K7VS04.4emm.local>
Message-ID: <AANLkTinLJGkQRM0syxus3LRwuhCL9hQRD_jTtD0osDzn@mail.gmail.com>

On Thu, Jul 29, 2010 at 8:46 AM, David Divins <dsd at carpathiahost.com> wrote:
> I'm going to disagree on this one. ?I think /30's must be a valid
> use and I will let others explain (or explode) why 1918 on the
> ptop may be a bad idea.

Hi David,

Got any reasons that neither involve the generation of an ICMP
destination-unreachable message nor poor-man's circuit-up monitoring
via echo-request? I'm game to learn something new.

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 owen at delong.com  Thu Jul 29 15:18:17 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 12:18:17 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
Message-ID: <049ACABF-60BC-427A-9D42-A328F100C7A1@delong.com>


On Jul 29, 2010, at 11:34 AM, William Herrin wrote:

> On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon <jmaimon at chl.com> wrote:
>> William Herrin wrote:
>>> I don't think we even give 'em point to point links. For the last /8
>>> the vendors can damn well fix their code to originate ICMP from the
>>> loop0 address instead of the RFC1918 address on the interface.
>> 
>> I completely agree. That feature would be really lovely along with other
>> control plane traffic handling improvements and wider availability of proper
>> address abstraction off of the physical interface.
> 
> How much support would there be for a policy proposal to exclude point
> to point links as a justification for any global IP addresses
> effective, say, 1/1/2012? Along with a stern recommendation from ARIN
> to the routing vendors that they update their software to prevent the
> non-availability of of addresses for point to point links from causing
> malfunctions with ICMP warnings and errors?
> 
> You'd still be able to justify an IP address for the router, of
> course, but you wouldn't be able to justify any addresses for the
> individual point to point links, regardless of technology employed. So
> you'd end up using unnumbered serial interfaces and RFC1918 addresses
> on the point to point ethernets.
> 
I would oppose such a policy. There simply aren't enough point to point
links to add up to a meaningful number of addresses. To put this in
perspective, let's assume a moderate sized ISP which has a total
address span of roughly a /14 (262,144 addresses) has as many
as 1,000 point to point links. That's still 4,000/262,144 addresses
or 1.5% of their total address utilization.

The problems caused by such a policy would exceed any possible
address conservation achieved.

Owen



From owen at delong.com  Thu Jul 29 15:13:47 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 12:13:47 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
Message-ID: <AEFEF6E5-C3A5-4568-9BB9-05BDA135A435@delong.com>


On Jul 29, 2010, at 11:21 AM, William Herrin wrote:

> On Wed, Jul 28, 2010 at 6:09 PM, Owen DeLong <owen at delong.com> wrote:
>> Do you have any evidence that there are significant quantities of
>> non-legacy address space available to be reclaimed at the end of
>> an audit process? Even a basis for credible suspicion?
> 
> Hi Owen,
> 
> Didn't we hear an anecdote last week about someone who quit Verizon a
> decade ago but the addresses are still reassigned to them? Didn't one
> of the academics do a peer-reviewed study and a scan of the Internet
> last year with results suggesting (among other things) that about
> 2/3rds of the allocated address space is not employed on the public
> Internet?
> 
Not reachable by the methods employed in that study has nothing to
do with whether it is legitimately utilized or not. The problem is that
there are many many unreachable yet valid reasons to use IP address
space.

> Meaningful audits would be incredibly expensive and manpower
> intensive, no doubt about it. The odds of the POC for any given SWIP
> being correct, reachable, willing to talk and knowledgeable enough to
> confirm both their specific addresses and qualifications for that size
> of address bank is, well, not great. Working past that would be really
> hard. We could easily find that getting an accurate census requires
> sending someone into the field to knock on doors.
> 
Right.

> But let's not kid ourselves: there are plenty of credible reasons to
> believe there are lots of mislaid addresses waiting to be found. The
> question is whether finding them would be really expensive or
> impossibly expensive.
> 
I don't doubt that there are lots of mislaid addresses. I do doubt that
they are in meaningful chunks that can be recovered effectively.
I also think that the vast majority of them are legacy.

> 
> Even if expensive, I think there are a couple cases where thorough
> audits would serve the community well:
> 
> 1. Reports of fraud or undue carelessness. This should trigger a
> stochastic audit where a subset of the address space gets carefully
> checked to estimate the error rate. If the error rate looks high, give
> the registrant a chance to fix it and the do a new stochastic audit.
> If still high, proceed to a full audit.
> 
Absolutely... Obviously if you look at the draft policy I wrote for
required resource reviews as an expansion of NRPM section
12, you can see that I support doing auditing where it is reasonably
justified.

This one of the key reasons for a required resource review contained
in that draft policy.

> 2. Prior to receiving 4.10 addresses, the organization and its
> affiliates should complete a full audit, including their legacy
> address space. ARIN may or may not have any rights to an org's legacy
> address space, but we're certainly not obligated to give the org more
> addresses if it can't prove a cautious and thorough use of its
> existing addresses.
> 
Agreed. I'm happy to add a provision to 2010-11 that
specifies any application under NRPM 4.10 is subject to a
required resource review if there is community support to
do so. The fact that it isn't already in there was an oversight
on my part.

Owen



From jmaimon at chl.com  Thu Jul 29 15:52:08 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 29 Jul 2010 15:52:08 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
Message-ID: <4C51DBE8.9060108@chl.com>



William Herrin wrote:
>  On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon <jmaimon at chl.com> wrote:
> > William Herrin wrote:
> >> I don't think we even give 'em point to point links. For the last
> >> /8 the vendors can damn well fix their code to originate ICMP
> >> from the loop0 address instead of the RFC1918 address on the
> >> interface.
> >
> > I completely agree. That feature would be really lovely along with
> > other control plane traffic handling improvements and wider
> > availability of proper address abstraction off of the physical
> > interface.
>
>  How much support would there be for a policy proposal to exclude
>  point to point links as a justification for any global IP addresses
>  effective, say, 1/1/2012? Along with a stern recommendation from
>  ARIN to the routing vendors that they update their software to
>  prevent the non-availability of of addresses for point to point links
>  from causing malfunctions with ICMP warnings and errors?

I agree with your technical assessment. It is unnecessary and simply 
prevails currently as the path of least resistance due to vendors and 
operators inability to expend the extra effort to properly abstract 
address endpoints used in communication off of the physical interfaces 
used to route them.

 From expensive firewalls that cannot accept dial up vpn on a loopback 
to cheap CPE which cannot even do unnumbered serial, the list of who to 
blame is endless and covers all areas. ICMP generation is simply the 
excuse which sounds the most legitimate, as it will tend to cause 
violation of a common interpretation of  standards. Monitoring and 
visibility also rank up there. However, these can all be worked around, 
if the desire to do exists.

That ARIN should be explicitly restricting what is justified use other 
than generally basing acceptable justification activities that conform 
to prevailing normative practices is an idea I am not quite comfortable 
with. The reward would need to be worth the risk. I know of one specific 
utilization singled out, that of name based virtual hosting, but has 
there been any others?

Is it wise to continue to craft policy that engages and addresses 
specific behaviors? I would have to be overwhelmingly convinced on a 
case by case basis.

How much influence can ARIN actually expect to have on vendors and 
operators, either by advocacy or by policy? I suspect the answer is far 
less than we might hope.

Joe




From sethm at rollernet.us  Thu Jul 29 16:12:08 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 29 Jul 2010 13:12:08 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
 a	/30?
In-Reply-To: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
Message-ID: <4C51E098.1010709@rollernet.us>

On 7/29/2010 11:34, William Herrin wrote:
> On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon <jmaimon at chl.com> wrote:
>> William Herrin wrote:
>>> I don't think we even give 'em point to point links. For the last /8
>>> the vendors can damn well fix their code to originate ICMP from the
>>> loop0 address instead of the RFC1918 address on the interface.
>>
>> I completely agree. That feature would be really lovely along with other
>> control plane traffic handling improvements and wider availability of proper
>> address abstraction off of the physical interface.
> 
> How much support would there be for a policy proposal to exclude point
> to point links as a justification for any global IP addresses
> effective, say, 1/1/2012? Along with a stern recommendation from ARIN
> to the routing vendors that they update their software to prevent the
> non-availability of of addresses for point to point links from causing
> malfunctions with ICMP warnings and errors?
> 

None from me. I don't see how ARIN could ever influence a router vendor
to do anything. We're already having enough trouble as it is getting
IPv6 feature parity from those same vendors.

~Seth


From sethm at rollernet.us  Thu Jul 29 16:17:59 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 29 Jul 2010 13:17:59 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C51DBE8.9060108@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com>
Message-ID: <4C51E1F7.1000302@rollernet.us>

On 7/29/2010 12:52, Joe Maimon wrote:
> 
> I agree with your technical assessment. It is unnecessary and simply
> prevails currently as the path of least resistance due to vendors and
> operators inability to expend the extra effort to properly abstract
> address endpoints used in communication off of the physical interfaces
> used to route them.
> 
> From expensive firewalls that cannot accept dial up vpn on a loopback to
> cheap CPE which cannot even do unnumbered serial, the list of who to
> blame is endless and covers all areas. ICMP generation is simply the
> excuse which sounds the most legitimate, as it will tend to cause
> violation of a common interpretation of  standards. Monitoring and
> visibility also rank up there. However, these can all be worked around,
> if the desire to do exists.
> 
> That ARIN should be explicitly restricting what is justified use other
> than generally basing acceptable justification activities that conform
> to prevailing normative practices is an idea I am not quite comfortable
> with. The reward would need to be worth the risk. I know of one specific
> utilization singled out, that of name based virtual hosting, but has
> there been any others?
> 
> Is it wise to continue to craft policy that engages and addresses
> specific behaviors? I would have to be overwhelmingly convinced on a
> case by case basis.
> 

I believe it's counterproductive to spend more time coming up with more
workarounds for IPv4 while at the same time expecting that IPv6 adoption
is going to take hold. Let IPv4 go. As long as there are still people
working on making it last longer that's all the more reason for everyone
who hasn't started with IPv6 yet to keep putting it off.

~Seth


From marty at akamai.com  Thu Jul 29 16:26:57 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 29 Jul 2010 16:26:57 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C51E1F7.1000302@rollernet.us>
Message-ID: <C8775C51.B3FB%marty@akamai.com>




On 7/29/10 4:17 PM, "Seth Mattinen" <sethm at rollernet.us> wrote:

> On 7/29/2010 12:52, Joe Maimon wrote:
>> 


[ snip ]

>> 
> 
> I believe it's counterproductive to spend more time coming up with more
> workarounds for IPv4 while at the same time expecting that IPv6 adoption
> is going to take hold. Let IPv4 go. As long as there are still people
> working on making it last longer that's all the more reason for everyone
> who hasn't started with IPv6 yet to keep putting it off.
> 
> ~Seth


 s/adoption/transition/

If I understood Bill's original post, he wasn't implying that this would do
anything pre-depletion like extend the life of v4. He used a date of 1-2012
and depletion of the ARIN region will have already occurred.


Bill's idea could be useful along the lines of post depletion cost
mitigation.

Best,

-M< 



From jmaimon at chl.com  Thu Jul 29 16:30:45 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 29 Jul 2010 16:30:45 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C51E1F7.1000302@rollernet.us>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us>
Message-ID: <4C51E4F5.9090003@chl.com>



Seth Mattinen wrote:
>

>
> I believe it's counterproductive to spend more time coming up with more
> workarounds for IPv4 while at the same time expecting that IPv6 adoption
> is going to take hold.

If and only if, all the effort available and tasks required were 
confined to the participants of this conversation, only then would this 
point be valid. That was the case circa the ARPANET. It is no longer.

> Let IPv4 go.

It is up to the individual operators and network and customers and users 
to let it go. Not us, even for an expansive version of "us".

> As long as there are still people
> working on making it last longer that's all the more reason for everyone
> who hasn't started with IPv6 yet to keep putting it off.
>
> ~Seth

No. That is an irrational fear, based on zero sum game, assuming control 
and coordination that cannot ever be realized.

Not to mention that this statement is in and of itself quite damning of 
IPv6.

That it wont happen unless there is absolutely no choice? Is it really 
that bad? Why cant it win on its own merits?

Not a very nice picture.

Joe


From bill at herrin.us  Thu Jul 29 16:49:27 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 10:49:27 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <4C51DBE8.9060108@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<4C51DBE8.9060108@chl.com>
Message-ID: <AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>

On Thu, Jul 29, 2010 at 9:52 AM, Joe Maimon <jmaimon at chl.com> wrote:
> That ARIN should be explicitly restricting what is justified use other than
> generally basing acceptable justification activities that conform to
> prevailing normative practices is an idea I am not quite comfortable with.
> The reward would need to be worth the risk. I know of one specific
> utilization singled out, that of name based virtual hosting, but has there
> been any others?

Okay, so let's forget writing policy to this at the moment. Absent any
policy change, would anybody encourage/object to the ARIN board
issuing an open letter to the routing vendors to the effect of:

"As you know, we're running out of IPv4 addresses. To help mitigate
the shortage, we respectfully ask you to implement features in your
software which enable and encourage your customers to employ RFC1918
IP addresses within their routing infrastructure. Such features might
include:

icmp-response interface loopback0

Originate ICMP warnings and errors for packets received on this
interface using the IP address assigned to Loopback0.

ip address always-active

The IP address assigned to this interface is always reachable even if
the interface itself is down.

no suppress rfc1918 icmp

Do not automatically attempt to replace RFC1918 addresses in the
source of ICMP warnings and errors by replacing them with a globally
routable address found on another interface. Default is to replace so
that the error message isn't dropped at the AS border.
"

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 DPALMERO at DELTA.ORG  Thu Jul 29 17:03:59 2010
From: DPALMERO at DELTA.ORG (Dennis Palmero)
Date: Thu, 29 Jul 2010 14:03:59 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C51E4F5.9090003@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>
Message-ID: <719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>

>That it wont happen unless there is absolutely no choice? Is it really 
>that bad? Why cant it win on its own merits?

Wise words, indeed.

I think this is indicative of a wide rift between agreement that there
is a problem (IPv4 exhaustion) but disagreement on _accepting_ the
solution (IPv6).  We know that IPv6 is the best solution we have right
now, but issues, both real and perceived, with IPv6 adoption means that
IPv6's defenders can come off rather strongly in an effort to forestall
greater IP-exhaustion problems down the line.

I wish there would be an IPv7 that was IPv4 backwards-compatible and
solved many of IPv6's negative-perceptions, but we'll have to deal with
what we have, especially in the time crunch that we have.

Dennis





The information contained in this e-mail message and any attachments is confidential and intended only for the addressee(s). If you are not an addressee, you may not copy or disclose the information, or act upon it, and you should delete it entirely from your e-mail system. Please notify the sender that you received this e-mail in error.
  



From sethm at rollernet.us  Thu Jul 29 17:48:08 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 29 Jul 2010 14:48:08 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C51E4F5.9090003@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com>
Message-ID: <4C51F718.5020907@rollernet.us>

On 7/29/2010 13:30, Joe Maimon wrote:
> 
> No. That is an irrational fear, based on zero sum game, assuming control
> and coordination that cannot ever be realized.
> 
> Not to mention that this statement is in and of itself quite damning of
> IPv6.
> 
> That it wont happen unless there is absolutely no choice? Is it really
> that bad? Why cant it win on its own merits?
> 

Then why are we still worried about IPv4 consumption and crafting
policies to alter it in ever increasing micromanaging ways?

~Seth


From jdeckness at tctainc.net  Thu Jul 29 17:52:22 2010
From: jdeckness at tctainc.net (Jay Deckness)
Date: Thu, 29 Jul 2010 16:52:22 -0500
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
 IP Reassignment Registration Requirements
In-Reply-To: <4C49FC2F.5050206@arin.net>
References: <4C49FC2F.5050206@arin.net>
Message-ID: <6A0C363AE52B3D428B147D3DD84A8BB87E164972@TCTEX.MACC043.local>

I support this petition.

Justin Deckness, CCNA Certified.
Tri-County Telephone Association, Inc.
jdeckness at tctainc.net


-----Original Message-----
From: ARIN [mailto:info at arin.net]
Sent: Friday, July 23, 2010 3:32 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP Reassignment Registration Requirements

The message below started a petition regarding the ARIN Advisory Council's decision not to select "Policy Proposal 109. Standardize IP Reassignment Registration Requirements" as a draft policy at this time.
The AC's decision was posted by ARIN staff to PPML on 20 July 2010.

If successful, this petition will change Proposal 109 into a Draft Policy which will be published for adoption discussion on the PPML and at the Public Policy Meeting in October. If the petition fails, the proposal will remain on the AC's docket.

For this petition to be successful, the petition needs statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. Point of contact information is required, either to the entire PPML or with a follow up post to petition at arin.net with full POC information (name, organization, street address, email, phone).

The duration of the petition is until through five business days after the AC's draft meeting minutes are published. ARIN staff will post the result of the petition to PPML.

For more information on starting and participating in petitions, see PDP Petitions at:
https://www.arin.net/policy/pdp_petitions.html

The proposal text is below and at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


#####


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 1:51 PM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 -
> Standardize IP Reassignment Registration Requirements
>
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
>
> > The AC decided not to select Proposal 109 as a draft policy at this
> time:
> >
> > 109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
> sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
> both
> > IPv4 and IPv6, the distinction of residential customers, the
> utilization
> > requirements for subsequent allocations, and customer privacy are
> > all good topics, but agreement in some will be held up by any
> disagreements
> > on the others when trying to address them as one.
>
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
>
> If you support this petition, please send the following:
>
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
>
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
>
> --
>
> Author contact information:
>
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
>
> --
>
> Policy statement (v4):
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
>
> 2.12. Residential Customer
>
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
> text:
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
>
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.3. Residential Subscribers
>
> 4.2.3.7.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 4.2.3.7.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Reassignment information
>
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Market Area
>
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
>
> 6.5.5.3.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
> ## Resource Review ##
>
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
>
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
>
> --
>
> Rationale:
>
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information - Phone number, street address and abuse
> POC now required.
> 2) Residential Customer - Added "for personal use only" to the
> definition.
> 3) Registration (4.2.3.7 & 6.5.5) - Added "but not limited to" WRT
> assignment histories.
> 4) IPv6 - Requires all /64 and larger blocks to be registered.
> 5) Resource Review - Added this section.
>
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
>
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
>
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
>
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
>
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
>
>
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it's customers.
>
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
>
> --
>
> Thank you,
> ~Chris
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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 ras at e-gerbil.net  Thu Jul 29 17:45:01 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 29 Jul 2010 16:45:01 -0500
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com>
	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>
Message-ID: <20100729214501.GJ1946@gerbil.cluepon.net>

On Thu, Jul 29, 2010 at 10:49:27AM -1000, William Herrin wrote:
> 
> Okay, so let's forget writing policy to this at the moment. Absent any
> policy change, would anybody encourage/object to the ARIN board
> issuing an open letter to the routing vendors to the effect of:
> 
> "As you know, we're running out of IPv4 addresses. To help mitigate
> the shortage, we respectfully ask you to implement features in your
> software which enable and encourage your customers to employ RFC1918
> IP addresses within their routing infrastructure. Such features might
> include:
> 
> icmp-response interface loopback0
> 
> Originate ICMP warnings and errors for packets received on this
> interface using the IP address assigned to Loopback0.

There is this little tool out there called "traceroute", you might have 
heard of it. Some of us like it, as it helps keep the Internet running. 
Please don't encourage people to break it just to try and save a handful 
of IP addresses.

If you'd really like a broken Internet just send me your IP and I can 
null route it for you. That way you'll be happy, and we can still keep 
it working for everyone else too. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From sethm at rollernet.us  Thu Jul 29 18:06:04 2010
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 29 Jul 2010 15:06:04 -0700
Subject: [arin-ppml] Petition for discussion of policy proposal
 116	(Permitted Uses of Space Reserved Under NRPM 4.10)
In-Reply-To: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com>
Message-ID: <4C51FB4C.40301@rollernet.us>

On 7/20/2010 23:19, Owen DeLong wrote:
>> The AC abandoned the following proposal:
>>
>>  116. Permitted Uses of space reserved under NRPM 4.10
>>
>> The AC voted to abandon this proposal because of a lack of sufficient
>> support to accept it as draft policy. Several AC members felt it not
>> appropriate that ARIN policy dictate any specific architecture or method
>> a network should use to transition from v4 to v6.
> 
> This is my formal request to initiate a discussion petition of proposal 116.
> 


I support the petition of proposal 116. Space reserved for transitional
technologies should be used as such.

~Seth


From kloch at kl.net  Thu Jul 29 18:27:23 2010
From: kloch at kl.net (Kevin Loch)
Date: Thu, 29 Jul 2010 18:27:23 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us>	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
Message-ID: <4C52004B.40708@kl.net>

Dennis Palmero wrote:
>
> I wish there would be an IPv7 that was IPv4 backwards-compatible and
> solved many of IPv6's negative-perceptions, but we'll have to deal with
> what we have, especially in the time crunch that we have.

One way to "deal" with it would be to get the basic functionality
we have with IPv4 like vrrp and dhcp that do not require Router
Advertisements. That will have to come from the vendors, the IETF seems
to consider RA a religion to be protected at all cost, against all
operator input.

- Kevin


From owen at delong.com  Thu Jul 29 18:37:08 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 15:37:08 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <4C51E4F5.9090003@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com>
Message-ID: <407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com>


On Jul 29, 2010, at 1:30 PM, Joe Maimon wrote:

> 
> 
> Seth Mattinen wrote:
>> 
> 
>> 
>> I believe it's counterproductive to spend more time coming up with more
>> workarounds for IPv4 while at the same time expecting that IPv6 adoption
>> is going to take hold.
> 
> If and only if, all the effort available and tasks required were confined to the participants of this conversation, only then would this point be valid. That was the case circa the ARPANET. It is no longer.
> 
Not entirely true.

>> Let IPv4 go.
> 
> It is up to the individual operators and network and customers and users to let it go. Not us, even for an expansive version of "us".
> 
It is up to the members of ARIN to choose how ARIN staff spends staff time and member money.

As such, I do not want to see significant ARIN resources dedicated to reclamation. I support auditing
where it is warranted as suggested in NRPM 12 and in 2010-11. So much so that I was a contributing
author of NRPM-12 and am the author of 2010-11. However, this has to do with ongoing operations
and stewardship of active address space. It is not intended as a concerted effort to reclaim under-
utilized IPv4 space.

Reclamation is a rathole that will consume vast amounts of staff time and ARIN money without
significant gain for the community at the end. If you want to fund your own personal "Give your
space back to ARIN" campaign and gather volunteers to help you and contributors to help
fund it, more power to you. If you want to divert ARIN resources to such a thing, then, I, and
the two ARIN member organizations for which I am a DMR are opposed to that.

Owen



From owen at delong.com  Thu Jul 29 18:44:51 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 15:44:51 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
Message-ID: <89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>


On Jul 29, 2010, at 2:03 PM, Dennis Palmero wrote:

>> That it wont happen unless there is absolutely no choice? Is it really 
>> that bad? Why cant it win on its own merits?
> 
> Wise words, indeed.
> 
> I think this is indicative of a wide rift between agreement that there
> is a problem (IPv4 exhaustion) but disagreement on _accepting_ the
> solution (IPv6).  We know that IPv6 is the best solution we have right
> now, but issues, both real and perceived, with IPv6 adoption means that
> IPv6's defenders can come off rather strongly in an effort to forestall
> greater IP-exhaustion problems down the line.
> 
> I wish there would be an IPv7 that was IPv4 backwards-compatible and
> solved many of IPv6's negative-perceptions, but we'll have to deal with
> what we have, especially in the time crunch that we have.
> 
Try this mental exercise...

Express a 128 bit number in 32 bits such that all possible 128 bit values
are uniquely expressed in the 32 bit field.

If you solve this problem, please contact me, I'm sure we can make money
from your solution.

If you cannot solve this problem, then please understand that there is no
way to have a host which expects everything to be a 32 bit value be
forwards compatible with a 128 bit world.

It's time to move forward. IPv6 is the best solution we have today, and,
today is the day. Yesterday would have been better. Last year better
still. Tomorrow is worse. Next year will be MUCH worse.

We're out of time. IPv4 runout is now truly approaching rapidly.

We're less than a year from runout. Even if you had a perfect new
protocol in a standards-track RFC with full consensus today, you
couldn't get it into enough routers to have it fully deployed in time.
IPv6 is what we have. It is the solution we need to accept. We don't
have any workable alternatives. (NAT-PT, and other v6<->v4
hacks are not sustainable nor can they provide equivalent levels
of service to even current IPv4 with NAT, let alone proper internet
access).

Owen

> Dennis
> 
> 
> 
> 
> 
> The information contained in this e-mail message and any attachments is confidential and intended only for the addressee(s). If you are not an addressee, you may not copy or disclose the information, or act upon it, and you should delete it entirely from your e-mail system. Please notify the sender that you received this e-mail in error.
> 
> 
> _______________________________________________
> 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 mysidia at gmail.com  Thu Jul 29 19:03:12 2010
From: mysidia at gmail.com (James Hess)
Date: Thu, 29 Jul 2010 18:03:12 -0500
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTinLJGkQRM0syxus3LRwuhCL9hQRD_jTtD0osDzn@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<46D17940F4B3C84AB02E7D5BFC0588CC0EEE6AAA@EX2K7VS04.4emm.local>
	<AANLkTinLJGkQRM0syxus3LRwuhCL9hQRD_jTtD0osDzn@mail.gmail.com>
Message-ID: <AANLkTi=6Uff8bvsdEshdFn8mJNjm+D1X4jo8owVeHrzF@mail.gmail.com>

On Thu, Jul 29, 2010 at 2:06 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Jul 29, 2010 at 8:46 AM, David Divins <dsd at carpathiahost.com> wrote:
[snip> Hi David,
> Got any reasons that neither involve the generation of an ICMP
> destination-unreachable message nor poor-man's circuit-up monitoring
> via echo-request? I'm game to learn something new.

Those reasons may be annoying, but they are still very good reasons.
Use of  echo-request for circuit monitoring and troubleshooting is
also more reliable than other techniques, in certain situations.
It allows the ISP subscriber to get useful traceroute information, and
check their WAN up/down status,  and get some limited idea of
latency/performance, without  being granted access to the ISP's
equipment.

This is particularly relevant if an end user has multiple links
attached to a router, for redundancy.   A simple ping test to upstream
routers will not be able to tell the subscriber that both links  are
fully operational or not,  they  need   numbered  WAN addresses,  to
determine that using ping tests.


ARIN should be careful and judicious and avoid mandating new
technology requirements that could have unforseen negative effects,
or  force organizations into technical problems and expensive upgrades
or process changes,   OR force them into a situation where their
technical requirements  or agreements with their customers cannot be
met  due to IP addressing policy,
unless absolutely necessary, or at least meaningfully  beneficial...


I would be in favor of this  being considered.... if it could
meaningfully delay exhaustion,  or allow a meaningfully larger number
of IP addresses to be allocated in practice.  However,   I don't think
there are enough IP addresses justified as /30s  for point to point
links to put even a small dent  in  IPv4  address consumption.

Does ARIN  have any data that could be provided regarding how many  IP
addresses justified by  members  are  reported  as  /30s  for  point
to point links,   Versus  IP addresses justified for other purposes ?

--
-JH


From jmaimon at chl.com  Thu Jul 29 20:22:09 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 29 Jul 2010 20:22:09 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com>
	<407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com>
Message-ID: <4C521B31.7060303@chl.com>



Owen DeLong wrote:
> On Jul 29, 2010, at 1:30 PM, Joe Maimon wrote:
>    
>> It is up to the individual operators and network and customers and users to let it go. Not us, even for an expansive version of "us".
>>
>>      
> It is up to the members of ARIN to choose how ARIN staff spends staff time and member money.
>
> As such, I do not want to see significant ARIN resources dedicated to reclamation. I support auditing
> where it is warranted as suggested in NRPM 12 and in 2010-11. So much so that I was a contributing
> author of NRPM-12 and am the author of 2010-11. However, this has to do with ongoing operations
> and stewardship of active address space. It is not intended as a concerted effort to reclaim under-
> utilized IPv4 space.
>
> Reclamation is a rathole that will consume vast amounts of staff time and ARIN money without
> significant gain for the community at the end. If you want to fund your own personal "Give your
> space back to ARIN" campaign and gather volunteers to help you and contributors to help
> fund it, more power to you. If you want to divert ARIN resources to such a thing, then, I, and
> the two ARIN member organizations for which I am a DMR are opposed to that.
>
> Owen
>
>    

I am opposed to reclamation techniques that step up the confrontational 
and adversarial relationship between ARIN and address holders, even were 
it to be essential for continued consumption of IPv4 and IPv6 did not 
exist. I view increasing auditing and mandatory triggers of audits with 
similar concern.

Expending good will and buy in, not to mention financial resources, all 
for relatively limited return along with greater risks of legal and 
political liabilities is not a good bargain.

Bad cop is not a character role an organization like ARIN should choose 
to be identified with.

Incentives for efficiencies, that is where my support lands. Even then,  
I prefer less direct incentives, those that can be spread and carried by 
the invisible hand.

I would support ARIN advocacy for technical standards and features that 
were mindful of IPv4 scarcity. I would also support advocacy for 
technical standards and features that would help smooth migration and 
transition to IPv6. I believe ARIN does have a role to play there and 
not just a passive one. Let them be a voice of the addressing community, 
a liaison, to help focus on those concerns in many an arena.

Joe


From jmaimon at chl.com  Thu Jul 29 20:30:37 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 29 Jul 2010 20:30:37 -0400
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <20100729214501.GJ1946@gerbil.cluepon.net>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>
	<20100729214501.GJ1946@gerbil.cluepon.net>
Message-ID: <4C521D2D.5020404@chl.com>



Richard A Steenbergen wrote:
> On Thu, Jul 29, 2010 at 10:49:27AM -1000, William Herrin wrote:
>>
>> Okay, so let's forget writing policy to this at the moment. Absent any
>> policy change, would anybody encourage/object to the ARIN board
>> issuing an open letter to the routing vendors to the effect of:
>>
>> "As you know, we're running out of IPv4 addresses. To help mitigate
>> the shortage, we respectfully ask you to implement features in your
>> software which enable and encourage your customers to employ RFC1918
>> IP addresses within their routing infrastructure. Such features might
>> include:
>>
>> icmp-response interface loopback0
>>
>> Originate ICMP warnings and errors for packets received on this
>> interface using the IP address assigned to Loopback0.
>
> There is this little tool out there called "traceroute", you might have
> heard of it. Some of us like it, as it helps keep the Internet running.
> Please don't encourage people to break it just to try and save a handful
> of IP addresses.
>
> If you'd really like a broken Internet just send me your IP and I can
> null route it for you. That way you'll be happy, and we can still keep
> it working for everyone else too. :)
>

Right now there is many a network you cant traceroute through at all due 
to their use of local scope addressing.

For those networks a feature such as this one would be a nice improvement.

Conceivably, the network could be able to view traceroutes across their 
own network unmasked.

The truth of that matter, that while hardly convenient and scalable in 
any but the smallest of implementations, control plane or border nat 
translation achieves the exact same results as the proposed feature.

I dont believe the results of a proper implementation of this feature 
must be as drastic as you paint them.

Joe


From bill at herrin.us  Thu Jul 29 22:04:42 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 16:04:42 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <20100729214501.GJ1946@gerbil.cluepon.net>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<4C51DBE8.9060108@chl.com>
	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com> 
	<20100729214501.GJ1946@gerbil.cluepon.net>
Message-ID: <AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com>

On Thu, Jul 29, 2010 at 11:45 AM, Richard A Steenbergen
<ras at e-gerbil.net> wrote:
> On Thu, Jul 29, 2010 at 10:49:27AM -1000, William Herrin wrote:
>>
>> Okay, so let's forget writing policy to this at the moment. Absent any
>> policy change, would anybody encourage/object to the ARIN board
>> issuing an open letter to the routing vendors to the effect of:
>>
>> "As you know, we're running out of IPv4 addresses. To help mitigate
>> the shortage, we respectfully ask you to implement features in your
>> software which enable and encourage your customers to employ RFC1918
>> IP addresses within their routing infrastructure. Such features might
>> include:
>>
>> icmp-response interface loopback0
>>
>> Originate ICMP warnings and errors for packets received on this
>> interface using the IP address assigned to Loopback0.
>
> There is this little tool out there called "traceroute", you might have
> heard of it. Some of us like it, as it helps keep the Internet running.
> Please don't encourage people to break it just to try and save a handful
> of IP addresses.

Hi Richard,

One of us misunderstands the situation. Let's back up and talk about
how traceroute works, the character of the problem encountered when
traceroutes are attempted via routers configured with RFC1918
addresses and how the proposed technology attempts to address the
problem.

Briefly, traceroute works by sending packets with the TTL byte in the
IP header intentionally set too low to reach the destination. This
byte is decremented by each router the packet passes through. When it
hits zero, the router is not allowed to pass it on. It must instead
respond with an ICMP type 11 packet - time exceeded.  So, it builds an
ICMP packet using the original packet's source as the ICMP packet's
destination and using the router's interface address on which the
offending packet was received as the source address. It appends as
much of the original packet as it wants to (at least 64 bytes worth if
I remember right. Might have been 56). And then it sends this new
packet on back to the source of the too-short TTL packet.

When the traceroute program receives this type 11 ICMP message, it
matches the packet it sent with the one included in the ICMP message
and notes that the router which sent the packet is so-many hops away.
So, in a nutshell, that's how traceroute works.

Traceroute works exactly the same way when one of the routers is
configured with RFC1918 addresses, but there's a hitch: at many system
borders, packets containing an RFC1918 source address (such as the
ICMP message the router constructed) are firewalled - not allowed to
pass. They're only legitimate source addresses within the system, not
beyond it. As a result, the ICMP packet never makes it back to the
traceroute program and you see three slow stars.

Under the hood there's actually a much more serious problem - ICMP
type 3 messages (destination unreachable) also don't make it back. TCP
needs ICMP type 3 code 4 messages (fragmentation needed) to work
properly, so you unexpectedly find yourself unable to pass data with
HTTP and SMTP over paths that include that router. You drop your MTU
to 1400 and viola, the problem magically disappears because the
packets are now small enough to get past that router.


Now, let's talk about how "icmp-response interface loopback0"
addresses this problem. The basic idea is this: you configure
interface loopback0 with a global IP address (e.g. 199.33.225.1). Then
you configure your interfaces with RFC1918 addresses (e.g.
192.168.100.125/30). Now, the router receives a packet with a TTL of 0
(from a traceroute). Ordinarily, it would construct the ICMP message
with a source address of 192.168.100.125. That would get blocked by
the firewall. But this router is programmed with "icmp-response
interface loopback0" so instead of using the interface address it
originates the ICMP packet from loop0's address: 199.33.225.1. The
ICMP packet with a soruce address of 199.33.225.1 makes it all the way
back to you since it's a legitimate source address for that network
and you see a router hop at 199.33.225.1, a legitimate global address
for that router.

All without burning global addresses on each separate point to point
interface on the router.

See how that works?

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  Thu Jul 29 22:22:07 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 16:22:07 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us> 
	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
	<89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
Message-ID: <AANLkTimqGFZT8awch4ADrJd8UBBZq4kJ4cN05WoH_s=N@mail.gmail.com>

On Thu, Jul 29, 2010 at 12:44 PM, Owen DeLong <owen at delong.com> wrote:
> Express a 128 bit number in 32 bits such that all possible 128 bit values
> are uniquely expressed in the 32 bit field.

Hi Owen,

It's been discussed. It was called something like "aggregation with
increasing scope." The basic idea works like "loose source routing."
The first address in the path is the anycast top-level waypoint for
the destination system, followed by additional waypoints until you
enter the final scope. The DNS for this returns a list of 32-bit
values as the address instead of a single 32-bit or single 128-bit
value.

One of the nice features is how easily it expands and contracts. If
you need more addresses inside your system, you just add one level of
scope and presto, you have 4 billion more addresses to play with, no
registry fuss required.

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 ras at e-gerbil.net  Thu Jul 29 22:25:33 2010
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 29 Jul 2010 21:25:33 -0500
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com>
	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>
	<20100729214501.GJ1946@gerbil.cluepon.net>
	<AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com>
Message-ID: <20100730022533.GP1946@gerbil.cluepon.net>

On Thu, Jul 29, 2010 at 04:04:42PM -1000, William Herrin wrote:
> 
> Hi Richard,
> 
> One of us misunderstands the situation. Let's back up and talk about
> how traceroute works, the character of the problem encountered when
> traceroutes are attempted via routers configured with RFC1918
> addresses and how the proposed technology attempts to address the
> problem.

William,

Rest assured I know exactly how traceroute works. :)

Sourcing the ICMP messages from a real loopback IP solves the problem of 
unreachables not making it back to the host due to filtering, but it 
still completely disrupts traceroute as a diagnostic tool. There is a 
lot more to troubleshooting a network than knowing the packet went from 
router A to router B, which is all you'd be left with if you sourced 
your icmps from a loopback.

For more information on how network operators use traceroute to 
troubleshoot real issues, take a look at:

http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From bill at herrin.us  Thu Jul 29 22:48:33 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 16:48:33 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <20100730022533.GP1946@gerbil.cluepon.net>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<4C51DBE8.9060108@chl.com>
	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com> 
	<20100729214501.GJ1946@gerbil.cluepon.net>
	<AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com> 
	<20100730022533.GP1946@gerbil.cluepon.net>
Message-ID: <AANLkTikKoWaPdeyrPwo9Ctorp3D_A8BTwR__uztHZY+5@mail.gmail.com>

On Thu, Jul 29, 2010 at 4:25 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
> Rest assured I know exactly how traceroute works. :)
>
> Sourcing the ICMP messages from a real loopback IP solves the problem of
> unreachables not making it back to the host due to filtering, but it
> still completely disrupts traceroute as a diagnostic tool. There is a
> lot more to troubleshooting a network than knowing the packet went from
> router A to router B, which is all you'd be left with if you sourced
> your icmps from a loopback.
>
> For more information on how network operators use traceroute to
> troubleshoot real issues, take a look at:
> http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf

Hi Richard,

I notice that your "factoid" on slide 10 that obeying RFC 1812 changed
from "would prevent traceroute from working properly" in your earlier
presentation to "would completely change traceroute results." The
latter observation is correct though the "completely" still overstates
the case.

The use of any number of technologies changes what traceroute tells
you. I'm sure you've seen the MPLS networks that show only two hops
revealing no internal information. The more and more frequently
employed tunnels and VPNs affect traceroute's function. And traceroute
never could tell you that the set of switches between two routers was
acting up.

This too would change what traceroute tells you. But at least it would
tell you something, which is often more than you get now when a router
is configured with RFC 1918 addresses.

Like your presentation by the way. Very thorough. Especially the
points about latency and asymmetric paths; so many folks don't get
that.

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  Thu Jul 29 23:02:25 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 29 Jul 2010 17:02:25 -1000
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTi=6Uff8bvsdEshdFn8mJNjm+D1X4jo8owVeHrzF@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com> 
	<46D17940F4B3C84AB02E7D5BFC0588CC0EEE6AAA@EX2K7VS04.4emm.local> 
	<AANLkTinLJGkQRM0syxus3LRwuhCL9hQRD_jTtD0osDzn@mail.gmail.com> 
	<AANLkTi=6Uff8bvsdEshdFn8mJNjm+D1X4jo8owVeHrzF@mail.gmail.com>
Message-ID: <AANLkTi=6ZChLW_iYXnuVoohiuuE2LiGr_v6e8oG9iSDg@mail.gmail.com>

On Thu, Jul 29, 2010 at 1:03 PM, James Hess <mysidia at gmail.com> wrote:
> Use of ?echo-request for circuit monitoring and troubleshooting is
> also more reliable than other techniques, in certain situations.
> It allows the ISP subscriber to get useful traceroute information, and
> check their WAN up/down status, ?and get some limited idea of
> latency/performance, without ?being granted access to the ISP's
> equipment.

Hi James,

I use that very technique in one of my systems. Except for the one
unnumbered link. For that one, I static route the upstream hop's IP
address and prevent it from transiting the other links. Accomplishes
exactly the same thing without burning addresses on the point to
point.

Always another way and rarely hard to find.


> ARIN should be careful and judicious and avoid mandating new
> technology requirements that could have unforseen negative effects,

Hear you loud and clear. How about instead encouraging address-saving
technology improvements short of mandating them, and then waiting to
see what folks decide for themselves about whether the improvements
are good enough to use?

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  Fri Jul 30 01:01:40 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 22:01:40 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTimqGFZT8awch4ADrJd8UBBZq4kJ4cN05WoH_s=N@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
	<89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
	<AANLkTimqGFZT8awch4ADrJd8UBBZq4kJ4cN05WoH_s=N@mail.gmail.com>
Message-ID: <AF8B8D67-A724-405B-A8F9-348EE51DB3AB@delong.com>


On Jul 29, 2010, at 7:22 PM, William Herrin wrote:

> On Thu, Jul 29, 2010 at 12:44 PM, Owen DeLong <owen at delong.com> wrote:
>> Express a 128 bit number in 32 bits such that all possible 128 bit values
>> are uniquely expressed in the 32 bit field.
> 
> Hi Owen,
> 
> It's been discussed. It was called something like "aggregation with
> increasing scope." The basic idea works like "loose source routing."
> The first address in the path is the anycast top-level waypoint for
> the destination system, followed by additional waypoints until you
> enter the final scope. The DNS for this returns a list of 32-bit
> values as the address instead of a single 32-bit or single 128-bit
> value.
> 
Right... Now, how does an un-upgraded IPv4 only host with no code
changes take advantage of this and start sending packets to IPv6-only
hosts in other scopes?

> One of the nice features is how easily it expands and contracts. If
> you need more addresses inside your system, you just add one level of
> scope and presto, you have 4 billion more addresses to play with, no
> registry fuss required.
> 
Right.. A rather pathological form of variable length addressing.  However,
not really a solution to the stated problem. Merely an obfuscation that
moves the problem around until you can pretend it is invisible. However,
without changing the code on the originating machine, it still doesn't
actually work.

Owen



From owen at delong.com  Fri Jul 30 00:58:40 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 29 Jul 2010 21:58:40 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
	a /30?
In-Reply-To: <AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com>
	<AANLkTi=DfaZcmH1KWAN6uJmQ-k2HaLaMmrbrKt_uwwET@mail.gmail.com>
	<20100729214501.GJ1946@gerbil.cluepon.net>
	<AANLkTimddhY1cKNXz0AB62Ssy9jhFGxZNod0P4+DAy5S@mail.gmail.com>
Message-ID: <FCD23ACD-6092-44F0-89BB-A6DECB44FA42@delong.com>


On Jul 29, 2010, at 7:04 PM, William Herrin wrote:

> On Thu, Jul 29, 2010 at 11:45 AM, Richard A Steenbergen
> <ras at e-gerbil.net> wrote:
>> On Thu, Jul 29, 2010 at 10:49:27AM -1000, William Herrin wrote:
>>> 
>>> Okay, so let's forget writing policy to this at the moment. Absent any
>>> policy change, would anybody encourage/object to the ARIN board
>>> issuing an open letter to the routing vendors to the effect of:
>>> 
>>> "As you know, we're running out of IPv4 addresses. To help mitigate
>>> the shortage, we respectfully ask you to implement features in your
>>> software which enable and encourage your customers to employ RFC1918
>>> IP addresses within their routing infrastructure. Such features might
>>> include:
>>> 
>>> icmp-response interface loopback0
>>> 
>>> Originate ICMP warnings and errors for packets received on this
>>> interface using the IP address assigned to Loopback0.
>> 
>> There is this little tool out there called "traceroute", you might have
>> heard of it. Some of us like it, as it helps keep the Internet running.
>> Please don't encourage people to break it just to try and save a handful
>> of IP addresses.
> 
> Hi Richard,
> 
> One of us misunderstands the situation. Let's back up and talk about
> how traceroute works, the character of the problem encountered when
> traceroutes are attempted via routers configured with RFC1918
> addresses and how the proposed technology attempts to address the
> problem.
> 
Actually, I have had to debug a number of problems where not getting
a link-specific address back in a traceroute is quite the opposite of
helpful. Often when one is troubleshooting with traceroute, you need
to know not only which router was responsible for a particular hop, but,
on which interface the packets entered said router. Parallel paths between
two routers are but one example where this could matter.

As such, I'd argue that Richard is the one who better understands the
situation.

Owen




From andrew.dul at quark.net  Fri Jul 30 01:18:42 2010
From: andrew.dul at quark.net (Andrew Dul)
Date: Thu, 29 Jul 2010 22:18:42 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <C8736CFE.A81C%marty@akamai.com>
References: <C8736CFE.A81C%marty@akamai.com>
Message-ID: <4C5260B2.3070803@quark.net>

 Has anyone considered that maybe what we should do is just reserve the
block for future use and not try to predict the future too much at this
point and instead comeback after IPv4 exhaustion and then write an
appropriate policy.  Yes this does kick the ball down the field, but it
also allows the ability to have space to work with in the future to use
for an appropriate use after IPv4 run-out.

Andrew

On 7/26/2010 1:49 PM, Hannigan, Martin wrote:
>
>
> And a minor correction please. I meant proposal 116 v. 109 when I
> referenced it.
>
>
> On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:
>
>     Owen,
>
>     So do you feel that this is bad all around or just the minimum
>     allocation unit needs to be changed to something smaller?  Others
>     out there?  What are your thoughts regarding a minimum/maximum
>     allocation size for this last /8?  
>
>     ----Cathy
>
>     On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
>
>         Marty,
>                 How do you expect anyone but the largest of the large
>         and extra large
>         organizations to qualify for a /20 of IPv4 space under this
>         proposal?
>
>                 This is a really interesting way to attempt to reserve
>         the last /8 for use
>         only by the largest organizations ARIN serves, but, I really
>         don't think that
>         is good policy.
>
>         Owen
>
>         On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:
>
>         >
>         >
>         > Hello PPML:
>         >
>         >
>         > Since it seemed to have been very helpful to vet the global
>         policy idea on
>         > the list, I thought it might be helpful to use it to frame my
>         non-support
>         > for 109. This is, just like the last time, very raw, but I
>         expect to solicit
>         > some time during open policy hour to discuss a more polished
>         version.
>         >
>         > A few points.
>         >
>         > - This idea takes us in the direction of actual transition
>         > - Define an acceptable use list
>         > - Seeks to address COSTS
>         > - Levels the playing field between small and large
>         > - Reserves an entire /8 for transition, not for business as usual
>         > - Counters the high priced "market" that is emerging by
>         deferring it's need
>         >
>         > May not get us all the way through, but every month that we
>         can avoid
>         > sending people to markets is a month of reduced costs IMHO.
>         And it is about
>         > costs at this point. It's a given that it is going to happen.
>         >
>         > Too soon for "for" or "against", but most definitely open to
>         feedback. Don't
>         > focus on the words, focus on the ideas. Feedback very much
>         appreciated.
>         >
>         >
>         > --draft, group working comments removed for ease of read
>         >
>         > 1. Transition Pool
>         >
>         > ARIN will set-aside the final /8 allocated form the IANA to
>         facilitate
>         > transition from IPv4 to IPv6. The resulting "transition pool"
>         will become
>         > immediately available for allocations under this policy. This
>         pool will be
>         > known as the "transition pool".
>         >
>         > 2. Minimum and Maximum Allocation Unit
>         >
>         > The minimum allocation unit will be a /20. The maximum
>         allocation unit will
>         > be /15.
>         >
>         > 2. Allocation Method
>         >
>         > ARIN will determine and utilize the best method possible for
>         allocations
>         > with the goal of maximizing what can be allocated balanced by
>         minimum
>         > deaggregation.
>         >
>         > 3. Eligibility
>         >
>         > An applicant will become eligible to receive IPv4 addresses
>         from this pool
>         > when they meet the following requirements:
>         >
>         > 1. Applicant will provide a written plan detailing how the
>         addresses will be
>         > used and on what devices.
>         >
>         > 2. Previous allocations or assignments under this policy must
>         continue to
>         > meet the justification requirements of this policy.
>         >
>         > 3. Must have applied for, been approved, received and be
>         utilizing an ARIN
>         > allocated IPv6 allocation or assignment.
>         >
>         > 4. All allocations or assignments made under this policy must
>         be efficiently
>         > utilized to a rate of 80%.
>         >
>         > 5. Applicant must demonstrate that no other allocations or
>         assignments that
>         > they have received will meet their requirements.
>         >
>         > 6. Applicants must provide documentation that demonstrates
>         that the
>         > addresses received under this policy will be used only on
>         dual stack devices
>         > that will have both an IPv4 and IPv6 address that will both
>         be reachable
>         > natively.
>         >
>         > 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>         >
>         >
>         > 4. Acceptable Use of Addresses
>         >
>         > 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT
>         gateways for each
>         > each layer 3 contagious v6 only customer networks thereby
>         enabling IPv4
>         > connectivity for an IPv6-only customer networks. Customers
>         must not have
>         > available IPv4 addresses.
>         >
>         > 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT
>         gateways for each
>         > each layer 3 contagious v6 customer networks to deploy IPv4
>         RFC-1918 in
>         > addition to (and NOT instead of) IPv6 thereby enabling IPv4
>         connectivity for
>         > an IPv6-only customer networks.. Customers must not have
>         available IPv4
>         > addresses.
>         >
>         > 3. Customer networks qualifying under 4.1 or 4.2 (above) may
>         qualify for
>         > additional IPv4 address to meet multi-homing traffic
>         engineering needs or to
>         > address stand-alone NAT devices as specified below:
>         >
>         > A. A single IPv4 /32 for each interconnect for each
>         mult-homed layer 3
>         > contiguous customer network that requires traffic
>         engineering. For example a
>         > network with two interconnects to a single upstream provider
>         can get one
>         > IPv4 /32 for each of their two interconnects, and distribute
>         their internal
>         > hosts between the two outside NAT addresses for traffic
>         engineering.
>         >
>         > B. Customer networks that require stand-alone NAT devices
>         (not integrated
>         > into their CPE router) qualify for enough IPv4 addresses to
>         number the
>         > loopback addresses (if needed) for all edge routers that have
>         one or more
>         > connections to a transit provider, enough IPv4 addresses to
>         number each of
>         > the point-to-point links between those routers and their
>         transit provider,
>         > as well as the point to point links between those routers and
>         directly
>         > connected NAT appliances. As well as one IPv4 address for
>         each of these
>         > directly connected NAT appliances.
>         >
>         >
>         > 4. Loopback addresses for edge routers that have one or more
>         connections to
>         > transit providers and/or peers
>         >
>         > 5. Address for point to point links between edge routers and
>         their transit
>         > providers [why does it need to be unique v. 1918?] [that is
>         an interesting
>         > point... We use globally unique as a matter of not breaking
>         routing by
>         > accident. I have to think about if it would be generally
>         acceptable to use
>         > RFC-1918. Interesting question!]
>         >
>         > 7. A /32 for routers in a greenfield network that are dual
>         stacked.
>         > [redundant to 3/5?] [this is not redundant... In this case I
>         need an IPv4
>         > routerID to make BGP work. If I want to be a green-filed IPv6
>         transit
>         > provider I need one IPv4 address for each router]
>         >
>         > 8. /32 for public facing name servers, NTP servers, SMTP
>         servers and Web
>         > servers which are dual stacked and reachable on IPv4 and IPv6
>         networks.
>         >
>         > 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per
>         VPN aggregator
>         >
>         >
>         > 5. Reservation Forecasting
>         >
>         > An applicant may provide ARIN with a thirty-month forecast of
>         IPv4 address
>         > need. ARIN will reserve the requested size in compliance with
>         Section 2 and
>         > 3. When a reservation forecast is approved by ARIN, the
>         applicant will then
>         > be authorized to draw down from the forecast quarterly. Prior
>         to requesting
>         > reserved addresses, applicant will provide documentation to
>         ARIN that they
>         > have maintained utilization requirements for previous
>         allocation. If
>         > applicant fails to meet utilization requirements for two
>         consecutive
>         > quarters, ARIN will cancel the reservation and return unused
>         addresses to
>         > the pool.
>         >
>         >
>         > Example:
>         >
>         > Applicant applies to ARIN under this policy and submits a
>         thirty-month
>         > forecast requesting a /16. Using criteria established in the
>         NRPM and this
>         > policy, ARIN will determine if applicant is eligible and has
>         need. If the
>         > applicant meets the requirements for the allocation, they
>         will reserve a
>         > /16. The applicant will then be allocated 3/30th of the
>         forecasted
>         > requirement in a CIDR block or equivalent number of IPv4
>         addresses. ARIN
>         > will round down allocations or assignments to the closest
>         CIDR single block.
>         > Rounding errors will be applied to the last allocation of the
>         last quarter
>         > of the thirty month period and allocated then.
>         >
>         >
>         > 6. Dual Stack Requirement
>         >
>         > Addresses from this pool may only be used on dual stack
>         devices that are to
>         > be reachable via both IPv4 and IPv6 networks.
>         >
>         >
>         > 7. Application Frequency
>         >
>         > Applicants may apply for address space from the transition
>         pool once per
>         > quarter. If an applicant has an existing thirty-month
>         forecast that has been
>         > approved by ARIN, they are ineligible to apply for more
>         address space until
>         > their reservation has been exhausted. If an applicant has had
>         a reservation
>         > cancelled due to policy compliance issues including
>         utilization, they are
>         > not eligble to apply for addresses.
>         >
>         >
>         > 8. Post Exhaustion Refresh
>         >> From the point of the issuance of the final /8 from the
>         IANA, ARIN will
>         > dispose of all address space that it may receive using this
>         policy.
>         >
>         > _______________________________________________
>         > 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100729/a01f6d8b/attachment.htm>

From scottleibrand at gmail.com  Fri Jul 30 01:28:28 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 29 Jul 2010 22:28:28 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C5260B2.3070803@quark.net>
References: <C8736CFE.A81C%marty@akamai.com> <4C5260B2.3070803@quark.net>
Message-ID: <59AEFE98-8AE3-4D27-BFC5-226372E67648@gmail.com>

Joe proposed that for the whole /8, and it didn't get much support. How big a block were you thinking?

-Scott

On Jul 29, 2010, at 10:18 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> Has anyone considered that maybe what we should do is just reserve the block for future use and not try to predict the future too much at this point and instead comeback after IPv4 exhaustion and then write an appropriate policy.  Yes this does kick the ball down the field, but it also allows the ability to have space to work with in the future to use for an appropriate use after IPv4 run-out.
> 
> Andrew 
> 
> On 7/26/2010 1:49 PM, Hannigan, Martin wrote:
>> 
>> 
>> 
>> And a minor correction please. I meant proposal 116 v. 109 when I referenced it.
>> 
>> 
>> On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:
>> 
>> Owen,
>> 
>> So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?  
>> 
>> ----Cathy
>> 
>> On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
>> Marty,
>>         How do you expect anyone but the largest of the large and extra large
>> organizations to qualify for a /20 of IPv4 space under this proposal?
>> 
>>         This is a really interesting way to attempt to reserve the last /8 for use
>> only by the largest organizations ARIN serves, but, I really don't think that
>> is good policy.
>> 
>> Owen
>> 
>> On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:
>> 
>> >
>> >
>> > Hello PPML:
>> >
>> >
>> > Since it seemed to have been very helpful to vet the global policy idea on
>> > the list, I thought it might be helpful to use it to frame my non-support
>> > for 109. This is, just like the last time, very raw, but I expect to solicit
>> > some time during open policy hour to discuss a more polished version.
>> >
>> > A few points.
>> >
>> > - This idea takes us in the direction of actual transition
>> > - Define an acceptable use list
>> > - Seeks to address COSTS
>> > - Levels the playing field between small and large
>> > - Reserves an entire /8 for transition, not for business as usual
>> > - Counters the high priced "market" that is emerging by deferring it's need
>> >
>> > May not get us all the way through, but every month that we can avoid
>> > sending people to markets is a month of reduced costs IMHO. And it is about
>> > costs at this point. It's a given that it is going to happen.
>> >
>> > Too soon for "for" or "against", but most definitely open to feedback. Don't
>> > focus on the words, focus on the ideas. Feedback very much appreciated.
>> >
>> >
>> > --draft, group working comments removed for ease of read
>> >
>> > 1. Transition Pool
>> >
>> > ARIN will set-aside the final /8 allocated form the IANA to facilitate
>> > transition from IPv4 to IPv6. The resulting "transition pool" will become
>> > immediately available for allocations under this policy. This pool will be
>> > known as the "transition pool".
>> >
>> > 2. Minimum and Maximum Allocation Unit
>> >
>> > The minimum allocation unit will be a /20. The maximum allocation unit will
>> > be /15.
>> >
>> > 2. Allocation Method
>> >
>> > ARIN will determine and utilize the best method possible for allocations
>> > with the goal of maximizing what can be allocated balanced by minimum
>> > deaggregation.
>> >
>> > 3. Eligibility
>> >
>> > An applicant will become eligible to receive IPv4 addresses from this pool
>> > when they meet the following requirements:
>> >
>> > 1. Applicant will provide a written plan detailing how the addresses will be
>> > used and on what devices.
>> >
>> > 2. Previous allocations or assignments under this policy must continue to
>> > meet the justification requirements of this policy.
>> >
>> > 3. Must have applied for, been approved, received and be utilizing an ARIN
>> > allocated IPv6 allocation or assignment.
>> >
>> > 4. All allocations or assignments made under this policy must be efficiently
>> > utilized to a rate of 80%.
>> >
>> > 5. Applicant must demonstrate that no other allocations or assignments that
>> > they have received will meet their requirements.
>> >
>> > 6. Applicants must provide documentation that demonstrates that the
>> > addresses received under this policy will be used only on dual stack devices
>> > that will have both an IPv4 and IPv6 address that will both be reachable
>> > natively.
>> >
>> > 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>> >
>> >
>> > 4. Acceptable Use of Addresses
>> >
>> > 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
>> > each layer 3 contagious v6 only customer networks thereby enabling IPv4
>> > connectivity for an IPv6-only customer networks. Customers must not have
>> > available IPv4 addresses.
>> >
>> > 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
>> > each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
>> > addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
>> > an IPv6-only customer networks.. Customers must not have available IPv4
>> > addresses.
>> >
>> > 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
>> > additional IPv4 address to meet multi-homing traffic engineering needs or to
>> > address stand-alone NAT devices as specified below:
>> >
>> > A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
>> > contiguous customer network that requires traffic engineering. For example a
>> > network with two interconnects to a single upstream provider can get one
>> > IPv4 /32 for each of their two interconnects, and distribute their internal
>> > hosts between the two outside NAT addresses for traffic engineering.
>> >
>> > B. Customer networks that require stand-alone NAT devices (not integrated
>> > into their CPE router) qualify for enough IPv4 addresses to number the
>> > loopback addresses (if needed) for all edge routers that have one or more
>> > connections to a transit provider, enough IPv4 addresses to number each of
>> > the point-to-point links between those routers and their transit provider,
>> > as well as the point to point links between those routers and directly
>> > connected NAT appliances. As well as one IPv4 address for each of these
>> > directly connected NAT appliances.
>> >
>> >
>> > 4. Loopback addresses for edge routers that have one or more connections to
>> > transit providers and/or peers
>> >
>> > 5. Address for point to point links between edge routers and their transit
>> > providers [why does it need to be unique v. 1918?] [that is an interesting
>> > point... We use globally unique as a matter of not breaking routing by
>> > accident. I have to think about if it would be generally acceptable to use
>> > RFC-1918. Interesting question!]
>> >
>> > 7. A /32 for routers in a greenfield network that are dual stacked.
>> > [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
>> > routerID to make BGP work. If I want to be a green-filed IPv6 transit
>> > provider I need one IPv4 address for each router]
>> >
>> > 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
>> > servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>> >
>> > 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>> >
>> >
>> > 5. Reservation Forecasting
>> >
>> > An applicant may provide ARIN with a thirty-month forecast of IPv4 address
>> > need. ARIN will reserve the requested size in compliance with Section 2 and
>> > 3. When a reservation forecast is approved by ARIN, the applicant will then
>> > be authorized to draw down from the forecast quarterly. Prior to requesting
>> > reserved addresses, applicant will provide documentation to ARIN that they
>> > have maintained utilization requirements for previous allocation. If
>> > applicant fails to meet utilization requirements for two consecutive
>> > quarters, ARIN will cancel the reservation and return unused addresses to
>> > the pool.
>> >
>> >
>> > Example:
>> >
>> > Applicant applies to ARIN under this policy and submits a thirty-month
>> > forecast requesting a /16. Using criteria established in the NRPM and this
>> > policy, ARIN will determine if applicant is eligible and has need. If the
>> > applicant meets the requirements for the allocation, they will reserve a
>> > /16. The applicant will then be allocated 3/30th of the forecasted
>> > requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
>> > will round down allocations or assignments to the closest CIDR single block.
>> > Rounding errors will be applied to the last allocation of the last quarter
>> > of the thirty month period and allocated then.
>> >
>> >
>> > 6. Dual Stack Requirement
>> >
>> > Addresses from this pool may only be used on dual stack devices that are to
>> > be reachable via both IPv4 and IPv6 networks.
>> >
>> >
>> > 7. Application Frequency
>> >
>> > Applicants may apply for address space from the transition pool once per
>> > quarter. If an applicant has an existing thirty-month forecast that has been
>> > approved by ARIN, they are ineligible to apply for more address space until
>> > their reservation has been exhausted. If an applicant has had a reservation
>> > cancelled due to policy compliance issues including utilization, they are
>> > not eligble to apply for addresses.
>> >
>> >
>> > 8. Post Exhaustion Refresh
>> >> From the point of the issuance of the final /8 from the IANA, ARIN will
>> > dispose of all address space that it may receive using this policy.
>> >
>> > _______________________________________________
>> > 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.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100729/cf989123/attachment.htm>

From owen at delong.com  Fri Jul 30 03:17:43 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Jul 2010 00:17:43 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C5260B2.3070803@quark.net>
References: <C8736CFE.A81C%marty@akamai.com> <4C5260B2.3070803@quark.net>
Message-ID: <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com>

I think to some extent 4.10 attempted to do that.

I think that 116 is an attempt to do a little more of that. As it currently stands, there are no criteria
for 4.10 so arguably ARIN staff could either not be able to issue space for any technology under
existing 4.10, or, they may not be able to make any determination that any particular claimed
usage is not transitional.

As such, I think we need to do something to shore up 4.10. 116 was an attempt to do that while
not restricting the policy only to the technologies known now.

So, I think the closest you might be able to come to punting right now would be to support the
discussion petition for 116.

Owen

On Jul 29, 2010, at 10:18 PM, Andrew Dul wrote:

> Has anyone considered that maybe what we should do is just reserve the block for future use and not try to predict the future too much at this point and instead comeback after IPv4 exhaustion and then write an appropriate policy.  Yes this does kick the ball down the field, but it also allows the ability to have space to work with in the future to use for an appropriate use after IPv4 run-out.
> 
> Andrew 
> 
> On 7/26/2010 1:49 PM, Hannigan, Martin wrote:
>> 
>> 
>> 
>> And a minor correction please. I meant proposal 116 v. 109 when I referenced it.
>> 
>> 
>> On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:
>> 
>> Owen,
>> 
>> So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?  
>> 
>> ----Cathy
>> 
>> On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
>> Marty,
>>         How do you expect anyone but the largest of the large and extra large
>> organizations to qualify for a /20 of IPv4 space under this proposal?
>> 
>>         This is a really interesting way to attempt to reserve the last /8 for use
>> only by the largest organizations ARIN serves, but, I really don't think that
>> is good policy.
>> 
>> Owen
>> 
>> On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:
>> 
>> >
>> >
>> > Hello PPML:
>> >
>> >
>> > Since it seemed to have been very helpful to vet the global policy idea on
>> > the list, I thought it might be helpful to use it to frame my non-support
>> > for 109. This is, just like the last time, very raw, but I expect to solicit
>> > some time during open policy hour to discuss a more polished version.
>> >
>> > A few points.
>> >
>> > - This idea takes us in the direction of actual transition
>> > - Define an acceptable use list
>> > - Seeks to address COSTS
>> > - Levels the playing field between small and large
>> > - Reserves an entire /8 for transition, not for business as usual
>> > - Counters the high priced "market" that is emerging by deferring it's need
>> >
>> > May not get us all the way through, but every month that we can avoid
>> > sending people to markets is a month of reduced costs IMHO. And it is about
>> > costs at this point. It's a given that it is going to happen.
>> >
>> > Too soon for "for" or "against", but most definitely open to feedback. Don't
>> > focus on the words, focus on the ideas. Feedback very much appreciated.
>> >
>> >
>> > --draft, group working comments removed for ease of read
>> >
>> > 1. Transition Pool
>> >
>> > ARIN will set-aside the final /8 allocated form the IANA to facilitate
>> > transition from IPv4 to IPv6. The resulting "transition pool" will become
>> > immediately available for allocations under this policy. This pool will be
>> > known as the "transition pool".
>> >
>> > 2. Minimum and Maximum Allocation Unit
>> >
>> > The minimum allocation unit will be a /20. The maximum allocation unit will
>> > be /15.
>> >
>> > 2. Allocation Method
>> >
>> > ARIN will determine and utilize the best method possible for allocations
>> > with the goal of maximizing what can be allocated balanced by minimum
>> > deaggregation.
>> >
>> > 3. Eligibility
>> >
>> > An applicant will become eligible to receive IPv4 addresses from this pool
>> > when they meet the following requirements:
>> >
>> > 1. Applicant will provide a written plan detailing how the addresses will be
>> > used and on what devices.
>> >
>> > 2. Previous allocations or assignments under this policy must continue to
>> > meet the justification requirements of this policy.
>> >
>> > 3. Must have applied for, been approved, received and be utilizing an ARIN
>> > allocated IPv6 allocation or assignment.
>> >
>> > 4. All allocations or assignments made under this policy must be efficiently
>> > utilized to a rate of 80%.
>> >
>> > 5. Applicant must demonstrate that no other allocations or assignments that
>> > they have received will meet their requirements.
>> >
>> > 6. Applicants must provide documentation that demonstrates that the
>> > addresses received under this policy will be used only on dual stack devices
>> > that will have both an IPv4 and IPv6 address that will both be reachable
>> > natively.
>> >
>> > 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>> >
>> >
>> > 4. Acceptable Use of Addresses
>> >
>> > 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
>> > each layer 3 contagious v6 only customer networks thereby enabling IPv4
>> > connectivity for an IPv6-only customer networks. Customers must not have
>> > available IPv4 addresses.
>> >
>> > 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
>> > each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
>> > addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
>> > an IPv6-only customer networks.. Customers must not have available IPv4
>> > addresses.
>> >
>> > 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
>> > additional IPv4 address to meet multi-homing traffic engineering needs or to
>> > address stand-alone NAT devices as specified below:
>> >
>> > A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
>> > contiguous customer network that requires traffic engineering. For example a
>> > network with two interconnects to a single upstream provider can get one
>> > IPv4 /32 for each of their two interconnects, and distribute their internal
>> > hosts between the two outside NAT addresses for traffic engineering.
>> >
>> > B. Customer networks that require stand-alone NAT devices (not integrated
>> > into their CPE router) qualify for enough IPv4 addresses to number the
>> > loopback addresses (if needed) for all edge routers that have one or more
>> > connections to a transit provider, enough IPv4 addresses to number each of
>> > the point-to-point links between those routers and their transit provider,
>> > as well as the point to point links between those routers and directly
>> > connected NAT appliances. As well as one IPv4 address for each of these
>> > directly connected NAT appliances.
>> >
>> >
>> > 4. Loopback addresses for edge routers that have one or more connections to
>> > transit providers and/or peers
>> >
>> > 5. Address for point to point links between edge routers and their transit
>> > providers [why does it need to be unique v. 1918?] [that is an interesting
>> > point... We use globally unique as a matter of not breaking routing by
>> > accident. I have to think about if it would be generally acceptable to use
>> > RFC-1918. Interesting question!]
>> >
>> > 7. A /32 for routers in a greenfield network that are dual stacked.
>> > [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
>> > routerID to make BGP work. If I want to be a green-filed IPv6 transit
>> > provider I need one IPv4 address for each router]
>> >
>> > 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
>> > servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>> >
>> > 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>> >
>> >
>> > 5. Reservation Forecasting
>> >
>> > An applicant may provide ARIN with a thirty-month forecast of IPv4 address
>> > need. ARIN will reserve the requested size in compliance with Section 2 and
>> > 3. When a reservation forecast is approved by ARIN, the applicant will then
>> > be authorized to draw down from the forecast quarterly. Prior to requesting
>> > reserved addresses, applicant will provide documentation to ARIN that they
>> > have maintained utilization requirements for previous allocation. If
>> > applicant fails to meet utilization requirements for two consecutive
>> > quarters, ARIN will cancel the reservation and return unused addresses to
>> > the pool.
>> >
>> >
>> > Example:
>> >
>> > Applicant applies to ARIN under this policy and submits a thirty-month
>> > forecast requesting a /16. Using criteria established in the NRPM and this
>> > policy, ARIN will determine if applicant is eligible and has need. If the
>> > applicant meets the requirements for the allocation, they will reserve a
>> > /16. The applicant will then be allocated 3/30th of the forecasted
>> > requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
>> > will round down allocations or assignments to the closest CIDR single block.
>> > Rounding errors will be applied to the last allocation of the last quarter
>> > of the thirty month period and allocated then.
>> >
>> >
>> > 6. Dual Stack Requirement
>> >
>> > Addresses from this pool may only be used on dual stack devices that are to
>> > be reachable via both IPv4 and IPv6 networks.
>> >
>> >
>> > 7. Application Frequency
>> >
>> > Applicants may apply for address space from the transition pool once per
>> > quarter. If an applicant has an existing thirty-month forecast that has been
>> > approved by ARIN, they are ineligible to apply for more address space until
>> > their reservation has been exhausted. If an applicant has had a reservation
>> > cancelled due to policy compliance issues including utilization, they are
>> > not eligble to apply for addresses.
>> >
>> >
>> > 8. Post Exhaustion Refresh
>> >> From the point of the issuance of the final /8 from the IANA, ARIN will
>> > dispose of all address space that it may receive using this policy.
>> >
>> > _______________________________________________
>> > 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.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From michael.dillon at bt.com  Fri Jul 30 09:15:34 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 30 Jul 2010 14:15:34 +0100
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>

> Didn't one
> of the academics do a peer-reviewed study and a scan of the Internet
> last year with results suggesting (among other things) that about
> 2/3rds of the allocated address space is not employed on the public
> Internet?

Irrelevant.
ARIN does not allocate IP addresses for the public Internet.

ARIN's role is to allocate IP addresses to organizations that require them
in order to build and operate Internet Protocol networks. While many of these
private networks are interconnected to form the public Internet, that is not
relevant to ARIN's mission. It has never been mandatory to make your IP
network part of the public Internet and there is no good reason to change
that.

--Michael Dillon



From warren at wholesaleinternet.com  Fri Jul 30 09:17:33 2010
From: warren at wholesaleinternet.com (Warren Wholesale.com)
Date: Fri, 30 Jul 2010 08:17:33 -0500
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <59AEFE98-8AE3-4D27-BFC5-226372E67648@gmail.com>
References: <C8736CFE.A81C%marty@akamai.com> <4C5260B2.3070803@quark.net>
	<59AEFE98-8AE3-4D27-BFC5-226372E67648@gmail.com>
Message-ID: <02a601cb2fe9$937847d0$ba68d770$@com>

I would suggest making policy now.   Post exhaustion, people may not make as
rational decisions J.

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Scott Leibrand
Sent: Friday, July 30, 2010 12:28 AM
To: andrew.dul at quark.net
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Set aside round deux

 

Joe proposed that for the whole /8, and it didn't get much support. How big
a block were you thinking?

 

-Scott


On Jul 29, 2010, at 10:18 PM, Andrew Dul <andrew.dul at quark.net> wrote:

Has anyone considered that maybe what we should do is just reserve the block
for future use and not try to predict the future too much at this point and
instead comeback after IPv4 exhaustion and then write an appropriate policy.
Yes this does kick the ball down the field, but it also allows the ability
to have space to work with in the future to use for an appropriate use after
IPv4 run-out.

Andrew 

On 7/26/2010 1:49 PM, Hannigan, Martin wrote: 



And a minor correction please. I meant proposal 116 v. 109 when I referenced
it.


On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:

Owen,

So do you feel that this is bad all around or just the minimum allocation
unit needs to be changed to something smaller?  Others out there?  What are
your thoughts regarding a minimum/maximum allocation size for this last /8?
----Cathy

On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:

Marty,
        How do you expect anyone but the largest of the large and extra
large
organizations to qualify for a /20 of IPv4 space under this proposal?

        This is a really interesting way to attempt to reserve the last /8
for use
only by the largest organizations ARIN serves, but, I really don't think
that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

>
>
> Hello PPML:
>
>
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to
solicit
> some time during open policy hour to discuss a more polished version.
>
> A few points.
>
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's
need
>
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is
about
> costs at this point. It's a given that it is going to happen.
>
> Too soon for "for" or "against", but most definitely open to feedback.
Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
>
>
> --draft, group working comments removed for ease of read
>
> 1. Transition Pool
>
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
>
> 2. Minimum and Maximum Allocation Unit
>
> The minimum allocation unit will be a /20. The maximum allocation unit
will
> be /15.
>
> 2. Allocation Method
>
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation.
>
> 3. Eligibility
>
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
>
> 1. Applicant will provide a written plan detailing how the addresses will
be
> used and on what devices.
>
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
>
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
>
> 4. All allocations or assignments made under this policy must be
efficiently
> utilized to a rate of 80%.
>
> 5. Applicant must demonstrate that no other allocations or assignments
that
> they have received will meet their requirements.
>
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack
devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.
>
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>
>
> 4. Acceptable Use of Addresses
>
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for
each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
>
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for
each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity
for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses.
>
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or
to
> address stand-alone NAT devices as specified below:
>
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example
a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their
internal
> hosts between the two outside NAT addresses for traffic engineering.
>
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
>
>
> 4. Loopback addresses for edge routers that have one or more connections
to
> transit providers and/or peers
>
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
>
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
>
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN
aggregator
>
>
> 5. Reservation Forecasting
>
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2
and
> 3. When a reservation forecast is approved by ARIN, the applicant will
then
> be authorized to draw down from the forecast quarterly. Prior to
requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool.
>
>
> Example:
>
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single
block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
>
>
> 6. Dual Stack Requirement
>
> Addresses from this pool may only be used on dual stack devices that are
to
> be reachable via both IPv4 and IPv6 networks.
>
>
> 7. Application Frequency
>
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has
been
> approved by ARIN, they are ineligible to apply for more address space
until
> their reservation has been exhausted. If an applicant has had a
reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
>
>
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy.
>
> _______________________________________________
> 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.

 

_______________________________________________
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: winmail.dat
Type: application/ms-tnef
Size: 15230 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100730/11a8bde5/attachment.bin>

From michael.dillon at bt.com  Fri Jul 30 09:43:34 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 30 Jul 2010 14:43:34 +0100
Subject: [arin-ppml] Ending point to point links as a justification
	for	a /30?
In-Reply-To: <89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
	<89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918022043@EMV01-UKBR.domain1.systemhost.net>

> Express a 128 bit number in 32 bits such that all possible 128 bit
> values
> are uniquely expressed in the 32 bit field.

This problem was solved a long, long time ago at least as early as
1930 when BAUDOT code was enhanced by the ITU's predecessor to become
International Telegraphy Alphabet No. 2. 

A more modern example is the Unicode encoding known as UTF-8 where
escape codes followed by multiple bytes are used to represent codes
which would not otherwise fit into an 8-bit byte.

An IPv4 extension might take over the class E address space (E for
Escape and Encapsulation) to use as Escape and Encap addresses for
addressing portions of the extended 64-bit IPv4 address range that
are not accessible with straight 32-bit addresses. Or you could
call it IPv7 or IPv11 or whatever. It could easily be made to
interwork with the normal IPv4 Internet as long as class E addresses
were handled normally by all devices. The traffic coming from
class E space would actually be from 64-bit address sites that
were using middleboxes in the class E space as Escape and Encap
gateways. 

This would make an interesting project for an undergraduate network
engineering class to build a proof of concept, but I don't think
it would ever displace IPv6 even the teeniest little bit.

> If you solve this problem, please contact me, I'm sure we can make
> money
> from your solution.

People make money by selling the Brooklyn Bridge, but that doesn't mean
it is a good thing to get involved in.

I really would like to see people begin to work on an IPv6 replacement
because we now know that it takes almost a generation for an Internet
protocol replacement to get off the ground. If you are fresh out of 
college, intelligent, and working close enough to the network operations
area over the next 5 years or so to see what kind of issues come up and
get solved then you have a chance of making a new proposal that is workable.
If you are 22 years old, and write your RFCs when your idea is ready at
age 27, then you could see the protocol ready for live deployment by
age 37. Give it another 10 years of practical experience to work out
the rough edges, and by age 47 you may see it being adopted as a
replacement for IPv6 in some networks that have limited Internet
connectivity like MILNET. Spend another 20 years evangelizing it
and by age 67, you might see it adopted by the public Internet, or
at least a firm plan of transition being adopted.

Probably not worth talking about this seriously for another 5 years
though.

--Michael Dillon



From michael.dillon at bt.com  Fri Jul 30 09:45:40 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 30 Jul 2010 14:45:40 +0100
Subject: [arin-ppml] Ending point to point links as a justification for
 a /30?
In-Reply-To: <4C521B31.7060303@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com>	<4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>	<407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com>
	<4C521B31.7060303@chl.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391802204A@EMV01-UKBR.domain1.systemhost.net>

> I am opposed to reclamation techniques that step up the confrontational
> and adversarial relationship between ARIN and address holders, even
> were
> it to be essential for continued consumption of IPv4 and IPv6 did not
> exist. I view increasing auditing and mandatory triggers of audits with
> similar concern.
> 
> Expending good will and buy in, not to mention financial resources, all
> for relatively limited return along with greater risks of legal and
> political liabilities is not a good bargain.
> 
> Bad cop is not a character role an organization like ARIN should choose
> to be identified with.
> 
> Incentives for efficiencies, that is where my support lands. Even then,
> I prefer less direct incentives, those that can be spread and carried
> by
> the invisible hand.
> 
> I would support ARIN advocacy for technical standards and features that
> were mindful of IPv4 scarcity. I would also support advocacy for
> technical standards and features that would help smooth migration and
> transition to IPv6. I believe ARIN does have a role to play there and
> not just a passive one. Let them be a voice of the addressing
> community,
> a liaison, to help focus on those concerns in many an arena.
> 
> Joe

Well said, Joe!
I am 100% in agreement with this approach.

--Michael Dillon



From jmaimon at chl.com  Fri Jul 30 09:54:02 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 30 Jul 2010 09:54:02 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>	<20100729021840.B101E2B2135@mx5.roble.com>	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4C52D97A.2050409@chl.com>



michael.dillon at bt.com wrote:
>> Didn't one
>> of the academics do a peer-reviewed study and a scan of the Internet
>> last year with results suggesting (among other things) that about
>> 2/3rds of the allocated address space is not employed on the public
>> Internet?
>
> Irrelevant.
> ARIN does not allocate IP addresses for the public Internet.
>
> ARIN's role is to allocate IP addresses to organizations that require them
> in order to build and operate Internet Protocol networks. While many of these
> private networks are interconnected to form the public Internet, that is not
> relevant to ARIN's mission. It has never been mandatory to make your IP
> network part of the public Internet and there is no good reason to change
> that.
>
> --Michael Dillon
>

All that is historically true. Now it is only true to a much lesser extent.

Current reality is that globally unique addresses are of most value on 
the global network and I would be quite surprised if the percentage of 
allocation for other purposes was above single percentage digits.

Policy already differentiates for multi-homers to the global network. 
Does that mean that policy requires the allocations to these 
multi-homers on that basis to be routable?  In my experience, the common 
impression is yes, it does.

That a large portion of allocations as well as legacy space appear to be 
non-routed is more likely due to happenstance rather than the 
intentional design and purpose of the allocation at the time it was made.

I expect, and I hope, that requests for global resources that are not to 
be addressable on the global network must demonstrate why site-local 
rfc1918 addressing is not sufficient for their needs, as it is for the 
overwhelming majority of network not directly addressable from the 
global network.

I do believe that suitable need can be demonstrated in a minority of 
situations.

Policy that dictates that requests for global resources must demonstrate 
a global need for those resources is not out of order.

Demonstrating justified global need should not nearly be as easy for 
resources intended to not being addressable on the global network as 
otherwise.


Joe


From marty at akamai.com  Fri Jul 30 09:56:07 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 30 Jul 2010 09:56:07 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C5260B2.3070803@quark.net>
Message-ID: <C8785237.B51A%marty@akamai.com>




On 7/30/10 1:18 AM, "Andrew Dul" <andrew.dul at quark.net> wrote:

>    Has anyone considered that maybe what we should do is just reserve the
> block for future use and not try to predict the future too much at this point
> and instead comeback after IPv4 exhaustion and then write an appropriate
> policy.  Yes this does kick the ball down the field, but it also allows the
> ability to have space to work with in the future to use for an appropriate use
> after IPv4 run-out.
>  
>  Andrew 
>  


Hi Andrew,

Guess I'm not sure what would be speculation or not. I think that there are
some facts at hand:

-  ipv4 addresses will run out at the IANA this year
-  at least three RIR's (ARIN, RIPE, APNIC) will run out of ipv4 address
   space next year
-  networks will need to find ipv4 addresses in order to grow and transition


We could modify such a proposal later if it were posed and succeeds, and
finally, if something is broken horribly and there's consensus the BoT could
act (and probably not be vilified).

Setting aside a block for future use doesn't seem prudent to me. The time to
take it from "reserved" to "in use" would be significant. The fact that we
don't have policy already that sets a direction for transition is troubling
and I see the opportunity to do that with a solid set-aside proposal.


Best,

Marty



From terry.l.davis at boeing.com  Fri Jul 30 10:14:02 2010
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Fri, 30 Jul 2010 07:14:02 -0700
Subject: [arin-ppml] Ending point to point links as a justification
	fora	 /30?
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B42391802204A@EMV01-UKBR.domain1.systemhost.net>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com><4
	C51DBE8.9060108@chl.com>	<4C51E1F7.1000302@rollernet.us><4C51E4F5.9090003@c
	hl.com>
	<407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com><4C521B31.7060303@chl.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B42391802204A@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516E41AF3@XCH-NW-05V.nw.nos.boeing.com>

Michael/Joe

I agree also; confrontational approaches will most likely fail.

I more suggest that ARIN find every way possible to incentivize use and migration to IPv6!

As we approach the end of IPv4 space, should an IPv4 allocation also require a corresponding IPv6 request and/or an IPv6 migration plan?

Take care
Terry
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Friday, July 30, 2010 6:46 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Ending point to point links as a 
> justification fora /30?
> 
> > I am opposed to reclamation techniques that step up the 
> confrontational
> > and adversarial relationship between ARIN and address holders, even
> > were
> > it to be essential for continued consumption of IPv4 and 
> IPv6 did not
> > exist. I view increasing auditing and mandatory triggers of 
> audits with
> > similar concern.
> > 
> > Expending good will and buy in, not to mention financial 
> resources, all
> > for relatively limited return along with greater risks of legal and
> > political liabilities is not a good bargain.
> > 
> > Bad cop is not a character role an organization like ARIN 
> should choose
> > to be identified with.
> > 
> > Incentives for efficiencies, that is where my support 
> lands. Even then,
> > I prefer less direct incentives, those that can be spread 
> and carried
> > by
> > the invisible hand.
> > 
> > I would support ARIN advocacy for technical standards and 
> features that
> > were mindful of IPv4 scarcity. I would also support advocacy for
> > technical standards and features that would help smooth 
> migration and
> > transition to IPv6. I believe ARIN does have a role to play 
> there and
> > not just a passive one. Let them be a voice of the addressing
> > community,
> > a liaison, to help focus on those concerns in many an arena.
> > 
> > Joe
> 
> Well said, Joe!
> I am 100% in agreement with this approach.
> 
> --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.
> 

From michael.dillon at bt.com  Fri Jul 30 10:21:27 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 30 Jul 2010 15:21:27 +0100
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C52D97A.2050409@chl.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>
	<20100729021840.B101E2B2135@mx5.roble.com>
	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>
	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
	<4C52D97A.2050409@chl.com>
Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918022092@EMV01-UKBR.domain1.systemhost.net>

> Policy already differentiates for multi-homers to the global network.

I'm not aware of how ARIN policies differentiates multi-homers on a
private internetwork from multihomers on the public Internet.

> I expect, and I hope, that requests for global resources that are not
> to
> be addressable on the global network must demonstrate why site-local
> rfc1918 addressing is not sufficient for their needs, as it is for the
> overwhelming majority of network not directly addressable from the
> global network.

EVen in the days of RFC 2050 it was necessary to show why you could not
use RFC 1918 addresses. In any case there is a big difference between 
a private network which does not interconnect (or has severly controlled
interconnects) and a private internetwork which basically functions just
like the Internet, except that they do not transit any traffic to the public
Internet. If you were to show this graphically, you would draw a big
cloud of Internet ASes with the best connected ones in the centre, and then
a very thin layer around the edge, practically invisible, which represents 
one of these private internetworks. The hundreds of ASes in one of these
private internetworks are probably all connected to the Internet, but 
are configured so that no traffic transits between the public Internet
and the private internetwork.

> I do believe that suitable need can be demonstrated in a minority of
> situations.

There are many such private internetworks and several of them are 
global in scope. Your minority represents thousands of companies,
many of which are large multinational companies. They may well
be numerically a minority, but they are a significant minority who
need to be served fairly by ARIN or they will destroy the RIR system.

The RIR system is based on fair dealing and therefore ARIN has to treat
it's minorities in the same way that Canada treats its French language 
majority, and the many First Nations peoples who occupied the territory
before Europeans arrived. The same model is followed in the USA with
its treatment of the black minority, the hispanic minority and so on.

Counting up things is a risky business because it leads to majority
versus minority thinking, which will only result in wasted energy
fighting disputes and bickering. Let's not go down that path.

--Michael Dillon



From bensons at queuefull.net  Fri Jul 30 11:48:06 2010
From: bensons at queuefull.net (Benson Schliesser)
Date: Fri, 30 Jul 2010 10:48:06 -0500
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C52D97A.2050409@chl.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>	<20100729021840.B101E2B2135@mx5.roble.com>	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
	<4C52D97A.2050409@chl.com>
Message-ID: <099BED9D-78F8-4EA5-9976-F3FEBCA19AFB@queuefull.net>


On 30 Jul 10, at 8:54 AM, Joe Maimon wrote:

> Policy that dictates that requests for global resources must demonstrate a global need for those resources is not out of order.

Agreed in principle, but "global need" doesn't equal "Internet routed".  E.g. A provider (of information or communication services) might run a global network that interconnects with many other networks (some of which may run RFC1918 internally) but isn't present in the global routing table, as seen by Tier 1 ISPs.  That network has the need for globally unique address space, just like any other global inter-network.

> Demonstrating justified global need should not nearly be as easy for resources intended to not being addressable on the global network as otherwise.

How would you propose that "demonstrating justified global need" is different between big-"I" and little-"i" internetworks?  Just because a prefix exists in the DFZ routing table doesn't mean that anyone can reach those addresses; firewalls and other methods of policy enforcement are ubiquitous.  Would a network like the one I described above hold more esteem simply by adding their prefixes to the global routing table, regardless of connectivity?

In short, I think it's a messy situation if any RIR starts discriminating based on the way addresses are used.  Clearly, it's a good idea to verify that "globally unique" is a requirement before providing an allocation of global resources.  But beyond that, I think we have to accept that not every organization has the same perspective as ourselves.  The RIR exists to foster number resources, not define the Internet.

Cheers,
-Benson



From owen at delong.com  Fri Jul 30 12:10:41 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Jul 2010 09:10:41 -0700
Subject: [arin-ppml] Ending point to point links as a justification
	for	a /30?
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423918022043@EMV01-UKBR.domain1.systemhost.net>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
	<4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us>
	<4C51E4F5.9090003@chl.com>
	<719F1296BEB46744A22C76B3C82BBA3507F58E1D@SACMSGEVS001.deltads.ent>
	<89738C29-FCFA-4966-A2F8-7D5D4F7E568A@delong.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918022043@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <83DADC8E-100E-418F-917C-803DDBB8802B@delong.com>


On Jul 30, 2010, at 6:43 AM, <michael.dillon at bt.com> wrote:

>> Express a 128 bit number in 32 bits such that all possible 128 bit
>> values
>> are uniquely expressed in the 32 bit field.
> 
> This problem was solved a long, long time ago at least as early as
> 1930 when BAUDOT code was enhanced by the ITU's predecessor to become
> International Telegraphy Alphabet No. 2. 
> 
So every BAUDOT system with zero software modification was able to
send and receive ITA No. 2 symbology? That's not what I remember
reading.

> A more modern example is the Unicode encoding known as UTF-8 where
> escape codes followed by multiple bytes are used to represent codes
> which would not otherwise fit into an 8-bit byte.
> 
I don't know of a single ASCII-only system that did not require software
updates to be able to accept user input or display UTF-8 characters
outside the normal ASCII range.

> An IPv4 extension might take over the class E address space (E for
> Escape and Encapsulation) to use as Escape and Encap addresses for
> addressing portions of the extended 64-bit IPv4 address range that
> are not accessible with straight 32-bit addresses. Or you could

Even if you did that, you would need software updates on EVERY
end system and to every piece of client/server software in order
to support it. It would not be backwards compatible.

Bzzt... But thank you for playing.
> 
> 
>> If you solve this problem, please contact me, I'm sure we can make
>> money
>> from your solution.
> 
> People make money by selling the Brooklyn Bridge, but that doesn't mean
> it is a good thing to get involved in.
> 
If you can solve the problem in a way that does not require software
modifications on the existing IPv4 hosts, I'm pretty sure that would
do well selling in today's environment. However, you can't actually
do so. Each of the techniques you described above did not pack
the unique 128 bit values into 32 bits, it merely provided a way to
flag the 32 bits for "but wait, there's more". That's not a solution,
that's a side-step.

Believe me, if you can find a way to represent 340 undecillion
unique values in 32 bits and make it actually work 100%,
I guarantee you there's legitimate money to be made.

Owen

P.S. Rather than working on an IPv6 replacement, I think we should
look at resolving the routing paradigm so that we can develop a
scalable IDR system. I believe that will require modification to the
packet headers, so, it will be an IPv6 replacement on one level, but,
this particular system should be able to be deployed in a backwards
compatible fashion much like the 32-bit ASN setup.





From owen at delong.com  Fri Jul 30 12:23:35 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Jul 2010 09:23:35 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C52D97A.2050409@chl.com>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>	<20100729021840.B101E2B2135@mx5.roble.com>	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
	<4C52D97A.2050409@chl.com>
Message-ID: <B88A5DAF-8349-4F18-A06F-DDC73B0793F5@delong.com>


On Jul 30, 2010, at 6:54 AM, Joe Maimon wrote:

> 
> 
> michael.dillon at bt.com wrote:
>>> Didn't one
>>> of the academics do a peer-reviewed study and a scan of the Internet
>>> last year with results suggesting (among other things) that about
>>> 2/3rds of the allocated address space is not employed on the public
>>> Internet?
>> 
>> Irrelevant.
>> ARIN does not allocate IP addresses for the public Internet.
>> 
>> ARIN's role is to allocate IP addresses to organizations that require them
>> in order to build and operate Internet Protocol networks. While many of these
>> private networks are interconnected to form the public Internet, that is not
>> relevant to ARIN's mission. It has never been mandatory to make your IP
>> network part of the public Internet and there is no good reason to change
>> that.
>> 
>> --Michael Dillon
>> 
> 
> All that is historically true. Now it is only true to a much lesser extent.
> 
I haven't seen any changes to the NRPM which make it true to a lesser extent.

What changes in ARIN policy can you show that make this less true?

> Current reality is that globally unique addresses are of most value on the global network and I would be quite surprised if the percentage of allocation for other purposes was above single percentage digits.
> 

Then I am pretty sure you are surprised.

> Policy already differentiates for multi-homers to the global network. Does that mean that policy requires the allocations to these multi-homers on that basis to be routable?  In my experience, the common impression is yes, it does.
> 
ARIN policy says nothing about whether addresses ARIN issues are routable or not with the exception of disclaimers stating "ARIN cannot guarantee..."

In any case, this has nothing to do with the fact that allocations or assignments for non-public networks are perfectly legitimate under current ARIN policy.

From NRPM 4.3.5:

4.3.5. Non-connected Networks

End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity.

> That a large portion of allocations as well as legacy space appear to be non-routed is more likely due to happenstance rather than the intentional design and purpose of the allocation at the time it was made.
> 
I do not agree. Of course we are both speculating to a large extent here. However, many things that appear non-routed from one perspective are routed from other perspectives. There is no single unified global routing table.

> I expect, and I hope, that requests for global resources that are not to be addressable on the global network must demonstrate why site-local rfc1918 addressing is not sufficient for their needs, as it is for the overwhelming majority of network not directly addressable from the global network.
> 
As stated in NRPM 4.3.5, they do. However, that is pretty simple:

Hello, we're organization A. We don't want to connect to the internet, but, we do want to exchange traffic with several other organizations using IP. As such, coordination of RFC-1918 between or organizations is infeasible and we request globally unique unicast IP numbers.

> I do believe that suitable need can be demonstrated in a minority of situations.
> 
A minority, perhaps, but, certainly not a particularly limited minority.

> Policy that dictates that requests for global resources must demonstrate a global need for those resources is not out of order.
> 
It may not be out of order, but, it is not current policy. I suspect such a proposal would be unlikely to gain consensus, but, if you feel that it can, I encourage you to write it up and submit it. If you want help, I'm happy to help you.

> Demonstrating justified global need should not nearly be as easy for resources intended to not being addressable on the global network as otherwise.
> 
Again, that isn't current policy, so, you'll need to gain consensus around a proposal to make it so.

Owen


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

From stephen at sprunk.org  Fri Jul 30 13:09:32 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 30 Jul 2010 12:09:32 -0500
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
References: <mailman.7.1280332802.12030.arin-ppml@arin.net>	<20100729021840.B101E2B2135@mx5.roble.com>	<031B93E3-E29B-4DAB-A78D-7AF8706D662F@delong.com>	<AANLkTimmYVGRhCz3-0cf-8qjY4NCNhWT+5PfwhZDvCzA@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B423918021FFD@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4C53074C.7060507@sprunk.org>

On 30 Jul 2010 08:15, michael.dillon at bt.com wrote:
>> Didn't one of the academics do a peer-reviewed study and a scan of the Internet last year with results suggesting (among other things) that about 2/3rds of the allocated address space is not employed on the public Internet?
>>     
> Irrelevant.
> ARIN does not allocate IP addresses for the public Internet.
>   

Agreed.  Still, address space not routed on the public Internet is a
logical place to start looking for abandoned or unused space to
reclaim.  If the registrant responds that they are using that space for
a private internet and passes a Section 12 review, we thank them and
move on.  If the registrant doesn't respond or their use doesn't pass a
review, Section 12 has procedures for that as well.

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/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100730/a0106eb5/attachment.p7s>

From stephen at sprunk.org  Fri Jul 30 13:27:26 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 30 Jul 2010 12:27:26 -0500
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com>
References: <C8736CFE.A81C%marty@akamai.com> <4C5260B2.3070803@quark.net>
	<797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com>
Message-ID: <4C530B7E.2030508@sprunk.org>

On 30 Jul 2010 02:17, Owen DeLong wrote:
> As it currently stands, there are no criteria for 4.10 so arguably
> ARIN staff could either not be able to issue space for any technology
> under existing 4.10, or, they may not be able to make any
> determination that any particular claimed usage is not transitional.

To paraphrase comments by Leslie on a somewhat-related topic, ARIN staff
grants all requests unless they can point to a specific section of the
NRPM prohibiting it, i.e. a "default allow" policy.

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/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100730/2917db46/attachment.p7s>

From marquis at roble.com  Fri Jul 30 17:02:24 2010
From: marquis at roble.com (Roger Marquis)
Date: Fri, 30 Jul 2010 14:02:24 -0700 (PDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <mailman.5.1280419202.21239.arin-ppml@arin.net>
References: <mailman.5.1280419202.21239.arin-ppml@arin.net>
Message-ID: <20100730210224.C86DA2B2135@mx5.roble.com>

> Additionally, much of the space to be audited is legacy space where
> it is not entirely clear ARIN can do much about the situation after the
> audit anyway.

Can't deny there is not much ARIN can do currently, particularly not
given its inability make IPv6 more feasible or correct past excessively
large IPv4 allocations.   This is likely to change, however, when there
are no more IPv4 addresses to allocate and current netblock owners begin
milking their holdings for profit.  When that occurs the legal landscape
is likely to change as it did when ICANN proposed deregulating tld
domain names.  In that case the DOD stepped in.  In this case I would
also expect the FCC to step in.

> An auditor as you are describing shouldn't actually bring any opinions
> on IPv6 transition or any of the other factors to the table at all. To the
> extent possible, the auditor should be strictly looking at whether the
> address utilization is sufficiently efficient according to ARIN policy to
> justify the address space held and making a report of that fact or of
> the extent to which the organization in question is out of compliance
> with ARIN policy.

Agreed, and it is that policy i.e., recognizing utilization, which must
change.  In particular it must begin addressing large legacy allocations,
mergers and aquisitions, and abandoned netblocks.

> The next step would be for staff to institute voluntary or forced reclamation
> procedures as required under section 12 after the audit, if the organization
> is significantly out of compliance.

I'd be surprised if there will not be sufficient political capital for
forced reclamation.  The political fallout necessary for that will follow
address exhaustion and it will be shaped first by the press and then by
the government.  We have not yet seen a "60 Minutes" show muckraking the
large IPv4 squatters but, heads-up corporate marketing departments, you
will likely need to move to damage control mode when the press picks up
this story.  Nothing new here, just study the history of Enron,
CountryWide, BP and other one-time beneficiaries of excessive
deregulation and under-regulation for details.

> There really is not much that ARIN can do to change the way that IPv4
> exhaustion impacts us. It is too late. About the only thing that would
> help us through the IPv6 transition would be a massive educational
> program by ARIN, starting with sessions for New York stock market analysts
> who ask CEOs the tough questions when they present their quarterly
> results.

"There really is not much that ARIN can do" does seem to be the case,
today, except perhaps for planning a less disruptive transition to IPv6,
emphasis on the "disruptive".

Roger Marquis


From marquis at roble.com  Fri Jul 30 17:28:14 2010
From: marquis at roble.com (Roger Marquis)
Date: Fri, 30 Jul 2010 14:28:14 -0700 (PDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <mailman.185.1280504892.17521.arin-ppml@arin.net>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>
Message-ID: <20100730212814.848D82B213A@mx5.roble.com>

michael.dillon at bt.com wrote:
> Counting up things is a risky business because it leads to majority
> versus minority thinking, which will only result in wasted energy
> fighting disputes and bickering. Let's not go down that path.

Good luck with that.  Deregulation is not the poster-child it was a few
years ago.  There will be fighting disputes and bickering and conflicts
will increase with address exhaustion.

Michael's perspective appears to be predicated on a thesis that
Internet-routed IP addresses are private assets.  The legal precedent,
OTOH, is more likely to see these addresses as public commons, similar to
the radio frequency spectrum.

Roger Marquis


From owen at delong.com  Fri Jul 30 17:48:47 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 30 Jul 2010 14:48:47 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100730210224.C86DA2B2135@mx5.roble.com>
References: <mailman.5.1280419202.21239.arin-ppml@arin.net>
	<20100730210224.C86DA2B2135@mx5.roble.com>
Message-ID: <AE46285B-6B02-405C-9128-A13099540D61@delong.com>


On Jul 30, 2010, at 2:02 PM, Roger Marquis wrote:

>> Additionally, much of the space to be audited is legacy space where
>> it is not entirely clear ARIN can do much about the situation after the
>> audit anyway.
> 
> Can't deny there is not much ARIN can do currently, particularly not
> given its inability make IPv6 more feasible or correct past excessively
> large IPv4 allocations.   This is likely to change, however, when there
> are no more IPv4 addresses to allocate and current netblock owners begin
> milking their holdings for profit.  When that occurs the legal landscape
> is likely to change as it did when ICANN proposed deregulating tld
> domain names.  In that case the DOD stepped in.  In this case I would
> also expect the FCC to step in.
> 
Not sure why you think IPv6 is either infeasible or incorrect, given the
large deployments actually operating with it. Is there room for improvement?
Sure. However, that can be said of just about anything. IPv6 is certainly not
particularly worse than IPv4 and has several advantages, including the
improvements in security and reliability that come from eliminating NAT.

When there are no more IPv4 addresses, I would expect the FCC will tell
you the same thing ARIN has been saying for some time... Use IPv6.

>> An auditor as you are describing shouldn't actually bring any opinions
>> on IPv6 transition or any of the other factors to the table at all. To the
>> extent possible, the auditor should be strictly looking at whether the
>> address utilization is sufficiently efficient according to ARIN policy to
>> justify the address space held and making a report of that fact or of
>> the extent to which the organization in question is out of compliance
>> with ARIN policy.
> 
> Agreed, and it is that policy i.e., recognizing utilization, which must
> change.  In particular it must begin addressing large legacy allocations,
> mergers and aquisitions, and abandoned netblocks.
> 
Those issues are all addressed.... In IPv6. Efforts to address them in
IPv4 will not yield more than a few months supply of IPv4 addresses
at current consumption rates and would likely take years to accomplish.
It simply isn't a good use of ARIN resources to chase these last vestiges
of potentially available IPv4.

>> The next step would be for staff to institute voluntary or forced reclamation
>> procedures as required under section 12 after the audit, if the organization
>> is significantly out of compliance.
> 
> I'd be surprised if there will not be sufficient political capital for
> forced reclamation.  The political fallout necessary for that will follow
> address exhaustion and it will be shaped first by the press and then by
> the government.  We have not yet seen a "60 Minutes" show muckraking the
> large IPv4 squatters but, heads-up corporate marketing departments, you
> will likely need to move to damage control mode when the press picks up
> this story.  Nothing new here, just study the history of Enron,
> CountryWide, BP and other one-time beneficiaries of excessive
> deregulation and under-regulation for details.
> 
Maybe, or, maybe like most of the press so far, they'll simply state that
it's time to move to IPv6.

Pitchforks and torches parading against corporate America chanting
"Give back your integers" just doesn't strike me as a likely scenario here.

>> There really is not much that ARIN can do to change the way that IPv4
>> exhaustion impacts us. It is too late. About the only thing that would
>> help us through the IPv6 transition would be a massive educational
>> program by ARIN, starting with sessions for New York stock market analysts
>> who ask CEOs the tough questions when they present their quarterly
>> results.
> 
> "There really is not much that ARIN can do" does seem to be the case,
> today, except perhaps for planning a less disruptive transition to IPv6,
> emphasis on the "disruptive".
> 
ARIN issues addresses according to policies set by the community.
ARIN can and does reclaim addresses issued by ARIN in accordance with
policies set by the community. I'm not sure what you think ARIN can
do to make the transition to IPv6 less disruptive. Do you need addresses
you feel you can't get? I simply don't understand what aspect of
address assignment you are finding so disruptive in this transition.

Owen



From Keith at jcc.com  Fri Jul 30 18:21:44 2010
From: Keith at jcc.com (Keith W. Hare)
Date: Fri, 30 Jul 2010 18:21:44 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100730210224.C86DA2B2135@mx5.roble.com>
References: <mailman.5.1280419202.21239.arin-ppml@arin.net>
	<20100730210224.C86DA2B2135@mx5.roble.com>
Message-ID: <9db381cd2c27d1cdd8441205d36efb324c535063@jcc.com>

>This is likely to change, however, when there
>are no more IPv4 addresses to allocate and current 
>netblock owners begin milking their holdings for profit. 

When there are no more IPv4 addresses to allocate, I expect a Y2K-type reactionary hype with:

-- The world as we know it is going to end!
-- We have to fix this problem now!
-- Why didn't anyone warn us about this before?!?

There might even be congressional hearings where all sorts of experts testify about the crisis.

I expect that when ISPs start issuing only IPv6 addresses to customers, the companies with web sites that sell things will make sure their web sites support IPv6.

I really don't expect much of a market for IPv4 addresses -- I think it will be cheaper and simpler to implement IPv6 than to purchase or lease IPv4 addresses.

I'm sure that there will be a small number of companies that fail because they didn't anticipate and plan. 

In another year or two, I expect IPv6 to hit like a tsunami. Worrying about how many beach umbrellas there are or where they are placed isn't going to make any difference.

Keith Hare


______________________________________________________________
 
Keith W. Hare                     JCC Consulting, Inc.
keith at jcc.com                     600 Newark Road
Phone: 740-587-0157               P.O. Box 381
Fax: 740-587-0163                 Granville, Ohio 43023
http://www.jcc.com                USA
______________________________________________________________





From sean.copeland at ibips.com  Fri Jul 30 19:12:53 2010
From: sean.copeland at ibips.com (Sean Copeland)
Date: Fri, 30 Jul 2010 16:12:53 -0700
Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize
	IP Reassignment Registration Requirements
Message-ID: <07A90258-5152-4F9E-8E6E-81B0106456B1@ibips.com>

I support the petition/proposal 109

Sean Copeland

Managing Director
Business Intelligent Processing Systems PLC Registered Office | 5th  
Floor | Anglo International House | Bank Hill | North Quay | Douglas |  
Isle of Man | IM1 4QE
Telephone: +44 20 8588 0608 Ext 001 or +1 (888) 540-2112 Ext 001 Fax:  
+1 (866) 665-6386

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

From marquis at roble.com  Fri Jul 30 22:20:00 2010
From: marquis at roble.com (Roger Marquis)
Date: Fri, 30 Jul 2010 19:20:00 -0700 (PDT)
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100730141545.A77546@eboyr.pbz>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>
	<20100730141545.A77546@eboyr.pbz>
Message-ID: <20100731022000.92ACC2B2135@mx5.roble.com>

Owen DeLong wrote:
> Not sure why you think IPv6 is either infeasible or incorrect, given the
> large deployments actually operating with it.

The reasons IPv6 is currently infeasible for the overwhelming majority
have been gone over in detail and at length many times in this forum.
Anyone following these threads and still claiming to be "not sure" of the
impediments is either unsure by choice or playing rhetorical games.  The
rest of the connected world understands the drawbacks as the lack of IPv6
uptake over the past decade clearly illustrates.

Roger Marquis


From owen at delong.com  Sat Jul 31 14:39:42 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 31 Jul 2010 11:39:42 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100731022000.92ACC2B2135@mx5.roble.com>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>
	<20100730141545.A77546@eboyr.pbz>
	<20100731022000.92ACC2B2135@mx5.roble.com>
Message-ID: <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com>


On Jul 30, 2010, at 7:20 PM, Roger Marquis wrote:

> Owen DeLong wrote:
>> Not sure why you think IPv6 is either infeasible or incorrect, given the
>> large deployments actually operating with it.
> 
> The reasons IPv6 is currently infeasible for the overwhelming majority
> have been gone over in detail and at length many times in this forum.
> Anyone following these threads and still claiming to be "not sure" of the
> impediments is either unsure by choice or playing rhetorical games.  The
> rest of the connected world understands the drawbacks as the lack of IPv6
> uptake over the past decade clearly illustrates.


I didn't say I was unsure of the impediments. I said I was unsure why you
thought IPv6 was infeasible (it isn't) or incorrect (that's such a subjective
term in this context).

However, since you choose not to answer here, I'll go based on your
previous statements:

The lack of uptake for most people has little to do with the reasons you
have stated in the past.

The primary cause for lack of IPv6 uptake is quite simple... Organizational
Inertia. Other phrases that describe this commonly include:
	"If it ain't broke, don't fix it."
	"It's not a priority yet."

Lack of NAT really isn't a barrier to anyone who takes the time to actually
understand IPv6.

Address hiding can be accomplished quite easily by using privacy
address extensions as described in RFCs 3041 and 4941.

If you're worried about avoiding renumbering when you switch providers,
the answer is quite simple... Pick two.

Connect to two providers and apply for your space directly from ARIN.
You can get a /48 (or larger if you need) for less than the cost of a 
new medium-large NAT gateway as a one-time fee and a mere $100/year
thereafter.

This avoids all those pesky source address selection problems, too.

Oh, and the adoption of IPv6 is clearly accelerating at this time. My bet
is it will continue to do so and that we'll see pretty wide-spread deployment
in less than 2 years, with near ubiquity in about 4-5 years. I also think that
the post-runout IPv4 world is going to create a great deal of pressure to
deprecate IPv4 much sooner than most people think due to the high costs
of maintaining and routing it in an address-trading-market world where
at least one RIR is allowing people to buy and sell down to the /32.
Even in ARIN with /24 as the lower limit, a couple of As getting sold
off as /24s would mean 130,000 more prefixes in the routing table.

There are far too many organizations running IPv6 for me to believe that
it cannot be deployed.

Finally, IIRC, you were also claiming that anyone who needs to
pass PCI, SOX, HIPPA, or SAS70 audits needed NAT. My
understanding is that the PCIA is in the process of revising their
audit documentation to clarify that NAT is recommended (not
required) for IPv4 only. As to HIPPA and SOX, since each auditor
kind of makes up their own criteria as they go along, that's a much
harder education effort, but, neither regulation even mentions
NAT, topological obfuscation, or even address privacy.

That leave SAS70. I don't have enough familiarity with the
SAS70 process or even the governing organization that sets
standards for SAS70 audits to comment meaningfully. I suspect,
however, given the situation, they will likely be reviewing the
issue soon enough and remove NAT from their
audit specifications too.

Yes, IPv6 requires education. No, there are no insurmountable
problems remaining in IPv6. Yes, it has some warts and some
things that could have been done better. However, it's no worse
than IPv4, and, the lack of NAT makes it quite a bit better in many
ways.

Owen



From tedm at ipinc.net  Sat Jul 31 17:15:40 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Sat, 31 Jul 2010 14:15:40 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B4239180213B6@EMV01-UKBR.domain1.systemhost.net>
References: <C87376B6.A832%marty@akamai.com>	<alpine.GSO.2.00.1007262230300.17216@peermon.argfrp.us.uu.net>	<AANLkTinzctWJKTUxuc+CZc9PEzbKve4bDPT5Cj-WLOU5@mail.gmail.com>
	<0F29D1BA57992E4CAB5AD2C9AE7B4239180213B6@EMV01-UKBR.domain1.systemhost.net>
Message-ID: <4C54927C.90205@ipinc.net>



On 7/28/2010 1:32 AM, michael.dillon at bt.com wrote:
>> Let me offer a rude viewpoint to gauge reaction: the 4.10 addresses
>> shouldn't be available to the X-larges at all. Period. The X-larges
>> have vast tracts of IPv4 addresses from which they can find a few to
>> facilitate IPv4 function during the v6 transition. 4.10 addresses
>> should be for folks who didn't have a lot of v4 addresses to start
>> with and need just a few more to carry them through to v6 ubiiquity.
>
> What's rude about it? This is reality. All large ISPs have enough
> existing IPv4 space to keep their businesses humming even if they
> can't get more from ARIN.
>
> That doesn't mean that they currently have spare addresses stashed
> away, although I would expect that most do have sloppy decommissioning
> processes with the end result that they have addresses lost in the
> system. But the main source of IP addresses for these large ISPs is
> their existing customers. They will have high margin customers and
> low margin customers. It is not unusual for a large company to identify
> its low margin customers, and then contact them all to say that
> their service contracts will not be renewed and if the customer
> wants to cancel the contracts at any time, no penalty will be
> charged.
>
> Therefore, the large ISPs are able to mine their low margin customer
> base to recover IP addresses which can be used for continued growth
> of high margin customers. In some cases this kind of process will have
> other benefits. For instance, consider an ISP who installed lots of
> 75xx edge routers to sell T1 access. Over the years, the high margin
> customers have all upgraded. By shedding certain low margin customers
> they not only recover IP addresses, but they can get rid of those
> 75xx boxes freeing up rack space for 10Ks with a higher port density
> and greater flexibility.
>
> I believe that address recovery through internal churn is viable for
> all of the larger ISPs therefore I think that a policy which intends
> to limit the disruptive effect of IPv4 exhaustion would do better to
> focus exclusively on the smaller businesses who often have less
> flexible business models. I'm not saying that ARIN has a responsibility
> to protect these businesses from bankruptcy or buyout, but that a
> policy focused on lengthening the period of time during which these
> businesses can get IPv4 addresses, will generally ease the process
> of IPv6 transition. For one thing, it will make it more likely that
> these smaller businesses can buy IPv6 routers on the used market.

The cost of a BGP-capabable "name brand" router that speaks IPv6
is still up in the $5K range on the used market.

> And it will allow them to spread their investment in transition
> over a longer period which makes it more financially feasible.

I agree 100% with Michael, here.  The large ISPs despite public
protestations and proclamations, will have no trouble transitioning.
Most of their customer base is comprised of people who have NO OTHER
CHOICE.  Take Comcast, for example.  A majority of their subscribers
in the US have only ONE broadband provider choice - them.  Thus if
Comcast unilaterally decides to tell all customers that they must
use IPv6 and access the IPv4 Internet through Comcast-run IPv6-to-IPv4
"transparent" proxy servers, then most of their customer base will
scream - but they won't leave.  They are stuck with them.  The same
goes for verizon.net, qwest.net, frontier.com, etc. etc.  All of these
guys have a book of business built on a customer base that has nowhere
else to go.  And despite what you read about anti-trust law in the US,
there is no legal reason that all of those large ISP's cannot get 
together and agree on a single "screw the customer date" so that when
the "your going to use IPv6 or else" day comes along, their customers
have no competitor to go to that isn't already doing the same thing.

Thus, even without "mining the low-margin" customers,
the IPv4->IPv6 transition is not going to be much of a problem for
them.  They won't lose customers as a result, and the handful who
"protest quit" will slink back a few months later.

All of the "extend the usefulness of IPv4" projects that have been
proposed in the past are really only of applicability and concern to
the SMALL ISPs who do NOT have the capability of telling their
customers how it's gonna be.  They know that they have customers who
will have to have their IPv4 pried out of their cold, dead fingers.
And they are all sitting around wondering just how long the large
ISP's are going to fiddle-faddle around still offering IPv4.

God's honest truth is that it would benefit ALL isp's out there for
the large networks to have a "screw-the-customer" day where they
tell all customers that IPv6 is a requirement, much sooner rather than
much later.  If the large networks succeed in dragging out the 
IPv4->IPv6 transition for many years, it's going to kill the
smaller ISPs.  So, if your going to reserve IPv4, don't even ALLOW
the large ISPs to have access to it.

In the US we have standards for TV broadcast transmission, we have
standards for what a passenger car tire must be able to do.  Customers
do not have the choice to buy and run products that don't meet these
standards.  There is no reason on Earth that we cannot do the same thing 
with IP.  The customer should not be allowed to have any ability
to prolong IPv4 usage and the only reason they do is because the
large networks have figured out this is yet another way they can screw
over the smaller ISPs and take away their customers.

Ted


From tedm at ipinc.net  Sat Jul 31 17:29:37 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Sat, 31 Jul 2010 14:29:37 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>	<20100730141545.A77546@eboyr.pbz>	<20100731022000.92ACC2B2135@mx5.roble.com>
	<1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com>
Message-ID: <4C5495C1.2070404@ipinc.net>



On 7/31/2010 11:39 AM, Owen DeLong wrote:
>
> On Jul 30, 2010, at 7:20 PM, Roger Marquis wrote:
>
>> Owen DeLong wrote:
>>> Not sure why you think IPv6 is either infeasible or incorrect, given the
>>> large deployments actually operating with it.
>>
>> The reasons IPv6 is currently infeasible for the overwhelming majority
>> have been gone over in detail and at length many times in this forum.
>> Anyone following these threads and still claiming to be "not sure" of the
>> impediments is either unsure by choice or playing rhetorical games.  The
>> rest of the connected world understands the drawbacks as the lack of IPv6
>> uptake over the past decade clearly illustrates.
>
>
> I didn't say I was unsure of the impediments. I said I was unsure why you
> thought IPv6 was infeasible (it isn't) or incorrect (that's such a subjective
> term in this context).
>
> However, since you choose not to answer here, I'll go based on your
> previous statements:
>
> The lack of uptake for most people has little to do with the reasons you
> have stated in the past.
>
> The primary cause for lack of IPv6 uptake is quite simple... Organizational
> Inertia. Other phrases that describe this commonly include:
> 	"If it ain't broke, don't fix it."
> 	"It's not a priority yet."
>
> Lack of NAT really isn't a barrier to anyone who takes the time to actually
> understand IPv6.
>
> Address hiding can be accomplished quite easily by using privacy
> address extensions as described in RFCs 3041 and 4941.
>
> If you're worried about avoiding renumbering when you switch providers,
> the answer is quite simple... Pick two.
>
> Connect to two providers and apply for your space directly from ARIN.
> You can get a /48 (or larger if you need) for less than the cost of a
> new medium-large NAT gateway as a one-time fee and a mere $100/year
> thereafter.
>
> This avoids all those pesky source address selection problems, too.
>

There's no question that it's quite possible to deploy and use IPv6.
Unfortunately the largest wart IMHO is the lack of a standard for
distributing DNS server IP addresses via auto assignment.  You
take the position that NAT is awful, I find DHCPv6 to be far worse.

> Oh, and the adoption of IPv6 is clearly accelerating at this time. My bet
> is it will continue to do so and that we'll see pretty wide-spread deployment
> in less than 2 years, with near ubiquity in about 4-5 years.

I disagree unless you mean near ubiquity on the provider side.  It's 
going to be many, many years before the end-users start using it even
though their provider offers it.

> I also think that
> the post-runout IPv4 world is going to create a great deal of pressure to
> deprecate IPv4 much sooner than most people think

I hope this is true.

> There are far too many organizations running IPv6 for me to believe that
> it cannot be deployed.
>

And how many of those orgs are IPv6 ONLY?

>
> Yes, IPv6 requires education. No, there are no insurmountable
> problems remaining in IPv6. Yes, it has some warts and some
> things that could have been done better. However, it's no worse
> than IPv4, and, the lack of NAT makes it quite a bit better in many
> ways.
>

Please keep in mind that people who do not have experience with
enterprise networks, who are coming at this from a small company
perspective, where everyone is single-homed, simply do not understand
the difficulties that NAT introduces to multi-site WANs.  NAT
is the "poor man's firewall" to the single-homers and it is
deployed on millions of residential CPEs and works well on most of
them, so continuing to harp on how the lack of NAT is a benefit
to IPv6 goes completely over many people's heads.

Ted


From tedm at ipinc.net  Sat Jul 31 17:37:25 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Sat, 31 Jul 2010 14:37:25 -0700
Subject: [arin-ppml] Ending point to point links as a justification for
 a	/30?
In-Reply-To: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>
Message-ID: <4C549795.9030500@ipinc.net>



On 7/29/2010 11:34 AM, William Herrin wrote:
> On Wed, Jul 28, 2010 at 5:21 AM, Joe Maimon<jmaimon at chl.com>  wrote:
>> William Herrin wrote:
>>> I don't think we even give 'em point to point links. For the last /8
>>> the vendors can damn well fix their code to originate ICMP from the
>>> loop0 address instead of the RFC1918 address on the interface.
>>
>> I completely agree. That feature would be really lovely along with other
>> control plane traffic handling improvements and wider availability of proper
>> address abstraction off of the physical interface.
>
> How much support would there be for a policy proposal to exclude point
> to point links as a justification for any global IP addresses
> effective, say, 1/1/2012? Along with a stern recommendation from ARIN
> to the routing vendors that they update their software to prevent the
> non-availability of of addresses for point to point links from causing
> malfunctions with ICMP warnings and errors?
>

None from me.

We want the smaller providers to upgrade to IPv6 - for
quite a lot of them, that means throwing away working routers and
replacing them with working routers that have more ram and newer
firmware that supports IPv6.  They cannot afford or justify doing
this with new gear but we might get them to do it with used gear.

But you are NOT going to find affordable routers on the secondary
market that support some brand-new "fixed" code that uses the loop
address.  You can find affordable ones that support IPv6 but that's
probably going to be about it.

Ted


From bensons at queuefull.net  Sat Jul 31 19:51:14 2010
From: bensons at queuefull.net (Benson Schliesser)
Date: Sat, 31 Jul 2010 18:51:14 -0500
Subject: [arin-ppml] incentives are better than penalties
In-Reply-To: <4C521B31.7060303@chl.com>
References: <AANLkTinJF6psRJJic-CvV8ceianDCyjrtSObXiELxHqS@mail.gmail.com>	<4C51DBE8.9060108@chl.com>
	<4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com>
	<407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com>
	<4C521B31.7060303@chl.com>
Message-ID: <406393C0-F805-4FE6-A8AE-5D27D27BA0DB@queuefull.net>


On 29 Jul 2010, at 7:22 PM, Joe Maimon wrote:

> I am opposed to reclamation techniques that step up the confrontational and adversarial relationship between ARIN and address holders, even were it to be essential for continued consumption of IPv4 and IPv6 did not exist. I view increasing auditing and mandatory triggers of audits with similar concern.
> 
> Expending good will and buy in, not to mention financial resources, all for relatively limited return along with greater risks of legal and political liabilities is not a good bargain.
> 
> Bad cop is not a character role an organization like ARIN should choose to be identified with.
> 
> Incentives for efficiencies, that is where my support lands. Even then,  I prefer less direct incentives, those that can be spread and carried by the invisible hand.

Amen.

As ARIN participants we all represent two perspectives that may be at odds: the success of our organizations, and the ongoing function of the Internet.  The best way to achieve goals associated with the latter, is to create policy that simultaneously encourages the former.

More specifically, we must recognize that the audit and renumbering of existing IP allocations consumes resources.  Few member organizations are motivated to spend money on returning address space, because there is no ROI.  Creating policy that artificially penalizes organizations for the status quo (i.e. "stick") will only encourage the minimal response to avoid trouble, and may encourage deceit.  On the other hand, policy that motivates efficiency (i.e. "carrot") by assigning real value to number resources will encourage cooperation and inherently encourages organizations to make excess resources available.  A secondary benefit is that the differential in cost of plentiful IPv6 and scarce IPv4 will encourage faster take-up of IPv6.

The only organizations that don't benefit in this "carrot" approach are those that demand IPv4 addresses at essentially no cost.  ARIN and other RIRs should find a way to enable the subset of these organizations that exist for the benefit of the public.  The rest probably represent untenable enterprises, and can learn to accept reality.

I welcome anybody interested in collaborating on draft policy that embodies the "carrot" approach to contact me directly.

Cheers,
-Benson



From bensons at queuefull.net  Sat Jul 31 21:22:59 2010
From: bensons at queuefull.net (Benson Schliesser)
Date: Sat, 31 Jul 2010 20:22:59 -0500
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <20100730212814.848D82B213A@mx5.roble.com>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>
	<20100730212814.848D82B213A@mx5.roble.com>
Message-ID: <DB1679C3-D09B-4CE1-BC00-518382F410BD@queuefull.net>


On 30 Jul 10, at 4:28 PM, Roger Marquis wrote:

> Michael's perspective appears to be predicated on a thesis that
> Internet-routed IP addresses are private assets.  The legal precedent,
> OTOH, is more likely to see these addresses as public commons, similar to
> the radio frequency spectrum.

I think the comparison of IP to radio spectrum is a weak one.  A closer comparison might be found in phone numbers, but even that has significant structural differences.  The public interest in IP addresses is unique with its own nuances.

That said, we can learn from all of these comparisons.  Spectrum: the FCC uses a market approach (monetary value/cost) to make sure that spectrum is allocated efficiently.  Phone Numbers: number portability was imposed by the government, when large operators failed to cooperatively fix the barrier to entry that their control over numbers represented.

For IP we should strive to create a fair field of play, but that doesn't oblige us to artificially de-value address resources.  Accepting a thesis that IP addresses are "private assets" might actually benefit the community more than the alternative.

Cheers,
-Benson



From marty at akamai.com  Sat Jul 31 21:43:07 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Sat, 31 Jul 2010 21:43:07 -0400
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <9db381cd2c27d1cdd8441205d36efb324c535063@jcc.com>
Message-ID: <C87A496B.B675%marty@akamai.com>




On 7/30/10 6:21 PM, "Keith W. Hare" <Keith at jcc.com> wrote:

>> This is likely to change, however, when there
>> are no more IPv4 addresses to allocate and current
>> netblock owners begin milking their holdings for profit.
> 
> When there are no more IPv4 addresses to allocate, I expect a Y2K-type
> reactionary hype with:
> 
> -- The world as we know it is going to end!
> -- We have to fix this problem now!
> -- Why didn't anyone warn us about this before?!?
> 
> There might even be congressional hearings where all sorts of experts testify
> about the crisis.
> 
> I expect that when ISPs start issuing only IPv6 addresses to customers, the
> companies with web sites that sell things will make sure their web sites
> support IPv6.
> 
> I really don't expect much of a market for IPv4 addresses -- I think it will
> be cheaper and simpler to implement IPv6 than to purchase or lease IPv4
> addresses.
> 
> I'm sure that there will be a small number of companies that fail because they
> didn't anticipate and plan.
> 
> In another year or two, I expect IPv6 to hit like a tsunami. Worrying about
> how many beach umbrellas there are or where they are placed isn't going to
> make any difference.
> 


You might be right. Then again, I'd rather see ARIN be wrong in asserting
that there is going to be a significant economic problem related to the
inability of some to continue to grow with IPv4 is dual stack is going to be
the transition mechanism du jour than wrong in doing nothing.

The only reason that there would be any involvement by government is if they
are lobbied to do so. If we blow transition, the government is going to
become involved at some level. Hopefully it will be as observers more than
participants.


Best,

-M<



From owen at delong.com  Sat Jul 31 23:22:59 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 31 Jul 2010 20:22:59 -0700
Subject: [arin-ppml] Set aside round deux
In-Reply-To: <4C5495C1.2070404@ipinc.net>
References: <mailman.185.1280504892.17521.arin-ppml@arin.net>	<20100730141545.A77546@eboyr.pbz>	<20100731022000.92ACC2B2135@mx5.roble.com>
	<1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com>
	<4C5495C1.2070404@ipinc.net>
Message-ID: <CD8E9034-3A7D-42F5-8E39-3C2E2D137454@delong.com>


On Jul 31, 2010, at 2:29 PM, Ted Mittelstaedt wrote:

> 
> 
> On 7/31/2010 11:39 AM, Owen DeLong wrote:
>> 
>> On Jul 30, 2010, at 7:20 PM, Roger Marquis wrote:
>> 
>>> Owen DeLong wrote:
>>>> Not sure why you think IPv6 is either infeasible or incorrect, given the
>>>> large deployments actually operating with it.
>>> 
>>> The reasons IPv6 is currently infeasible for the overwhelming majority
>>> have been gone over in detail and at length many times in this forum.
>>> Anyone following these threads and still claiming to be "not sure" of the
>>> impediments is either unsure by choice or playing rhetorical games.  The
>>> rest of the connected world understands the drawbacks as the lack of IPv6
>>> uptake over the past decade clearly illustrates.
>> 
>> 
>> I didn't say I was unsure of the impediments. I said I was unsure why you
>> thought IPv6 was infeasible (it isn't) or incorrect (that's such a subjective
>> term in this context).
>> 
>> However, since you choose not to answer here, I'll go based on your
>> previous statements:
>> 
>> The lack of uptake for most people has little to do with the reasons you
>> have stated in the past.
>> 
>> The primary cause for lack of IPv6 uptake is quite simple... Organizational
>> Inertia. Other phrases that describe this commonly include:
>> 	"If it ain't broke, don't fix it."
>> 	"It's not a priority yet."
>> 
>> Lack of NAT really isn't a barrier to anyone who takes the time to actually
>> understand IPv6.
>> 
>> Address hiding can be accomplished quite easily by using privacy
>> address extensions as described in RFCs 3041 and 4941.
>> 
>> If you're worried about avoiding renumbering when you switch providers,
>> the answer is quite simple... Pick two.
>> 
>> Connect to two providers and apply for your space directly from ARIN.
>> You can get a /48 (or larger if you need) for less than the cost of a
>> new medium-large NAT gateway as a one-time fee and a mere $100/year
>> thereafter.
>> 
>> This avoids all those pesky source address selection problems, too.
>> 
> 
> There's no question that it's quite possible to deploy and use IPv6.
> Unfortunately the largest wart IMHO is the lack of a standard for
> distributing DNS server IP addresses via auto assignment.  You
> take the position that NAT is awful, I find DHCPv6 to be far worse.
> 
>> Oh, and the adoption of IPv6 is clearly accelerating at this time. My bet
>> is it will continue to do so and that we'll see pretty wide-spread deployment
>> in less than 2 years, with near ubiquity in about 4-5 years.
> 
> I disagree unless you mean near ubiquity on the provider side.  It's going to be many, many years before the end-users start using it even
> though their provider offers it.
> 
We shall see.  I suspect it will happen a lot faster than you expect due
to the pressure that will be brought to bear from strong economic 
incentives to deprecate IPv4.

>> I also think that
>> the post-runout IPv4 world is going to create a great deal of pressure to
>> deprecate IPv4 much sooner than most people think
> 
> I hope this is true.
> 
I see one of two things happening:

1.	The address market is a total flop, nobody wants to sell addresses
	at any price. Result: the need for addresses drives a strong and rapid
	shift towards IPv6.

or

2.	The address market is a wild success, /8s are deaggregated left
	and right and sold off as /24s everywhere. The routing table explodes.
	Creating a strong economic incentive to deprecate IPv4 just to keep
	the internet routable.

>> There are far too many organizations running IPv6 for me to believe that
>> it cannot be deployed.
>> 
> 
> And how many of those orgs are IPv6 ONLY?
> 
Who said anything about IPv6 only. Deployment of IPv6 does not depend
on deprecation of IPv4. Quite the opposite.

>> 
>> Yes, IPv6 requires education. No, there are no insurmountable
>> problems remaining in IPv6. Yes, it has some warts and some
>> things that could have been done better. However, it's no worse
>> than IPv4, and, the lack of NAT makes it quite a bit better in many
>> ways.
>> 
> 
> Please keep in mind that people who do not have experience with
> enterprise networks, who are coming at this from a small company
> perspective, where everyone is single-homed, simply do not understand
> the difficulties that NAT introduces to multi-site WANs.  NAT
> is the "poor man's firewall" to the single-homers and it is
> deployed on millions of residential CPEs and works well on most of
> them, so continuing to harp on how the lack of NAT is a benefit
> to IPv6 goes completely over many people's heads.

I have substantial experience with SOHO, small enterprise and
large enterprise networks as well as service provider networks
of just about any scale.

The fact that NAT is widespread does not mean we can't deploy
IPv6 without introducing that damage to IPv6. NAT is not the poor
man's firewall, just a case of ignorance on the part of the poor
man. The poor man's firewall is and has long been stateful
inspection with a default deny inbound policy for all traffic not
matching an existing state table entry. That works with or
without the address mangling of NAT. NAT, on the other hand,
does not work without stateful inspection.

NAT does cause problems even for the single-homed small
environment, whether those environments are aware of the
problems or not.

Owen