From viriato.pina at sapo.pt  Tue Jul  7 06:50:38 2009
From: viriato.pina at sapo.pt (viriato@aoredor.org)
Date: Tue,  7 Jul 2009 06:50:38 -0400 (EDT)
Subject: [arin-ppml] =?iso-8859-1?q?SABER_COMANDAR_E_SABER_INSTRUIR?=
Message-ID: <20090707114855.56DF3B4C.F57DC81@127.0.0.1>

MAIL ERROR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090707/dc01a88d/attachment.htm>

From jcurran at arin.net  Wed Jul  8 16:55:50 2009
From: jcurran at arin.net (John Curran)
Date: Wed, 8 Jul 2009 16:55:50 -0400
Subject: [arin-ppml] ARIN Candidate Questions Due 15 July!
References: <4A535835.8060709@arin.net>
Message-ID: <B3FE55AE-C3FB-48C2-9A26-65581B593C97@arin.net>

Public Policy Community -

     The ARIN Advisory Committee, NRO Number Council, and the ARIN
     Board of Trustees all serve important roles in the formation,  
review,
     and ratification of number resource policy.   At ARIN, we've  
provided
     an opportunity for members of the community to ask questions to the
     upcoming election candidates, and in this manner have more insight
     into these candidates' qualifications to be elected.

     Please submit questions as soon as possible, as the ARIN Nominating
     Committee needs to have sufficient time to review and finalize  
the list
     of questions that will be answered by candidates.   Questions,  
along
     with the candidate group that they are directed towards, may be  
sent
     to info at arin.net no later than 15 July 2009 (as described in the  
email
     below).

Thanks!
/John

John Curran
President and CEO
ARIN



Begin forwarded message:

> From: Member Services <info at arin.net>
> Date: July 7, 2009 10:14:13 AM EDT
> To: arin-announce at arin.net
> Subject: [arin-announce] ARIN Candidate Questions Due 15 July:  
> What's on your mind?
>
> Don't miss your chance to submit suggestions for new candidate  
> questions.
>
> [As sent on 17 June]
>
> In October 2009, 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 15 July 2009.
>
> 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:
>
> https://www.arin.net/participate/elections/ac.html#accv
> https://www.arin.net/participate/elections/board.html#botcv
> https://www.arin.net/participate/elections/nronumbercouncil.html#nccv
>
> The 2009 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 27 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,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
> _______________________________________________
> ARIN-Announce
> You are receiving this message because you are subscribed to
> the ARIN Announce Mailing List (ARIN-announce at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-announce
> 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/20090708/79c0068e/attachment.htm>

From arin-poc at ralph.net  Fri Jul 17 04:34:27 2009
From: arin-poc at ralph.net (VIAGRA Inc)
Date: Fri, 17 Jul 2009 07:14:27 -0120
Subject: [arin-ppml] UK Pharmacy Online Sale 80% OFF!
Message-ID: <001701ca06c7$5d9b0720$c842dd3e@IRISHA>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090717/862baed5/attachment.htm>
-------------- next part --------------
Welcome to WebMD

Dear arin-ppml at arin.net!Stimulate her better in any position Sign-up today! at http://pfohapon.cn

You are subscribed as arin-ppml at arin.net.
              		View and manage your WebMD http://pfohapon.cn newsletter preferences
             		Subscribe http://pfohapon.cn to more newsletters.
                	http://pfohapon.cn Change/update your email address.

WebMD Privacy Policy http://pfohapon.cn
WebMD Office of Privacy 1175 Peachtree Street, Suite 2400, Atlanta, GA 30361<br>? 2009 WebMD, LLC. All rights reserved.

From mueller at syr.edu  Mon Jul 20 04:38:56 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 20 Jul 2009 04:38:56 -0400
Subject: [arin-ppml] Spectrum and IP address reservations
Message-ID: <75822E125BCB994F8446858C4B19F0D77B233EF6@SUEX07-MBX-04.ad.syr.edu>

I forward information about a study conducted by NERA on spectrum auctions.
Not directly applicable to IP addresses, but has some relevance to current discussions about attempts to reserve resources for new entrants vs. incumbents. Bear in mind, of course, that the study was produced by Telus, an incumbent operator, and discount for that; the point is that we need to pay attention to the economic reasoning underlying the finding; which is that policies designed to "help" competitors can have unintended consequences that may encourage conslidation and higher prices.

________________________________


Dear ITS Colleague,

As you know, Industry Canada completed Canada?s advanced wireless services (AWS) spectrum auction in July 2008. A recent study that NERA conducted for the Canadian telecommunications company TELUS analyzed the auction, and found that it may have been distorted by the insertion of incompatible regulatory goals into the auction process.

NERA?s analysis showed that while the auction generated higher revenues than expected, the most important reason for this was due to arbitrage opportunities in the auction design generated by the regulator?s decision to set-aside 44 percent of the available spectrum for ?entrants? which, as defined, were as all qualified bidders except the three largest incumbent mobile operators. As evidenced in the UK 3G and other 3G auctions in the early 2000s, the resulting inflated spectrum prices can negatively affect competition as investors tend to sell their holdings when earnings decrease and/or debt ratings drop. In severe cases, it can lead to market exit or market consolidation, all of which has a direct effect on competition.

Our report urges regulators to carefully balance the costs and benefits of regulatory intervention, and includes suggestions for avoiding the problems in future auctions that we identified in the Canadian case. The report is available for free upon request at: www.nera.com<http://www.nera.com> . [snip]

_______________________________

Christian Dippon
Vice President

NERA
   Economic Consulting

One Front Street, Suite 2600

San Francisco, CA 94111
Tel: 1-415-291-1044, Fax: 1-415-291-1020
Mobile: 415-810-9246

Christian.Dippon at NERA.com
www.nera.com
www.telecomeconomics.com
_______________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090720/4cd181a2/attachment.htm>
-------------- next part --------------
_______________________________________________
its-l site list
its-l at lists.sjsu.edu
http://lists.sjsu.edu/mailman/listinfo/its-l

From rudi.daniel at gmail.com  Mon Jul 20 12:27:12 2009
From: rudi.daniel at gmail.com (Rudi Daniel)
Date: Mon, 20 Jul 2009 12:27:12 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 49, Issue 4
References: <mailman.1.1248105601.24756.arin-ppml@arin.net>
Message-ID: <8BDB8AFCBB154400813665AAA1CA87B2@RudiDaniel>

 Are you suggesting that this report may have relevance to IPv4 depletion? I 
get its relevance to regulatory bodies, indeed my own local NTRC should also 
be aware of it.
RudiD
----- Original Message ----- 
From: <arin-ppml-request at arin.net>
To: <arin-ppml at arin.net>
Sent: Monday, July 20, 2009 12:00 PM
Subject: ARIN-PPML Digest, Vol 49, Issue 4


> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>   1. Spectrum and IP address reservations (Milton L Mueller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Jul 2009 04:38:56 -0400
> From: Milton L Mueller <mueller at syr.edu>
> To: "ARIN PPL (arin-ppml at arin.net)" <arin-ppml at arin.net>
> Cc: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
> Subject: [arin-ppml] Spectrum and IP address reservations
> Message-ID:
> <75822E125BCB994F8446858C4B19F0D77B233EF6 at SUEX07-MBX-04.ad.syr.edu>
> Content-Type: text/plain; charset="windows-1252"
>
> I forward information about a study conducted by NERA on spectrum 
> auctions.
> Not directly applicable to IP addresses, but has some relevance to current 
> discussions about attempts to reserve resources for new entrants vs. 
> incumbents. Bear in mind, of course, that the study was produced by Telus, 
> an incumbent operator, and discount for that; the point is that we need to 
> pay attention to the economic reasoning underlying the finding; which is 
> that policies designed to "help" competitors can have unintended 
> consequences that may encourage conslidation and higher prices.
>
> ________________________________
>
>
> Dear ITS Colleague,
>
> As you know, Industry Canada completed Canada?s advanced wireless services 
> (AWS) spectrum auction in July 2008. A recent study that NERA conducted 
> for the Canadian telecommunications company TELUS analyzed the auction, 
> and found that it may have been distorted by the insertion of incompatible 
> regulatory goals into the auction process.
>
> NERA?s analysis showed that while the auction generated higher revenues 
> than expected, the most important reason for this was due to arbitrage 
> opportunities in the auction design generated by the regulator?s decision 
> to set-aside 44 percent of the available spectrum for ?entrants? which, as 
> defined, were as all qualified bidders except the three largest incumbent 
> mobile operators. As evidenced in the UK 3G and other 3G auctions in the 
> early 2000s, the resulting inflated spectrum prices can negatively affect 
> competition as investors tend to sell their holdings when earnings 
> decrease and/or debt ratings drop. In severe cases, it can lead to market 
> exit or market consolidation, all of which has a direct effect on 
> competition.
>
> Our report urges regulators to carefully balance the costs and benefits of 
> regulatory intervention, and includes suggestions for avoiding the 
> problems in future auctions that we identified in the Canadian case. The 
> report is available for free upon request at: 
> www.nera.com<http://www.nera.com> . [snip]
>
> _______________________________
>
> Christian Dippon
> Vice President
>
> NERA
>   Economic Consulting
>
> One Front Street, Suite 2600
>
> San Francisco, CA 94111
> Tel: 1-415-291-1044, Fax: 1-415-291-1020
> Mobile: 415-810-9246
>
> Christian.Dippon at NERA.com
> www.nera.com
> www.telecomeconomics.com
> _______________________________
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.arin.net/pipermail/arin-ppml/attachments/20090720/4cd181a2/attachment-0001.html>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: ATT00001.txt
> URL: 
> <http://lists.arin.net/pipermail/arin-ppml/attachments/20090720/4cd181a2/attachment-0001.txt>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 49, Issue 4
> **************************************** 



From mueller at syr.edu  Mon Jul 20 13:36:35 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 20 Jul 2009 13:36:35 -0400
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>

Hey, Tom,
I'm glad after some years of purporting to be an economics researcher you've finally discovered the standard textbook definition of perfect competition. Looks like my reading recommendations are indeed helpful.

If you want to bone up a bit more (the quote you cited was patronizing WB baby-talk for developing country regulators) here's a start: 
http://en.wikipedia.org/wiki/Perfect_competition 

> -----Original Message-----
> From: Tom Vest [mailto:tvest at eyeconomics.com]
> Sent: Monday, July 20, 2009 8:24 AM
> To: Milton L Mueller
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Spectrum and IP address reservations / More from
> NERA
> 
> Apropos my request for you to clarify, NERA also authored most of the
> content for World Bank InfoDev's (ICT Division) Telecom and ICT
> "regulation handbooks" and "toolkits". The former includes a section
> (Appendix B) on "THE ECONOMICS OF TELECOMMUNICATIONS PRICES AND
> COSTS," where I found the following, unabridged quote:
> 
> "This*, then, is the situation in the ideal competitive marketplace.
> For this efficient ideal to be realized, the market must meet a number
> of conditions. For instance, the market must have several sellers
> (suppliers) and buyers (consumers), with none so large that it can
> affect prices: no one can be dominant in the marketplace. In addition,
> there must be no significant externalities, loosely defined as
> spillover benefits or negative effects to/from other markets. There
> should also be free entry to and exit from the market. Finally, as
> mentioned above, this market should not be characterised by economies
> of scale.
> 
> Where *all* [[emphasis mine]] the conditions mentioned above are not
> present, the market will not generally produce socially-optimal
> results."
> 
> *This = theoretical overview of what basic neoclassical economics says
> about how supply and demand interact in a rule-free context.
> Full file online at: http://www.infodev.org/en/Publication.22.html
> 
> TV
> 
> Begin forwarded message:
> 
> > From: tvest at eyeconomics.com
> > Date: July 20, 2009 7:28:19 AM EDT
> > To: Milton Mueller <mueller at syr.edu>
> > Cc: address-policy-wg at ripe.net
> > Subject: Re: [address-policy-wg] Spectrum and IP address reservations
> >
> >
> > On Jul 20, 2009, at 4:38 AM, Milton L Mueller wrote:
> >
> >> I forward information about a study conducted by NERA on spectrum
> >> auctions.
> >> Not directly applicable to IP addresses, but has some relevance to
> >> current discussions about attempts to reserve resources for new
> >> entrants vs. incumbents. Bear in mind, of course, that the study
> >> was produced by Telus, an incumbent operator, and discount for
> >> that; the point is that we need to pay attention to the economic
> >> reasoning underlying the finding; which is that policies designed
> >> to "help" competitors can have unintended consequences that may
> >> encourage conslidation and higher prices.
> >
> > Hi Milton,
> >
> > Clarifying question: what are you referring to exactly by "policies
> > designed to 'help' competitors," and why are you choosing to reduce
> > the question of routing and addressing system openness to this one
> > narrow dimension? I (among others) have written a lot about the
> > importances of keeping the door open for "new entrants," but not all
> > new entrants are "competitors" -- nor is competition the only reason
> > for incumbent service providers (and everybody else) to regard such
> > openness as a critical institutional priority.
> >
> > To illustrate, I've never heard anyone claim that the *only* reason
> > why it was a good idea to move from NCP addressing to classful IP
> > was to enable competition. Ditto, the move from classful IP to CIDR;
> > then as before, the prospect of continuous competition (including
> > competition by emerging new entrants) was just one of many reasons
> > to support the preservation of addressing and routing system
> > openness. I'm assuming that whatever you find persuasive in this
> > NERA document would not also implicate those past policy choices,
> > because I don't think you'd find much sympathy for the idea that the
> > "unintended consequences" of those decisions were/are so bad that
> > they outweigh they *intended* consequences (i.e., a future with max.
> > 256 independent addressing and routing system participants).
> >
> > Since most of the subscribers to these lists are not economists, it
> > would be helpful if you could briefly summarize the "underlying
> > economic reasoning" that you find particularly compelling in this
> > study. If it was less onerous, I'd also request that you clarify
> > what you regard to be the right way to balance intended vs.
> > unintended policy choices, and "historically/experientially
> > informed" vs. "idealized, theoretically informed" expectations about
> > the future -- but perhaps a sentence or two of clarification on the
> > NERA "reasoning" would suffice.
> >
> > Thanks,
> >
> > TV



From tedm at ipinc.net  Mon Jul 20 13:48:21 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 20 Jul 2009 10:48:21 -0700
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A64ADE5.1020202@ipinc.net>


Hello!  Clue phone ringing!!!

The current global recession has destroyed the last 50 years
of economic theory.  According to the supply-siders, it couldn't
have happened.  According to all the other economists, we aren't
in a depression.

At this point, anyone citing economic theory of any kind as
justification for an argument immediately forfeits all credibility.

Ted

Milton L Mueller wrote:
> Hey, Tom,
> I'm glad after some years of purporting to be an economics researcher you've finally discovered the standard textbook definition of perfect competition. Looks like my reading recommendations are indeed helpful.
> 
> If you want to bone up a bit more (the quote you cited was patronizing WB baby-talk for developing country regulators) here's a start: 
> http://en.wikipedia.org/wiki/Perfect_competition 
> 
>> -----Original Message-----
>> From: Tom Vest [mailto:tvest at eyeconomics.com]
>> Sent: Monday, July 20, 2009 8:24 AM
>> To: Milton L Mueller
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Spectrum and IP address reservations / More from
>> NERA
>>
>> Apropos my request for you to clarify, NERA also authored most of the
>> content for World Bank InfoDev's (ICT Division) Telecom and ICT
>> "regulation handbooks" and "toolkits". The former includes a section
>> (Appendix B) on "THE ECONOMICS OF TELECOMMUNICATIONS PRICES AND
>> COSTS," where I found the following, unabridged quote:
>>
>> "This*, then, is the situation in the ideal competitive marketplace.
>> For this efficient ideal to be realized, the market must meet a number
>> of conditions. For instance, the market must have several sellers
>> (suppliers) and buyers (consumers), with none so large that it can
>> affect prices: no one can be dominant in the marketplace. In addition,
>> there must be no significant externalities, loosely defined as
>> spillover benefits or negative effects to/from other markets. There
>> should also be free entry to and exit from the market. Finally, as
>> mentioned above, this market should not be characterised by economies
>> of scale.
>>
>> Where *all* [[emphasis mine]] the conditions mentioned above are not
>> present, the market will not generally produce socially-optimal
>> results."
>>
>> *This = theoretical overview of what basic neoclassical economics says
>> about how supply and demand interact in a rule-free context.
>> Full file online at: http://www.infodev.org/en/Publication.22.html
>>
>> TV
>>
>> Begin forwarded message:
>>
>>> From: tvest at eyeconomics.com
>>> Date: July 20, 2009 7:28:19 AM EDT
>>> To: Milton Mueller <mueller at syr.edu>
>>> Cc: address-policy-wg at ripe.net
>>> Subject: Re: [address-policy-wg] Spectrum and IP address reservations
>>>
>>>
>>> On Jul 20, 2009, at 4:38 AM, Milton L Mueller wrote:
>>>
>>>> I forward information about a study conducted by NERA on spectrum
>>>> auctions.
>>>> Not directly applicable to IP addresses, but has some relevance to
>>>> current discussions about attempts to reserve resources for new
>>>> entrants vs. incumbents. Bear in mind, of course, that the study
>>>> was produced by Telus, an incumbent operator, and discount for
>>>> that; the point is that we need to pay attention to the economic
>>>> reasoning underlying the finding; which is that policies designed
>>>> to "help" competitors can have unintended consequences that may
>>>> encourage conslidation and higher prices.
>>> Hi Milton,
>>>
>>> Clarifying question: what are you referring to exactly by "policies
>>> designed to 'help' competitors," and why are you choosing to reduce
>>> the question of routing and addressing system openness to this one
>>> narrow dimension? I (among others) have written a lot about the
>>> importances of keeping the door open for "new entrants," but not all
>>> new entrants are "competitors" -- nor is competition the only reason
>>> for incumbent service providers (and everybody else) to regard such
>>> openness as a critical institutional priority.
>>>
>>> To illustrate, I've never heard anyone claim that the *only* reason
>>> why it was a good idea to move from NCP addressing to classful IP
>>> was to enable competition. Ditto, the move from classful IP to CIDR;
>>> then as before, the prospect of continuous competition (including
>>> competition by emerging new entrants) was just one of many reasons
>>> to support the preservation of addressing and routing system
>>> openness. I'm assuming that whatever you find persuasive in this
>>> NERA document would not also implicate those past policy choices,
>>> because I don't think you'd find much sympathy for the idea that the
>>> "unintended consequences" of those decisions were/are so bad that
>>> they outweigh they *intended* consequences (i.e., a future with max.
>>> 256 independent addressing and routing system participants).
>>>
>>> Since most of the subscribers to these lists are not economists, it
>>> would be helpful if you could briefly summarize the "underlying
>>> economic reasoning" that you find particularly compelling in this
>>> study. If it was less onerous, I'd also request that you clarify
>>> what you regard to be the right way to balance intended vs.
>>> unintended policy choices, and "historically/experientially
>>> informed" vs. "idealized, theoretically informed" expectations about
>>> the future -- but perhaps a sentence or two of clarification on the
>>> NERA "reasoning" would suffice.
>>>
>>> Thanks,
>>>
>>> TV
> 
> _______________________________________________
> 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 lear at cisco.com  Mon Jul 20 14:05:13 2009
From: lear at cisco.com (Eliot Lear)
Date: Mon, 20 Jul 2009 20:05:13 +0200
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <4A64ADE5.1020202@ipinc.net>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<4A64ADE5.1020202@ipinc.net>
Message-ID: <4A64B1D9.9020208@cisco.com>

On 7/20/09 7:48 PM, Ted Mittelstaedt wrote:
> At this point, anyone citing economic theory of any kind as
> justification for an argument immediately forfeits all credibility.

Even though current theories of economics perfectly describe the 
behaviors of individuals and companies regarding address assignment and 
allocation?  Ted, anyone who has read this list for more than a week 
knows that Milton and Tom disagree fundamentally on a number of points.  
Learned people do that.  That gives us the opportunity to listen to the 
arguments, shrill though they might be at times, use our heads, and 
decide for ourselves.  Any economist of any value could have predicted 
our current situation, given the current policies.  We have not, until 
recently, invited them to the table to listen.  You are suggesting that 
we now disinvite them?

Eliot


From martin.hannigan at batelnet.bs  Mon Jul 20 20:49:43 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 20 Jul 2009 20:49:43 -0400
Subject: [arin-ppml] Spectrum and IP address reservations / More from
	NERA
In-Reply-To: <4A64ADE5.1020202@ipinc.net>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<4A64ADE5.1020202@ipinc.net>
Message-ID: <4607e1d50907201749k2a766a9cr7fc37d8c857c71bb@mail.gmail.com>

On Mon, Jul 20, 2009 at 1:48 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>
> Hello! ?Clue phone ringing!!!
>
> The current global recession has destroyed the last 50 years
> of economic theory. ?According to the supply-siders, it couldn't
> have happened. ?According to all the other economists, we aren't
> in a depression.
>
> At this point, anyone citing economic theory of any kind as
> justification for an argument immediately forfeits all credibility.
>
> Ted
>


Hi Ted,

Milton Mueller has been around for awhile and has credibility from my
perspective. There are people that I read and then there are people
that I filter. I read Milton. I've also read one of his books; Ruling
the Root. I found them to be intelligent and thought provoking. I also
tend to agree with him on social policy more than not. He seems like a
fairly smart person, much like Tom Vest. Both of whom I would
recommend paying close attention to.

Best Regards,

Martin


From mueller at syr.edu  Tue Jul 21 03:43:00 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 21 Jul 2009 03:43:00 -0400
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>


> I'm not even sure what you're trying to imply here. 
> NERA is the authority that *you* first chose to recommend, 
> when (as you explained) their findings indirectly supported 
> the position that you've clearly staked out in all of the 
> IPv4 transfer/market/privatization debates (and perhaps

Tom, 
On the NERA report, it makes some interesting points, and has some relevance to current ip address debates about reservations for "new entrants" as the free pool shrinks. And generally, I think it useful to use spectrum allocation as a pool of policy experience with relevance to ip addressing. 

That's all. 

I am not citing NERA as an unqualified authority; I did not say that it supported "my position" on anything; this particular report has nothing to do with the transfer market debate; the fact that you see anyone who uses economic theory as being a monolithic school of anarcho-objectivists is your problem, not mine. 

I do remain genuinely shocked at the fact that you displayed ignorance of basic perfect competition theory, and that you are unaware of how people have been debating its limitations and uses for decades. That's something we can take up later.

I can' resist one OT response:

> -----Original Message-----
> 
> looking belief, your  textbook Cato / von Mises / anarcho-objectivist

So many errors. You are really stuck in an ideological bog. I don't have time to clear it up for you on a public list, and besides, it would be boring if not downright rude to subject the rest of the list to extended talk about that when it's connection to address policy is tangential.

Mises wasn't an anarchist, and the Cato folks are more like Milton Friedman than von Mises, and neither are anarchists. You've got me misidentified, too. Ask the Misesians and anarcho-objectivists whether I am one of them. Better yet, ask Paul Vixie, a longtime devotee of Ayn Rand. If you don't understand the difference between Hayek/Popper-style empirical skepticism and von Mises/Rand deductive rationalism, it's your problem. Don't make it my problem, and above all, don't make it ARIN's. Do your homework.

Maybe it's a cultural difference, but researchers generally send papers around that are "of interest" and these actions do not imply general agreement with worldview or even the findings. If this is really a public policy list it might behoove you to get more into that culture of sharing and exchanging ideas about public policy rather than professing shock when you come up against something that differs from your own ideology and then engaging in stereotyping campaigns. 



From tvest at eyeconomics.com  Tue Jul 21 06:04:09 2009
From: tvest at eyeconomics.com (tvest at eyeconomics.com)
Date: Tue, 21 Jul 2009 06:04:09 -0400
Subject: [arin-ppml] Spectrum and IP address reservations / More from
	NERA
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <2CE11001-4380-422D-A3FB-D81B49AA0C44@eyeconomics.com>


On Jul 21, 2009, at 3:43 AM, Milton L Mueller wrote:

>
>> I'm not even sure what you're trying to imply here.
>> NERA is the authority that *you* first chose to recommend,
>> when (as you explained) their findings indirectly supported
>> the position that you've clearly staked out in all of the
>> IPv4 transfer/market/privatization debates (and perhaps
>
> Tom,
> On the NERA report, it makes some interesting points, and has some  
> relevance to current ip address debates about reservations for "new  
> entrants" as the free pool shrinks. And generally, I think it useful  
> to use spectrum allocation as a pool of policy experience with  
> relevance to ip addressing.
>
> That's all.
>
> I am not citing NERA as an unqualified authority; I did not say that  
> it supported "my position" on anything; this particular report has  
> nothing to do with the transfer market debate; the fact that you see  
> anyone who uses economic theory as being a monolithic school of  
> anarcho-objectivists is your problem, not mine.
>
> I do remain genuinely shocked at the fact that you displayed  
> ignorance of basic perfect competition theory, and that you are  
> unaware of how people have been debating its limitations and uses  
> for decades. That's something we can take up later.

Skipping past the diversionary chaff, I'll just observe that  
"disinclination to use" does not imply "ignorance of" (e.g., a  
particular family of theories). You may notice that I also don't  
reference phlogiston or phrenology-based theories to justify or  
criticize address policy, nor do I feel compelled to reference critics  
of those theories to justify my general inattention to them in this  
context. In all three cases, there's not much of use that can be  
constructively applied here, so why waste everybody's time?

> I can' resist one OT response:
>
>> -----Original Message-----
>>
>> looking belief, your  textbook Cato / von Mises / anarcho-objectivist
>
> So many errors. You are really stuck in an ideological bog. I don't  
> have time to clear it up for you on a public list, and besides, it  
> would be boring if not downright rude to subject the rest of the  
> list to extended talk about that when it's connection to address  
> policy is tangential.
>
> Mises wasn't an anarchist, and the Cato folks are more like Milton  
> Friedman than von Mises, and neither are anarchists. You've got me  
> misidentified, too. Ask the Misesians and anarcho-objectivists  
> whether I am one of them. Better yet, ask Paul Vixie, a longtime  
> devotee of Ayn Rand. If you don't understand the difference between  
> Hayek/Popper-style empirical skepticism and von Mises/Rand deductive  
> rationalism, it's your problem. Don't make it my problem, and above  
> all, don't make it ARIN's. Do your homework.

I understand the differences, and am aware of your drift between the  
various schismatic political movements. I was summarizing, not  
conflating.
Regardless, in the end the vast (methodological) differences that you  
would prefer to focus on -- e.g., between the Miseans and the  
Friedmanites et al. -- make little difference in terms of  
(substantive, pragmatic) policy differences that are relevant to this  
discussion. To most people (i.e., probably all but the members of one  
of the other schismatic quasi-libertarian groups) it's not going to  
matter much in the end whether you reject all non-market decision  
making mechanisms because the pursuit of pure freedom or the will to  
power compels you to do so, or because you know a priori that all  
other institutions are always inherently (more) corrupt, or because  
you can produce a simple model that shows that in, all cases, even the  
worst market-imposed abuse could never be as bad as even the best  
possible nonmarket-based alternative. In the end, it doesn't matter  
what precise point within that range of views you currently occupy,  
because all of them exist at the far extreme of the spectrum of  
political (or if you prefer, the "policy sympathetic") orientations,  
separated by a vast gulf from the range of views that allow for some  
(maybe a little, maybe a lot) legitimate scope for coordinated, non  
market-based decision making.

> Maybe it's a cultural difference, but researchers generally send  
> papers around that are "of interest" and these actions do not imply  
> general agreement with worldview or even the findings. If this is  
> really a public policy list it might behoove you to get more into  
> that culture of sharing and exchanging ideas about public policy  
> rather than professing shock when you come up against something that  
> differs from your own ideology and then engaging in stereotyping  
> campaigns.


Your recurring faith in the forgetfulness of other list members never  
fails to surprise me. But I'm game (again).

I am happy to resume our stereotyping-free discussion of address  
policy by thanking you for responding to the questions that I posed  
earlier. I would have been happy for more direct responses, but no  
matter...

Regards,

TV






From info at arin.net  Tue Jul 21 10:42:38 2009
From: info at arin.net (Member Services)
Date: Tue, 21 Jul 2009 10:42:38 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
Message-ID: <4A65D3DE.2040303@arin.net>

On 16 July 2009 the ARIN Advisory Council (AC) held a meeting and made
decisions about several policy proposals and draft policies.

The AC selected the following proposal and promoted it to a draft policy
for adoption discussion. It will be posted shortly to the PPML.

   Policy Proposal 84: IPv6 Multiple Discrete Networks

The AC accepted the following proposals onto the AC's docket for
development and evaluation:

   Policy Proposal 96: Transfer Listing Service
   Policy Proposal 97: Waiting List for Unmet IPv4 Requests

The AC abandoned the following policy proposal:

   Policy Proposal 87: Extend 16 bit ASN Assignments

The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
abandoned by the AC because the ARIN staff has now made an
implementation plan to combine both sets of numbers into one pool, and
issue in numerical order starting with the lowest numbers first
(starting in January 2010). With this plan in place the intention of
this proposal is addressed and the need for this proposal no longer
exists."

The AC's decision to abandon proposal 87 can be petitioned. The purpose
of a petition at this stage would be to advance it as draft policy for
discussion on the Public Policy Mailing List and at the October meeting.
The deadline to begin a petition for this proposal is 28 July 2009. For
more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)






From info at arin.net  Tue Jul 21 10:45:48 2009
From: info at arin.net (Member Services)
Date: Tue, 21 Jul 2009 10:45:48 -0400
Subject: [arin-ppml] Draft Policy 2009-5: IPv6 Multiple Discrete Networks
Message-ID: <4A65D49C.7050407@arin.net>

Draft Policy 2009-5
IPv6 Multiple Discrete Networks

On 16 July 2009 the ARIN Advisory Council (AC) selected "Draft Policy
2009-5: IPv6 Multiple Discrete Networks" for adoption discussion on the
PPML and at the Public Policy Meeting in Dearborn.

The draft was developed by the AC from "Policy Proposal 84. IPv6
Multiple Discrete Networks". Per the Policy Development Process the AC
submitted text to ARIN for a staff and legal assessment prior to
selection as a draft policy. After review of the assessment the text was
revised (item 5 was added to the text). The assessment, along with the
original text that was assessed, is located below the draft policy.

You are encouraged to discuss Draft Policy 2009-5 on the PPML prior to
the ARIN XXIV 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 regarding adopting this as policy.

Draft Policy 2009-5 is below and can be found at:
https://www.arin.net/policy/proposals/2009_5.html

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2009-5
IPv6 Multiple Discrete Networks

Version/Date: 21 July 2009

Policy statement:

Organizations with multiple discrete IPv6 networks desiring to request
new or additional address space under a single Organization ID must meet
the following criteria:

   1. The organization shall be a single entity and not a consortium of
      smaller independent entities.
   2. The organization must have compelling criteria for creating
      discrete networks.
      Examples of a discrete network might include:
          * Regulatory restrictions for data transmission,
          * Geographic distance and diversity between networks,
          * Autonomous multihomed discrete networks.
   3. The organization must keep detailed records on how it has
      allocated space to each location, including the date of each
      allocation.
   4. The organization should notify ARIN at the time of the request
      their desire to apply this policy to their account.
   5. Requests for additional space:

       a. Organization must specify on the application which discreet
network(s) the request applies to.

       b. Each network will be judged against the existing utilization
criteria specified in 6.5.2 as if it were a separate organization,
rather than collectively as would be done for requests outside of this
policy.

Rationale:

This proposed policy is suggested as NRPM 6.11.

The policy is intended to provide parity between current IPv4 policy and
allow discrete network operators to obtain IPv6 space.

Timetable for implementation: Immediately


#####


Staff Assessment

Proposal: IPv6 Multiple Discrete Networks

Date of Assessment: 7 July 2009

Text assessed: 23 June 2009

1. Summary (Staff Understanding)

This proposal would allow network operators to request /32s (ISPs) or
/48s (End-users), or larger blocks as justified, for each of their
discrete networks. They would first need to meet current policy criteria
for initial IPv6 allocations or assignments as described in NRPM section
6.5.1 or section 6.5.8 (as appropriate). The organization must have
compelling criteria to create discrete networks, must keep detailed
records, and must tell ARIN at the beginning of the request that they
are applying under this policy.

2. Comments

A. ARIN Staff Comments

    * The proposal says that it is for requesting new or additional
      address space, but it does not include criteria for additional
      requests. This means that staff would likely have to revert to
      existing NRPM 6.5.2 criteria for requesting additional IPv6
      address space.
    * This policy creates no significant operational impact and would
      require very little staff time or effort to implement.
    * This policy could be utilized by network operators running
      multiple discrete networks who in the past, may have been denied
      under current policy and/or forced to open multiple accounts to
      accomplish their goals.

B. ARIN General Counsel

    * Counsel saw no issues with this proposal.

3. Resource Impact

This policy would have minimal resource impact. It is estimated that
implementation would occur within three months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:

    * Updated guidelines
    * Staff training

4. Proposal Text

Proposal: IPv6 Multiple Discrete Networks

Version/Date: 23 June 2009

Organizations with multiple discrete IPv6 networks desiring to request
new or additional address space under a single Organization ID must meet
the following criteria:

1. The organization shall be a single entity and not a consortium of
smaller independent entities.

2. The organization must have compelling criteria for creating discrete
networks. Examples of a discrete network might include:

a. Regulatory restrictions for data transmission,

b. Geographic distance and diversity between networks,

c. Autonomous multihomed discrete networks.

3. The organization must keep detailed records on how it has allocated
space to each location, including the date of each allocation.

4. The organization should notify ARIN at the time of the request their
desire to apply this policy to their account.

Rationale:

This proposed policy is suggested as NRPM 6.11. The policy is intended
to provide parity between current IPv4 policy and allow discrete network
operators to obtain IPv6 space.








From celestea at usc.edu  Tue Jul 21 11:11:19 2009
From: celestea at usc.edu (Celeste Anderson)
Date: Tue, 21 Jul 2009 08:11:19 -0700
Subject: [arin-ppml] Fwd: Draft Policy 2009-5: IPv6 Multiple Discrete
	Networks
Message-ID: <f9fca01060ff.4a657827@usc.edu>

I am curious as to why a consortium of smaller independent entities is excluded from this policy.  I apologize if I missed this in a previous discussion. 

--celeste.
-------------- next part --------------
An embedded message was scrubbed...
From: Member Services <info at arin.net>
Subject: [arin-ppml] Draft Policy 2009-5: IPv6 Multiple Discrete Networks
Date: Tue, 21 Jul 2009 10:45:48 -0400
Size: 9531
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090721/e5daee05/attachment.eml>

From spiffnolee at yahoo.com  Tue Jul 21 11:06:20 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Tue, 21 Jul 2009 08:06:20 -0700 (PDT)
Subject: [arin-ppml] Spectrum and IP address reservations / More from
	NERA
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <997551.95719.qm@web63304.mail.re1.yahoo.com>






----- Original Message ----
> From: Milton L Mueller <mueller at syr.edu>
> To: "tvest at eyeconomics.com" <tvest at eyeconomics.com>
> Cc: ARIN PPML <ppml at arin.net>
> Sent: Tuesday, July 21, 2009 3:43:00 AM
> Subject: Re: [arin-ppml] Spectrum and IP address reservations / More from NERA
> 
> 
> > I'm not even sure what you're trying to imply here. 
> > NERA is the authority that *you* first chose to recommend, 
> > when (as you explained) their findings indirectly supported 
> > the position that you've clearly staked out in all of the 
> > IPv4 transfer/market/privatization debates (and perhaps
> 
> Tom, 
> On the NERA report, it makes some interesting points, and has some relevance to 
> current ip address debates about reservations for "new entrants" as the free 
> pool shrinks. And generally, I think it useful to use spectrum allocation as a 
> pool of policy experience with relevance to ip addressing. 

Looked to me like Tom's point was that the report said, "These findings are not
relevant [in cases like this]."  

> I am not citing NERA as an unqualified authority; I did not say that it 
> supported "my position" on anything; this particular report has nothing to do 
> with the transfer market debate; 

I probably missed your point then.  Would you clarify how this report is 
interesting to this community, if not in the context of IP address transfer markets?

> I do remain genuinely shocked at the fact that you displayed ignorance of basic 
> perfect competition theory, and that you are unaware of how people have been 
> debating its limitations and uses for decades. That's something we can take up 
> later.

I don't see where he displayed ignorance, and I'm annoyed at the general tone
of your comments.  Please help to maintain the tone of professional respect on
this list.  One way to do that is that if someone seems not to understand 
something that's important to the policy discussion, check whether you have a
common understanding of the terms.

> Maybe it's a cultural difference, but researchers generally send papers around 
> that are "of interest" and these actions do not imply general agreement with 
> worldview or even the findings.

Sure, and one appropriate comment on such papers is, "Interesting, but because
of this section, it isn't as relevant as it otherwise might be."


>  ideas about 
> public policy rather than professing shock when you come up against something 
> that differs from your own ideology and then engaging in stereotyping campaigns. 

Tom is not the professor of shock in this thread.

Lee


      



From mueller at syr.edu  Tue Jul 21 12:38:46 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 21 Jul 2009 12:38:46 -0400
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <997551.95719.qm@web63304.mail.re1.yahoo.com>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>,
	<997551.95719.qm@web63304.mail.re1.yahoo.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B233EFA@SUEX07-MBX-04.ad.syr.edu>


> Looked to me like Tom's point was that the report said, "These findings are not
> relevant [in cases like this]."

I guess you haven't read the report then. And you won't, will you?

> I probably missed your point then.  Would you clarify how this report is
> interesting to this community, if not in the context of IP address transfer markets?

Don't have time to do your work for you, Lee. If you want to read it, read it. If you don't, don't. 
A sentence in the original thread indicated enough about what I thought its relevance was.  

> I don't see where he displayed ignorance

He did. He covered it up pretty nicely, mainly by trying to divert attention to ideological classification, as usual, but he did. No need to dwell on that. I'm not interested in discussing tom.

I _am_ interested in advancing list engagement with what is obviously an unfamiliar concept: perfect competition. 

The concept of perfect competition is deliberately used as an ideal-typical situation for modeling purposes. Neoclassical policy analysts are fully aware of its strict assumptions (and btw the non-neoclassical Austrians tom is fond of lumping them with don't even believe in that kind of modeling and reject equilibrium economics altogether). Anyway, to suggest that a model such as that has no use whatsoever because no situation in reality conforms to it perfectly is very much like saying we can throw out geometry because there is no such thing as a perfect sphere or a truly straight line. In fact, you learn interesting things about the real world by comparing it to ideal-typical models and trying to posit what accounts for the differences and similarities. 

The main difference between economists and noneconomists in this case is that the economists were rigorous and honest enough to specify their assumptions clearly. On the other hand, the advocates of nonmarket resource allocation policies are often making equally strict and bizarre assumptions about human behavior, but their theories are often too flaccid to specify what those assumptions are, and so they are unable to derive good models of their implications. For example, when people say you can fix market imperfections by "regulating" the market, are they not assuming that: 
 * the regulator has perfect knowledge about the actors in the market and everything they do
 * the people who do the regulation will not exploit their position for their own benefit
 * regulators are never politically or personally motivated to show favoritism in the application of the rules (e.g., not prosecuting Madoff after two notifications)  
 * etc., etc.?  

> Please help to maintain the tone of professional respect on this list.

Way off target, Lee. If you had any sense of professional discourse and objectivity, you'd recognize that it was Tom who dragged this thread into to the mud. I'll take your comments seriously when you apply the same standards to people who say things that stroke you preconceptions as you do to people who's ideas challenge your own. I simply posted a report for people to read. 

--MM

From martin.hannigan at batelnet.bs  Tue Jul 21 14:26:47 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 21 Jul 2009 14:26:47 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4A65D3DE.2040303@arin.net>
References: <4A65D3DE.2040303@arin.net>
Message-ID: <4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>

> The AC abandoned the following policy proposal:
>
> ?Policy Proposal 87: Extend 16 bit ASN Assignments
>
> The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
> abandoned by the AC because the ARIN staff has now made an
> implementation plan to combine both sets of numbers into one pool, and
> issue in numerical order starting with the lowest numbers first
> (starting in January 2010). With this plan in place the intention of
> this proposal is addressed and the need for this proposal no longer
> exists."


Can someone explain how this will work please?

Best Regards,

Martin Hannigan


From scottleibrand at gmail.com  Tue Jul 21 14:42:22 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 21 Jul 2009 11:42:22 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
Message-ID: <4A660C0E.1070605@gmail.com>

Martin Hannigan wrote:
>> The AC abandoned the following policy proposal:
>>
>>  Policy Proposal 87: Extend 16 bit ASN Assignments
>>
>> The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
>> abandoned by the AC because the ARIN staff has now made an
>> implementation plan to combine both sets of numbers into one pool, and
>> issue in numerical order starting with the lowest numbers first
>> (starting in January 2010). With this plan in place the intention of
>> this proposal is addressed and the need for this proposal no longer
>> exists."
>>     
>
>
> Can someone explain how this will work please?
>   

I can try, and I'm sure someone will correct me if I'm wrong...

Up until January 1 2010, ARIN distinguishes between 2-byte and 4-byte 
ASNs, and lets you have a 2-byte if you need it, but gives out 4-bytes 
otherwise, to spur adoption.

After January 1 2010, ARIN ceases to make any distinction between 2-byte 
and 4-byte ASNs.  Instead, they simply give out ASNs as they always 
have, working up from the bottom.  At first, the ASNs given out will be 
<64k.  Eventually, when that block of ASNs is used up, they'll move on 
to higher numbers >64k.  Presumably by then everyone with a growing 
network will have rolled out code to support 4-byte ASNs.

-Scott


From scottleibrand at gmail.com  Tue Jul 21 14:47:45 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 21 Jul 2009 11:47:45 -0700
Subject: [arin-ppml] Fwd: Draft Policy 2009-5: IPv6 Multiple Discrete
 Networks
In-Reply-To: <f9fca01060ff.4a657827@usc.edu>
References: <f9fca01060ff.4a657827@usc.edu>
Message-ID: <4A660D51.7080903@gmail.com>

It looks like that was carried over from the IPv4 Multiple Discrete 
Networks policy (https://www.arin.net/policy/nrpm.html#four5).

If several smaller entities each need addresses for separate networks, 
they should apply independently as separate organizations.  If a single 
organization runs multiple discrete networks, they can't apply for space 
for each network independently, so this policy is needed to allow them 
to do so.

If this policy were applied to a consortium of smaller independent 
entities, then such entities could create such a consortium for the sole 
purpose of getting around the ARIN fee structure.

-Scott

Celeste Anderson wrote:
> I am curious as to why a consortium of smaller independent entities is excluded from this policy.  I apologize if I missed this in a previous discussion. 
>
> --celeste.
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> [arin-ppml] Draft Policy 2009-5: IPv6 Multiple Discrete Networks
> From:
> Member Services <info at arin.net>
> Date:
> Tue, 21 Jul 2009 10:45:48 -0400
> To:
> arin-ppml at arin.net
>
> To:
> arin-ppml at arin.net
>
>
> Draft Policy 2009-5
> IPv6 Multiple Discrete Networks
>
> On 16 July 2009 the ARIN Advisory Council (AC) selected "Draft Policy
> 2009-5: IPv6 Multiple Discrete Networks" for adoption discussion on the
> PPML and at the Public Policy Meeting in Dearborn.
>
> The draft was developed by the AC from "Policy Proposal 84. IPv6
> Multiple Discrete Networks". Per the Policy Development Process the AC
> submitted text to ARIN for a staff and legal assessment prior to
> selection as a draft policy. After review of the assessment the text was
> revised (item 5 was added to the text). The assessment, along with the
> original text that was assessed, is located below the draft policy.
>
> You are encouraged to discuss Draft Policy 2009-5 on the PPML prior to
> the ARIN XXIV 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 regarding adopting this as policy.
>
> Draft Policy 2009-5 is below and can be found at:
> https://www.arin.net/policy/proposals/2009_5.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2009-5
> IPv6 Multiple Discrete Networks
>
> Version/Date: 21 July 2009
>
> Policy statement:
>
> Organizations with multiple discrete IPv6 networks desiring to request
> new or additional address space under a single Organization ID must meet
> the following criteria:
>
>   1. The organization shall be a single entity and not a consortium of
>      smaller independent entities.
>   2. The organization must have compelling criteria for creating
>      discrete networks.
>      Examples of a discrete network might include:
>          * Regulatory restrictions for data transmission,
>          * Geographic distance and diversity between networks,
>          * Autonomous multihomed discrete networks.
>   3. The organization must keep detailed records on how it has
>      allocated space to each location, including the date of each
>      allocation.
>   4. The organization should notify ARIN at the time of the request
>      their desire to apply this policy to their account.
>   5. Requests for additional space:
>
>       a. Organization must specify on the application which discreet
> network(s) the request applies to.
>
>       b. Each network will be judged against the existing utilization
> criteria specified in 6.5.2 as if it were a separate organization,
> rather than collectively as would be done for requests outside of this
> policy.
>
> Rationale:
>
> This proposed policy is suggested as NRPM 6.11.
>
> The policy is intended to provide parity between current IPv4 policy and
> allow discrete network operators to obtain IPv6 space.
>
> Timetable for implementation: Immediately
>
>
> #####
>
>
> Staff Assessment
>
> Proposal: IPv6 Multiple Discrete Networks
>
> Date of Assessment: 7 July 2009
>
> Text assessed: 23 June 2009
>
> 1. Summary (Staff Understanding)
>
> This proposal would allow network operators to request /32s (ISPs) or
> /48s (End-users), or larger blocks as justified, for each of their
> discrete networks. They would first need to meet current policy criteria
> for initial IPv6 allocations or assignments as described in NRPM section
> 6.5.1 or section 6.5.8 (as appropriate). The organization must have
> compelling criteria to create discrete networks, must keep detailed
> records, and must tell ARIN at the beginning of the request that they
> are applying under this policy.
>
> 2. Comments
>
> A. ARIN Staff Comments
>
>    * The proposal says that it is for requesting new or additional
>      address space, but it does not include criteria for additional
>      requests. This means that staff would likely have to revert to
>      existing NRPM 6.5.2 criteria for requesting additional IPv6
>      address space.
>    * This policy creates no significant operational impact and would
>      require very little staff time or effort to implement.
>    * This policy could be utilized by network operators running
>      multiple discrete networks who in the past, may have been denied
>      under current policy and/or forced to open multiple accounts to
>      accomplish their goals.
>
> B. ARIN General Counsel
>
>    * Counsel saw no issues with this proposal.
>
> 3. Resource Impact
>
> This policy would have minimal resource impact. It is estimated that
> implementation would occur within three months after ratification by the
> ARIN Board of Trustees. The following would be needed in order to 
> implement:
>
>    * Updated guidelines
>    * Staff training
>
> 4. Proposal Text
>
> Proposal: IPv6 Multiple Discrete Networks
>
> Version/Date: 23 June 2009
>
> Organizations with multiple discrete IPv6 networks desiring to request
> new or additional address space under a single Organization ID must meet
> the following criteria:
>
> 1. The organization shall be a single entity and not a consortium of
> smaller independent entities.
>
> 2. The organization must have compelling criteria for creating discrete
> networks. Examples of a discrete network might include:
>
> a. Regulatory restrictions for data transmission,
>
> b. Geographic distance and diversity between networks,
>
> c. Autonomous multihomed discrete networks.
>
> 3. The organization must keep detailed records on how it has allocated
> space to each location, including the date of each allocation.
>
> 4. The organization should notify ARIN at the time of the request their
> desire to apply this policy to their account.
>
> Rationale:
>
> This proposed policy is suggested as NRPM 6.11. The policy is intended
> to provide parity between current IPv4 policy and allow discrete network
> operators to obtain IPv6 space.
>
>
>
>
>
>
> _______________________________________________
> 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 celestea at usc.edu  Tue Jul 21 15:06:08 2009
From: celestea at usc.edu (Celeste Anderson)
Date: Tue, 21 Jul 2009 12:06:08 -0700
Subject: [arin-ppml] Fwd: Draft Policy 2009-5: IPv6 Multiple Discrete
 Networks
In-Reply-To: <4A660D51.7080903@gmail.com>
References: <f9fca01060ff.4a657827@usc.edu> <4A660D51.7080903@gmail.com>
Message-ID: <ee7ed0053eb0.4a65af30@usc.edu>

Scott,

Thanks for the explanation.  

--celeste.

----- Original Message -----
From: Scott Leibrand <scottleibrand at gmail.com>
Date: Tuesday, July 21, 2009 11:48 am
Subject: Re: [arin-ppml] Fwd: Draft Policy 2009-5: IPv6 Multiple Discrete Networks
To: Celeste Anderson <celestea at usc.edu>
Cc: arin-ppml at arin.net

> It looks like that was carried over from the IPv4 Multiple Discrete 
> Networks policy (https://www.arin.net/policy/nrpm.html#four5).
> 
> If several smaller entities each need addresses for separate 
> networks, 
> they should apply independently as separate organizations.  If a 
> single 
> organization runs multiple discrete networks, they can't apply for 
> space 
> for each network independently, so this policy is needed to allow 
> them 
> to do so.
> 
> If this policy were applied to a consortium of smaller independent 
> entities, then such entities could create such a consortium for the 
> sole 
> purpose of getting around the ARIN fee structure.
> 
> -Scott
> 
> Celeste Anderson wrote:
> > I am curious as to why a consortium of smaller independent 
> entities is excluded from this policy.  I apologize if I missed 
> this in a previous discussion. 
> >
> > --celeste.
> >   
> >
> > ------------------------------------------------------------------
> ------
> >
> > Subject:
> > [arin-ppml] Draft Policy 2009-5: IPv6 Multiple Discrete Networks
> > From:
> > Member Services <info at arin.net>
> > Date:
> > Tue, 21 Jul 2009 10:45:48 -0400
> > To:
> > arin-ppml at arin.net
> >
> > To:
> > arin-ppml at arin.net
> >
> >
> > Draft Policy 2009-5
> > IPv6 Multiple Discrete Networks
> >
> > On 16 July 2009 the ARIN Advisory Council (AC) selected "Draft 
> Policy> 2009-5: IPv6 Multiple Discrete Networks" for adoption 
> discussion on the
> > PPML and at the Public Policy Meeting in Dearborn.
> >
> > The draft was developed by the AC from "Policy Proposal 84. IPv6
> > Multiple Discrete Networks". Per the Policy Development Process 
> the AC
> > submitted text to ARIN for a staff and legal assessment prior to
> > selection as a draft policy. After review of the assessment the 
> text was
> > revised (item 5 was added to the text). The assessment, along 
> with the
> > original text that was assessed, is located below the draft policy.
> >
> > You are encouraged to discuss Draft Policy 2009-5 on the PPML 
> prior to
> > the ARIN XXIV 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 regarding adopting this as policy.
> >
> > Draft Policy 2009-5 is below and can be found at:
> > https://www.arin.net/policy/proposals/2009_5.html
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy 2009-5
> > IPv6 Multiple Discrete Networks
> >
> > Version/Date: 21 July 2009
> >
> > Policy statement:
> >
> > Organizations with multiple discrete IPv6 networks desiring to 
> request> new or additional address space under a single 
> Organization ID must meet
> > the following criteria:
> >
> >   1. The organization shall be a single entity and not a 
> consortium of
> >      smaller independent entities.
> >   2. The organization must have compelling criteria for creating
> >      discrete networks.
> >      Examples of a discrete network might include:
> >          * Regulatory restrictions for data transmission,
> >          * Geographic distance and diversity between networks,
> >          * Autonomous multihomed discrete networks.
> >   3. The organization must keep detailed records on how it has
> >      allocated space to each location, including the date of each
> >      allocation.
> >   4. The organization should notify ARIN at the time of the request
> >      their desire to apply this policy to their account.
> >   5. Requests for additional space:
> >
> >       a. Organization must specify on the application which discreet
> > network(s) the request applies to.
> >
> >       b. Each network will be judged against the existing 
> utilization> criteria specified in 6.5.2 as if it were a separate 
> organization,> rather than collectively as would be done for 
> requests outside of this
> > policy.
> >
> > Rationale:
> >
> > This proposed policy is suggested as NRPM 6.11.
> >
> > The policy is intended to provide parity between current IPv4 
> policy and
> > allow discrete network operators to obtain IPv6 space.
> >
> > Timetable for implementation: Immediately
> >
> >
> > #####
> >
> >
> > Staff Assessment
> >
> > Proposal: IPv6 Multiple Discrete Networks
> >
> > Date of Assessment: 7 July 2009
> >
> > Text assessed: 23 June 2009
> >
> > 1. Summary (Staff Understanding)
> >
> > This proposal would allow network operators to request /32s 
> (ISPs) or
> > /48s (End-users), or larger blocks as justified, for each of their
> > discrete networks. They would first need to meet current policy 
> criteria> for initial IPv6 allocations or assignments as described 
> in NRPM section
> > 6.5.1 or section 6.5.8 (as appropriate). The organization must have
> > compelling criteria to create discrete networks, must keep detailed
> > records, and must tell ARIN at the beginning of the request that 
> they> are applying under this policy.
> >
> > 2. Comments
> >
> > A. ARIN Staff Comments
> >
> >    * The proposal says that it is for requesting new or additional
> >      address space, but it does not include criteria for additional
> >      requests. This means that staff would likely have to revert to
> >      existing NRPM 6.5.2 criteria for requesting additional IPv6
> >      address space.
> >    * This policy creates no significant operational impact and would
> >      require very little staff time or effort to implement.
> >    * This policy could be utilized by network operators running
> >      multiple discrete networks who in the past, may have been 
> denied>      under current policy and/or forced to open multiple 
> accounts to
> >      accomplish their goals.
> >
> > B. ARIN General Counsel
> >
> >    * Counsel saw no issues with this proposal.
> >
> > 3. Resource Impact
> >
> > This policy would have minimal resource impact. It is estimated that
> > implementation would occur within three months after ratification 
> by the
> > ARIN Board of Trustees. The following would be needed in order to 
> > implement:
> >
> >    * Updated guidelines
> >    * Staff training
> >
> > 4. Proposal Text
> >
> > Proposal: IPv6 Multiple Discrete Networks
> >
> > Version/Date: 23 June 2009
> >
> > Organizations with multiple discrete IPv6 networks desiring to 
> request> new or additional address space under a single 
> Organization ID must meet
> > the following criteria:
> >
> > 1. The organization shall be a single entity and not a consortium of
> > smaller independent entities.
> >
> > 2. The organization must have compelling criteria for creating 
> discrete> networks. Examples of a discrete network might include:
> >
> > a. Regulatory restrictions for data transmission,
> >
> > b. Geographic distance and diversity between networks,
> >
> > c. Autonomous multihomed discrete networks.
> >
> > 3. The organization must keep detailed records on how it has 
> allocated> space to each location, including the date of each 
> allocation.>
> > 4. The organization should notify ARIN at the time of the request 
> their> desire to apply this policy to their account.
> >
> > Rationale:
> >
> > This proposed policy is suggested as NRPM 6.11. The policy is 
> intended> to provide parity between current IPv4 policy and allow 
> discrete network
> > operators to obtain IPv6 space.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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 tedm at ipinc.net  Tue Jul 21 15:33:02 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Jul 2009 12:33:02 -0700
Subject: [arin-ppml] Spectrum and IP address reservations / More from
 NERA
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233EFA@SUEX07-MBX-04.ad.syr.edu>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>,
	<997551.95719.qm@web63304.mail.re1.yahoo.com>
	<75822E125BCB994F8446858C4B19F0D77B233EFA@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A6617EE.3010002@ipinc.net>

Milton L Mueller wrote:

> 
> The main difference between economists and noneconomists in this case is that the economists were rigorous and honest enough to specify their assumptions clearly. On the other hand, the advocates of nonmarket resource allocation policies are often making equally strict and bizarre assumptions about human behavior, but their theories are often too flaccid to specify what those assumptions are, and so they are unable to derive good models of their implications.

Hold on here, Milton, your making a leading argument.

Regulators are not all "noneconomists" (whatever you mean by that)  Many 
economists advocate market regulation.

I won't argue that noneconomists have flaccid theories (sounds like a 
personal problem) since the word noneconomist implies that already.  But 
before you imply that regulators are a) not economists and b) have
flaccid theories, you better justify this about regulators.

> For example, when people say you can fix market imperfections by "regulating" the market, are they not assuming that: 
>  * the regulator has perfect knowledge about the actors in the market and everything they do

Yes and no, it depends.  A regulation proposed as a RESPONSE to some 
market imperfection DOES have a claim of behavior by the actors in the 
market - assuming the imperfection exists because of behavior.

For example recent events have demonstrated a false theory - that
bankers, acting on self-interest, will as a group avoid extending 
high-risk home loans to people with bad credit.  That theory ignored the 
fact that introducing sales commissions for sale of securities composed 
of those loans setup a lure that got bankers to act against their own 
best interest.

Thus, regulation that disallows the bundling of high-risk loans with 
low-risk loans into securities is an obvious, and logical, response to 
the aberration.

By contrast, regulations proposed with the EXPECTATION of how they think 
a market will react - such as the TARP regulation, which assumed that 
after the capital influx the banks would be all better - DID make 
assumptions about how the actors would act.

>  * the people who do the regulation will not exploit their position for their own benefit

If the regulator is permitted to operate within the market they are
regulating, this is obvious.

But not all regulators are bankers, for example.  Nor are all regulators 
millionaires with stock portfolios that will react to their regulation.

>  * regulators are never politically or personally motivated to show favoritism in the application of the rules (e.g., not prosecuting Madoff after two notifications)

The Madoff thing wasn't a favoritism in rule application, it was
criminal behavior and cannot be analysed from an economic perspective. 
You must look at it from a criminal perspective.  Criminals operate from 
a risk/benefit perspective.  If the risk of getting caught and the 
penalties for getting caught are high in comparison to the reward for 
committing the crime, the criminal will not do the crime.

The fact of the matter is that if the SEC regulators who colluded with 
Madoff to allow the scheme were imprisoned for life, it would set the 
penalty high enough so that future regulators would be very unlikely to 
engage in criminal behavior of this type.

If you want to remove favoritism from regulators the usual way to do it 
is to bar the regulator from participating in the market he's 
regulating.  This is SOP for many regulatory posts.

As for IP address regulation - have we observed reaction of the "market" 
to a shortage of IPv4 numbers yet?  No - because while such a shortage 
is looming, it hasn't happened yet.  The looming shortage is the "market 
imperfection" here, and it's a bit too early to be looking at 
comparisons to economic models, in my opinion.

Ted


From owen at delong.com  Tue Jul 21 16:09:02 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jul 2009 13:09:02 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4A660C0E.1070605@gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
Message-ID: <CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>

> I can try, and I'm sure someone will correct me if I'm wrong...
>
> Up until January 1 2010, ARIN distinguishes between 2-byte and 4- 
> byte ASNs, and lets you have a 2-byte if you need it, but gives out  
> 4-bytes otherwise, to spur adoption.
>
> After January 1 2010, ARIN ceases to make any distinction between 2- 
> byte and 4-byte ASNs.  Instead, they simply give out ASNs as they  
> always have, working up from the bottom.  At first, the ASNs given  
> out will be <64k.  Eventually, when that block of ASNs is used up,  
> they'll move on to higher numbers >64k.  Presumably by then everyone  
> with a growing network will have rolled out code to support 4-byte  
> ASNs.

More importantly, by then, it really doesn't matter since there aren't  
any 16-bit ASNs left to give out.

Owen



From arin-poc at ralph.net  Wed Jul 22 15:26:42 2009
From: arin-poc at ralph.net (arin-poc)
Date: Wed, 22 Jul 2009 15:06:42 -0420
Subject: [arin-ppml] Dear arin-ppml 84% 0FF on MensHealth.
Message-ID: <133b01ca0b18$b1f56310$8823787c@home-139358ba26>

An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090722/dccf5d87/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zbli.jpg
Type: image/jpeg
Size: 2380 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090722/dccf5d87/attachment.jpg>

From michael.dillon at bt.com  Wed Jul 22 11:18:00 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 22 Jul 2009 16:18:00 +0100
Subject: [arin-ppml] Offer to buy IP address block (was Spectrum and IP
	address reservations)
In-Reply-To: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com>
Message-ID: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net>


> More specifically, in this context I think that the tendency 
> to assume that market mechanisms would infallibly convert the 
> fact/existence/ supply of additional loose (de-assignable, 
> transferable, etc.) IPv4 into the enduring condition of 
> greater openness to aspiring new entrants is based on the 
> widespread (mis)perception of individual IPv4 addresses and 
> prefixes as "things" (assets, commodities, etc.), when in 
> fact they actually represent something more like discrete 
> instances of a "generalized  privilege"  or "license" (as in 
> "creative license"  
> even more than "driver's license").

The minimum ARIN allocation to a new ISP is currently a /20.
Someone recently offered an American ISP 6 figures for a 
/20 block that was acquired as part of a corporate acquisition. 
The ISP declined the offer and returned the block to ARIN.

This could mean that the value of a /20 on the open market is
100,000 USD. Since a /20 has 16 /24 equivalents in it, that would
place the value of a /24 at 6250 USD. According to
<https://www.arin.net/knowledge/statistics/>
in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents
to ISPs. That means that ARIN issued 620,531,250 USD worth
of IP addresses. Over the course of 2009 we can expect some
1.2 billion dollars worth of IPv4 addresses to be allocated
to ISPs, or $103 million per month.

Where is the industry going to find 1.2 billion dollars to sustain
growth of the network after IPv4 runout? And where is a new entrant
going to find $100,000 to buy their first allocation, assuming that
the price doesn't rise even higher when the free alternative no 
longer exists?

Will the prices in Europe be any different than in America?
Why?

--Michael Dillon

P.S. note that there are more predictable costs to an ISP 
in deploying either carrier-grade NAT or transitioning to IPv6. 
How will this impact IP address block prices and why?


From martin.hannigan at batelnet.bs  Wed Jul 22 16:53:39 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 22 Jul 2009 16:53:39 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
Message-ID: <4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>

On Tue, Jul 21, 2009 at 4:09 PM, Owen DeLong<owen at delong.com> wrote:
>> I can try, and I'm sure someone will correct me if I'm wrong...
>>
>> Up until January 1 2010, ARIN distinguishes between 2-byte and 4-byte
>> ASNs, and lets you have a 2-byte if you need it, but gives out 4-bytes
>> otherwise, to spur adoption.
>>
>> After January 1 2010, ARIN ceases to make any distinction between 2-byte
>> and 4-byte ASNs. ?Instead, they simply give out ASNs as they always have,
>> working up from the bottom. ?At first, the ASNs given out will be <64k.
>> ?Eventually, when that block of ASNs is used up, they'll move on to higher
>> numbers >64k. ?Presumably by then everyone with a growing network will have
>> rolled out code to support 4-byte ASNs.
>
> More importantly, by then, it really doesn't matter since there aren't any
> 16-bit ASNs left to give out.


How's that? There is likely some churn. If anything, it significantly
pushes out 4 byte allocations since this seems to imply that as long
as there are 2 byte ASN's they will be allocated.

This is a good candidate for a petition. We lost transparency by the
abandonment and the second interpretation of the intent of the
original policy. It's possible that there are also technical
implications to recycling (if that is the intent) on a rapid basis
some previously utillized ASN's. I admit, I can't really think of
anything significant besides number reputation. That could be enough
though. I'm honestly not sure.

Best,

Martin


From packetgrrl at gmail.com  Wed Jul 22 17:06:34 2009
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Wed, 22 Jul 2009 15:06:34 -0600
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
	<4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
Message-ID: <c3227e9e0907221406h2ac7f643i71e8abdb0fee144e@mail.gmail.com>

Marty
Feel free to petition but the author of the proposal is the one who
interpreted and advocated abandonment.  The intent of the proposal was to
extend the timeframe that folks could get 2-byte ASNs.  ARIN's practice
regarding how they will hand out ASNs in essence does this without a policy.


----Cathy

On Wed, Jul 22, 2009 at 2:53 PM, Martin Hannigan <
martin.hannigan at batelnet.bs> wrote:

> On Tue, Jul 21, 2009 at 4:09 PM, Owen DeLong<owen at delong.com> wrote:
> >> I can try, and I'm sure someone will correct me if I'm wrong...
> >>
> >> Up until January 1 2010, ARIN distinguishes between 2-byte and 4-byte
> >> ASNs, and lets you have a 2-byte if you need it, but gives out 4-bytes
> >> otherwise, to spur adoption.
> >>
> >> After January 1 2010, ARIN ceases to make any distinction between 2-byte
> >> and 4-byte ASNs.  Instead, they simply give out ASNs as they always
> have,
> >> working up from the bottom.  At first, the ASNs given out will be <64k.
> >>  Eventually, when that block of ASNs is used up, they'll move on to
> higher
> >> numbers >64k.  Presumably by then everyone with a growing network will
> have
> >> rolled out code to support 4-byte ASNs.
> >
> > More importantly, by then, it really doesn't matter since there aren't
> any
> > 16-bit ASNs left to give out.
>
>
> How's that? There is likely some churn. If anything, it significantly
> pushes out 4 byte allocations since this seems to imply that as long
> as there are 2 byte ASN's they will be allocated.
>
> This is a good candidate for a petition. We lost transparency by the
> abandonment and the second interpretation of the intent of the
> original policy. It's possible that there are also technical
> implications to recycling (if that is the intent) on a rapid basis
> some previously utillized ASN's. I admit, I can't really think of
> anything significant besides number reputation. That could be enough
> though. I'm honestly not sure.
>
> Best,
>
> Martin
> _______________________________________________
> 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/20090722/f35d1c88/attachment.htm>

From michael.dillon at bt.com  Wed Jul 22 17:50:03 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 22 Jul 2009 22:50:03 +0100
Subject: [arin-ppml] The price of address space
In-Reply-To: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com>
Message-ID: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>

> To be serious, I think it's unwise to extrapolate from your 
> anecdote about someone offering a six figure sum for a /20. 

Not at all. In several years of discussion of IP address markets,
this is the first time that I have seen someone put an actual 
dollar value on an address block. Granted, it was an offered
amount that did not result in a sale, but it is the best data
point that I have seen so far.

> For one thing, who could possibly know 
> for sure if the figure you quoted that was offered recently 
> will be the going rate for a /20 after the IPv4 run-out? 

I think that we all realise that in a real market, prices go
up and down with every transaction. So, given that someone is
willing to offer 100,000 USD for a /20 today, when there are
free alternatives at the RIR, what do you think the going rate
will be after the free alternative is gone? 

> If we assume there will be a market in IPv4 after the 
> run-out, we should expect the usual laws of supply and demand 
> will mean there's some sort of price equilibrium in the 
> market.

Equilibrium? When I learned basic economics, scarcity caused
prices to rise. After IPv4 runout, every block sold just makes
IPv4 addresses scarcer which means that there will be no equilibrium,
just increases until nobody can afford to pay the price. I would
expect that to be a stairstep increase because everyone knows that
addresses are scarcer and scarcer as time goes on.

Then the whole thing comes crashing down when IPv6 gathers enough
momentum and people start releasing large amounts of IPv4 addresses.

> Just like 
> any predictions for the prices of shares or exchange rates or 
> commodities N years in the future.

You may not be able to predict exact prices, but you can do pretty good
at predicting minimum and maximum prices relative to a hard currency,
i.e. ounces of gold or barrels of crude, or Big Macs.

> For instance more use of NAT and ALG 
> (if these turn out to be cheaper than buying a /20 or 
> whatever).

How cheap do IPv4 addresses need to be to make it worthwhile for an
equipment vendor to buy up addresses today to drive up the price and
make it worthwhile for the market to buy carrier grade NAT boxes?

> The point I'm making is that it doesn't seem sensible or even 
> possible to predict what these prices might be post run-out. 

We could prohibit 3rd part transfers and only allow returns to
the RIR in which case we can confidently predict that the price
will be zero. In any case, it is very sensible to do these types
of scenario analysis as part of the policymaking process.

> Or to invent policies which 
> somehow influence or control those prices. [That might well 
> have the look and feel of a cartel.]

We have a cartel today and the price is zero. It's been like 
that for many years now and nobody is complaining or investigating
the RIRs.

> It would be an 
> interesting academic exercise for economists to model the 
> impact of various pricing scenarios though I'm not sure how 
> useful that would be in practice. That said, it would be nice 
> to have some sort of idea of the price points where the 
> trade-offs between buying
> IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy.

I agree on that. Where are all the economics grad students?

--Michael Dillon

P.S. My position is that IPv6 is the answer and post runout, most
larger ISPs should be able to satisfy growth of IPv4 in one area 
of their business by migrating lower margin services onto pure IPv6
in order to free the IPv4 addresses for the sluggish corporates who
are willing to pay a higher margin for service using legacy technology.
Note that an economist might well consider this to be a market
alternative
because money is exchanged in return for IPv4 network services with
IPv4 addresses bundled in.



From martin.hannigan at batelnet.bs  Wed Jul 22 17:51:05 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 22 Jul 2009 17:51:05 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <c3227e9e0907221406h2ac7f643i71e8abdb0fee144e@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
	<4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
	<c3227e9e0907221406h2ac7f643i71e8abdb0fee144e@mail.gmail.com>
Message-ID: <4607e1d50907221451h562e01dbq2cf7980bec42568d@mail.gmail.com>

On Wed, Jul 22, 2009 at 5:06 PM, cja at daydream.com<packetgrrl at gmail.com> wrote:
> Marty
> Feel free to petition but the author of the proposal is the one who
> interpreted and advocated abandonment. ?The intent of the proposal was to
> extend the timeframe that folks could get 2-byte ASNs. ?ARIN's practice
> regarding how they will hand out ASNs in essence does this without a policy.
>
> ----Cathy

Why, so the AC can toss it again? If it doesnt say "global" or
"transition" nobody really cares. It's not cool enough. :-)

-M<


From packetgrrl at gmail.com  Wed Jul 22 17:58:23 2009
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Wed, 22 Jul 2009 15:58:23 -0600
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4607e1d50907221451h562e01dbq2cf7980bec42568d@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
	<4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
	<c3227e9e0907221406h2ac7f643i71e8abdb0fee144e@mail.gmail.com>
	<4607e1d50907221451h562e01dbq2cf7980bec42568d@mail.gmail.com>
Message-ID: <c3227e9e0907221458t4b554bb1ieeb83fd051a68c20@mail.gmail.com>

Marty it is not true that nobody cares.  Most of us care a great deal.  The
Author of this proposal feels (ask her.. it's Marla) that the current
practice implemented by ARIN takes care of things then why shouldn't the AC
focus our time and energy on proposals of greater concern?  If you or anyone
else feels that we have made an error than petitiion and the proposal will
be brought to the meeting in Dearborn for consideration.
----Cathy

On Wed, Jul 22, 2009 at 3:51 PM, Martin Hannigan <
martin.hannigan at batelnet.bs> wrote:

> On Wed, Jul 22, 2009 at 5:06 PM, cja at daydream.com<packetgrrl at gmail.com>
> wrote:
> > Marty
> > Feel free to petition but the author of the proposal is the one who
> > interpreted and advocated abandonment.  The intent of the proposal was to
> > extend the timeframe that folks could get 2-byte ASNs.  ARIN's practice
> > regarding how they will hand out ASNs in essence does this without a
> policy.
> >
> > ----Cathy
>
> Why, so the AC can toss it again? If it doesnt say "global" or
> "transition" nobody really cares. It's not cool enough. :-)
>
> -M<
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090722/1afacd4d/attachment.htm>

From scottleibrand at gmail.com  Wed Jul 22 17:58:29 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 22 Jul 2009 14:58:29 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4607e1d50907221451h562e01dbq2cf7980bec42568d@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>	
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>	
	<4A660C0E.1070605@gmail.com>	
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>	
	<4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>	
	<c3227e9e0907221406h2ac7f643i71e8abdb0fee144e@mail.gmail.com>
	<4607e1d50907221451h562e01dbq2cf7980bec42568d@mail.gmail.com>
Message-ID: <4A678B85.1050703@gmail.com>

Martin Hannigan wrote:
> On Wed, Jul 22, 2009 at 5:06 PM, cja at daydream.com<packetgrrl at gmail.com> wrote:
>   
>> Marty
>> Feel free to petition but the author of the proposal is the one who
>> interpreted and advocated abandonment.  The intent of the proposal was to
>> extend the timeframe that folks could get 2-byte ASNs.  ARIN's practice
>> regarding how they will hand out ASNs in essence does this without a policy.
>>
>> ----Cathy
>>     
>
> Why, so the AC can toss it again? If it doesnt say "global" or
> "transition" nobody really cares. It's not cool enough. :-)
>   

The AC can't "throw out" a policy after a successful petition.  In this 
case, it would be a discussion petition, which would mean it'd go to 
Dearborn for discussion before going back to the AC.  So it could only 
get abandoned if the AC decided there wasn't consensus for it after the 
meeting (at which point it could be further petitioned if necessary).

In this case, the author of the proposal was an AC member and shepherd.  
Once the reason she proposed the policy went away, she moved that we 
abandon it, and the AC voted to do so (unanimously, IIRC).

There is an argument you could make that the date should be extended in 
order to continue making 4-byte ASNs available by default up until the 
point where the 2-byte pool is exhausted.  If you'd like to discuss such 
a proposal at Dearborn, a petition would be in order, followed by an 
update (by the petitioner) to the Rationale of the proposal to reflect 
the new reason for it.

-Scott

P.S. There are a lot of policies on the docket right now, and we're 
trying to prioritize them appropriately. Right now, that does mean that 
most (but not all) of the proposals on the agenda for Dearborn pertain 
to v4-v6 transition, but we welcome any feedback you have on which other 
items require urgent work.



From cgrundemann at gmail.com  Wed Jul 22 18:00:14 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 22 Jul 2009 16:00:14 -0600
Subject: [arin-ppml] Offer to buy IP address block (was Spectrum and IP
	address reservations)
In-Reply-To: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net>
References: <1F6404CD-A0B2-42D4-A849-ED5E9F9D89E5@eyeconomics.com>
	<28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com>

On Wed, Jul 22, 2009 at 09:18, <michael.dillon at bt.com> wrote:
>
>> More specifically, in this context I think that the tendency
>> to assume that market mechanisms would infallibly convert the
>> fact/existence/ supply of additional loose (de-assignable,
>> transferable, etc.) IPv4 into the enduring condition of
>> greater openness to aspiring new entrants is based on the
>> widespread (mis)perception of individual IPv4 addresses and
>> prefixes as "things" (assets, commodities, etc.), when in
>> fact they actually represent something more like discrete
>> instances of a "generalized ?privilege" ?or "license" (as in
>> "creative license"
>> even more than "driver's license").
>
> The minimum ARIN allocation to a new ISP is currently a /20.
> Someone recently offered an American ISP 6 figures for a
> /20 block that was acquired as part of a corporate acquisition.
> The ISP declined the offer and returned the block to ARIN.
>
> This could mean that the value of a /20 on the open market is
> 100,000 USD. Since a /20 has 16 /24 equivalents in it, that would
> place the value of a /24 at 6250 USD.

http://xkcd.com/605/

> According to
> <https://www.arin.net/knowledge/statistics/>
> in the first 6 months of 2009, ARIN issued 99,285 /24 equivalents
> to ISPs. That means that ARIN issued 620,531,250 USD worth
> of IP addresses. Over the course of 2009 we can expect some
> 1.2 billion dollars worth of IPv4 addresses to be allocated
> to ISPs, or $103 million per month.
>
> Where is the industry going to find 1.2 billion dollars to sustain
> growth of the network after IPv4 runout? And where is a new entrant
> going to find $100,000 to buy their first allocation, assuming that
> the price doesn't rise even higher when the free alternative no
> longer exists?
>
> Will the prices in Europe be any different than in America?
> Why?
>
> --Michael Dillon
>
> P.S. note that there are more predictable costs to an ISP
> in deploying either carrier-grade NAT or transitioning to IPv6.
> How will this impact IP address block prices and why?
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From john.sweeting at twcable.com  Wed Jul 22 18:02:38 2009
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 22 Jul 2009 18:02:38 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
Message-ID: <58174FA985B92A42B9E3142C4DD2CC0405EC09F7@PRVPVSMAIL07.corp.twcable.com>

Marty,

I have to fully agree with Cathy and I think you owe the AC members an apology for that remark. I know you don't believe it so not sure why you posted it. Call me when you get in town tomorrow.

________________________________

From: arin-ppml-bounces at arin.net 
To: Martin Hannigan 
Cc: arin-ppml at arin.net 
Sent: Wed Jul 22 17:58:23 2009
Subject: Re: [arin-ppml] Advisory Council Meeting Results - July 2009 


Marty it is not true that nobody cares.  Most of us care a great deal.  The Author of this proposal feels (ask her.. it's Marla) that the current practice implemented by ARIN takes care of things then why shouldn't the AC focus our time and energy on proposals of greater concern?  If you or anyone else feels that we have made an error than petitiion and the proposal will be brought to the meeting in Dearborn for consideration.  

----Cathy


On Wed, Jul 22, 2009 at 3:51 PM, Martin Hannigan <martin.hannigan at batelnet.bs> wrote:


	On Wed, Jul 22, 2009 at 5:06 PM, cja at daydream.com<packetgrrl at gmail.com> wrote:
	> Marty
	> Feel free to petition but the author of the proposal is the one who
	> interpreted and advocated abandonment.  The intent of the proposal was to
	> extend the timeframe that folks could get 2-byte ASNs.  ARIN's practice
	> regarding how they will hand out ASNs in essence does this without a policy.
	>
	> ----Cathy
	
	
	Why, so the AC can toss it again? If it doesnt say "global" or
	"transition" nobody really cares. It's not cool enough. :-)
	
	-M<
	


This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090722/7aab65f4/attachment.htm>

From michael.dillon at bt.com  Wed Jul 22 18:35:50 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 22 Jul 2009 23:35:50 +0100
Subject: [arin-ppml] Offer to buy IP address block (was Spectrum and IP
	address reservations)
In-Reply-To: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net>


> > Someone recently offered an American ISP 6 figures for a /20 block 
> > that was acquired as part of a corporate acquisition.
> > The ISP declined the offer and returned the block to ARIN.
> >
> > This could mean that the value of a /20 on the open market 
> is 100,000 
> > USD. Since a /20 has 16 /24 equivalents in it, that would place the 
> > value of a /24 at 6250 USD.
> 
> http://xkcd.com/605/

Not terribly relevant to IPv4 addresses.

> > According to
> > <https://www.arin.net/knowledge/statistics/>
> > in the first 6 months of 2009, ARIN issued 99,285 /24 
> equivalents to 
> > ISPs. That means that ARIN issued 620,531,250 USD worth of IP 
> > addresses. Over the course of 2009 we can expect some
> > 1.2 billion dollars worth of IPv4 addresses to be allocated 
> to ISPs, 
> > or $103 million per month.
> >
> > Where is the industry going to find 1.2 billion dollars to sustain 
> > growth of the network after IPv4 runout? And where is a new entrant 
> > going to find $100,000 to buy their first allocation, assuming that 
> > the price doesn't rise even higher when the free 
> alternative no longer 
> > exists?

I just learned that 6 figures actually referred to 185,000 USD
so multiply all my above figures by 1.85. That brings the value
of ARIN's annual ISP allocations to 2.2 billion USD.

Another organization made an offer to use the address range for
spamming, without transfering ownership, and their offer amounts
to about 1/25th of the above one which would make ARIN's annual
ISP allocations worth only 48 million USD and a /20 would cost
approximately 4000 USD.

So there you have two actual price offers showing a substantial
range of values. Someone with actual economical statistics experience
may be able to suggest a likely distribution of prices over this
price range and come up with a more likely value of ARIN's annual
ISP allocations.

--Michael Dillon




From owen at delong.com  Wed Jul 22 19:57:14 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jul 2009 16:57:14 -0700
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
References: <4A65D3DE.2040303@arin.net>
	<4607e1d50907211126q3c17a128q49ff2f7906106555@mail.gmail.com>
	<4A660C0E.1070605@gmail.com>
	<CC43FA81-8D9A-4CC1-A211-84B4AF55BC6D@delong.com>
	<4607e1d50907221353s523d056bs9c18838baf9378d5@mail.gmail.com>
Message-ID: <4D8B3E14-5A5A-4CD3-9EAA-174E8C5163F7@delong.com>


On Jul 22, 2009, at 1:53 PM, Martin Hannigan wrote:

> On Tue, Jul 21, 2009 at 4:09 PM, Owen DeLong<owen at delong.com> wrote:
>>> I can try, and I'm sure someone will correct me if I'm wrong...
>>>
>>> Up until January 1 2010, ARIN distinguishes between 2-byte and 4- 
>>> byte
>>> ASNs, and lets you have a 2-byte if you need it, but gives out 4- 
>>> bytes
>>> otherwise, to spur adoption.
>>>
>>> After January 1 2010, ARIN ceases to make any distinction between  
>>> 2-byte
>>> and 4-byte ASNs.  Instead, they simply give out ASNs as they  
>>> always have,
>>> working up from the bottom.  At first, the ASNs given out will be  
>>> <64k.
>>>  Eventually, when that block of ASNs is used up, they'll move on  
>>> to higher
>>> numbers >64k.  Presumably by then everyone with a growing network  
>>> will have
>>> rolled out code to support 4-byte ASNs.
>>
>> More importantly, by then, it really doesn't matter since there  
>> aren't any
>> 16-bit ASNs left to give out.
>
>
> How's that? There is likely some churn. If anything, it significantly
> pushes out 4 byte allocations since this seems to imply that as long
> as there are 2 byte ASN's they will be allocated.
>
Right.  It will push additional 4-byte allocations (after 2010) out by
some amount of time (not much, IIRC). Until January, 2010, the
distinction will remain and you can apply for whichever type of ASN
you prefer.

Is that a problem? Why?

As to churn, I suspect ARIN will not rapid-cycle the limited churn
in ASNs <65536.

> This is a good candidate for a petition. We lost transparency by the
> abandonment and the second interpretation of the intent of the
> original policy. It's possible that there are also technical
> implications to recycling (if that is the intent) on a rapid basis
> some previously utillized ASN's. I admit, I can't really think of
> anything significant besides number reputation. That could be enough
> though. I'm honestly not sure.
>
I don't know why you think there was a loss of transparency.

The author's statement about why the policy was needed was
rendered moot by staff's clarification about how things would be
handled in the next phase.

If you still feel that this policy is useful or necessary in light of  
staff's
clarification of how they would process requests after 1/1/2010,
please do petition, and, please elaborate on why you think the
policy is still needed.

Owen



From bmanning at vacation.karoshi.com  Thu Jul 23 05:51:44 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 23 Jul 2009 09:51:44 +0000
Subject: [arin-ppml] [address-policy-wg] RE: The price of address space
In-Reply-To: <2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com>
References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
	<2C4A4EB5-DC61-4F77-B992-4394016AA328@rfc1035.com>
Message-ID: <20090723095144.GA10019@vacation.karoshi.com.>

> etc. And if/when there is a mass uptake of IPv6, IPv4 space will  
> become as valuable as VHS tape: impossible to even give away.

	and one of my 80's bands just released their latest 
	on 8track...  no MP3, no LP, no CD... an 8track.  I hate them.


> that the price of a scarce resource can only increase: how much is a  
> LaserDisc player worth today?

	depends on how badly I need to watch the ChuckJones pre-estate
	fight, can't get anywhere else but the laser-disk version of 
	BugsBunny.

> >at predicting minimum and maximum prices relative to a hard currency,
> >i.e. ounces of gold or barrels of crude, or Big Macs.

	BigMacs are only hard if left out for 6years.. takes that long
	for the bun to toughen up.

> >P.S. My position is that IPv6 is the answer
> 
> I agree wholeheartedly. My personal opinion is to leave the IPv4  
> policies as they are. Any changes will be like re-arranging the  
> deckchairs on the Titanic. And will look bad to the outside world when  
> they finally wake up to the imminent exhaustion of IPv4 space. We  
> should stop worrying about IPv4 or speculating about what a future  
> market in IPv4 might look like. [Though an open question is what the  
> role of the RIRs might be in that market.] IMO, it's best to  
> concentrate on IPv6 deployment and getting on with that migration.

	pragmatically, there is a genuine need to retain IPv4
	for the forseeable future - at least until significant
	software replacement is done.  Too much depends on an IPv4
	like thing (AAA, radius, SYSLOG, SNMP, etc) to expect
	wholesale abandonment of v4 in the next - say - 5-10 years.

	v4 just won't be wasted on endsystems :)

(and Jim, you use of technologies that have been OBE'd in the commodity 
space was a joyful trip down memory lane.... )

--bill


From bmanning at vacation.karoshi.com  Thu Jul 23 06:52:23 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 23 Jul 2009 10:52:23 +0000
Subject: [arin-ppml] long term useful life expectancy for IPv4
Message-ID: <20090723105223.GA10554@vacation.karoshi.com.>


would like to move the discussion to:

http://www.longbets.org/about


seems like a better place to hold this debate than policy fora.


--bill


From jim at reptiles.org  Thu Jul 23 07:18:12 2009
From: jim at reptiles.org (Jim Mercer)
Date: Thu, 23 Jul 2009 07:18:12 -0400
Subject: [arin-ppml] Offer to buy IP address block (was Spectrum and IP
	address reservations)
In-Reply-To: <28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net>
References: <443de7ad0907221500v33162ba2x6294d6ee52d2c742@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458024924D0@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090723111812.GA68894@reptiles.org>

On Wed, Jul 22, 2009 at 11:35:50PM +0100, michael.dillon at bt.com wrote:
> > > Someone recently offered an American ISP 6 figures for a /20 block 
> > > that was acquired as part of a corporate acquisition.
> > > The ISP declined the offer and returned the block to ARIN.
> > >
> > > This could mean that the value of a /20 on the open market 
> > is 100,000 
> > > USD. Since a /20 has 16 /24 equivalents in it, that would place the 
> > > value of a /24 at 6250 USD.
> > 
> > http://xkcd.com/605/
> 
> Not terribly relevant to IPv4 addresses.

hugely relevant, as the extrapolation above is based on way, way, way too few
datapoints/samples.

> So there you have two actual price offers showing a substantial
> range of values. Someone with actual economical statistics experience
> may be able to suggest a likely distribution of prices over this
> price range and come up with a more likely value of ARIN's annual
> ISP allocations.

the first example was a price offered by a company that obviously had way too
much surplus cash around, and apparently didn't qualify for their own block.

the second example (spammers looking to rent a block) is a bit of a stretch
as well.

-- 
Jim Mercer        jim at reptiles.org        +971 55 410-5633
"I'm Prime Minister of Canada, I live here and I'm going to take a leak."
   - Lester Pearson in 1967, during a meeting between himself and
    President Lyndon Johnson, whose Secret Service detail had taken over
    Pearson's cottage retreat.  At one point, a Johnson guard asked
    Pearson, "Who are you and where are you going?"


From lear at cisco.com  Thu Jul 23 07:26:59 2009
From: lear at cisco.com (Eliot Lear)
Date: Thu, 23 Jul 2009 13:26:59 +0200
Subject: [arin-ppml] The price of address space
In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A684903.60009@cisco.com>

On 7/22/09 11:50 PM, michael.dillon at bt.com wrote:
> How cheap do IPv4 addresses need to be to make it worthwhile for an
> equipment vendor to buy up addresses today to drive up the price and
> make it worthwhile for the market to buy carrier grade NAT boxes?
>    

If you attend next week's IETF in Sweden, you will see quite a number of 
Cisco employees involved in nearly every aspect of IPv6, including 
transition technologies.  We are there because we continue to believe 
that there is no Plan B(*), that IPv6 is the best way for the Internet 
to grow.  We are also there because many of our service provider 
customers are in agreement.  What we all seem to recognize is that there 
is a challenging transition period coming, and that it will have to be 
carefully managed by vendors, service providers, and large enterprises.

Eliot
(*) One could argue that we are still cooking Plan A.  For those who 
attend IETF, there is a draft, for instance, that looks at improving 
both TCP and DNS timers to ease transition.  This builds on work that 
Stuart Cheshire presented some time ago.


From tvest at eyeconomics.com  Thu Jul 23 08:14:41 2009
From: tvest at eyeconomics.com (tvest at eyeconomics.com)
Date: Thu, 23 Jul 2009 08:14:41 -0400
Subject: [arin-ppml] [address-policy-wg] The price of address space
In-Reply-To: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com>
References: <28E139F46D45AF49A31950F88C497458024922EB@E03MVZ2-UKDY.domain1.systemhost.net>
	<51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com>
Message-ID: <06FAA8D0-8571-4E15-A56A-9AC61F85052B@eyeconomics.com>


On Jul 22, 2009, at 12:32 PM, Jim Reid wrote:

> On 22 Jul 2009, at 16:18, <michael.dillon at bt.com> <michael.dillon at bt.com 
> > wrote:
>
>> Where is the industry going to find 1.2 billion dollars to sustain
>> growth of the network after IPv4 runout? And where is a new entrant
>> going to find $100,000 to buy their first allocation, assuming that
>> the price doesn't rise even higher when the free alternative no
>> longer exists?
>
> I'm reminded of the late 90's .com joke/business model about how to  
> becomea multi-billionaire: Set up a company with 100Bn shares. Sell  
> one share to yourself for $5. Congratulations! Your company is now  
> worth $500Bn. So exchange your company's paper for a medium-sized  
> country.
>
> To be serious, I think it's unwise to extrapolate from your anecdote  
> about someone offering a six figure sum for a /20. Or to use that as  
> the basis for a valuation of the allocated and/or yet-to-be- 
> allocated IPv4 address space. For one thing, who could possibly know  
> for sure if the figure you quoted that was offered recently will be  
> the going rate for a /20 after the IPv4 run-out? If someone can do  
> that, please provide me with the winning numbers for next week's  
> lottery.... :-)
>
> If we assume there will be a market in IPv4 after the run-out, we  
> should expect the usual laws of supply and demand will mean there's  
> some sort of price equilibrium in the market.

Hi Jim,

I'd have to say that that depends a lot on what you mean by  
"equilibrium."
In principle, in an IPv4 transfer market that has some aspiring buyers  
and some aspiring sellers sellers, some transfer transactions may  
occur, and any average of the sum of prices paid that you find  
meaningful (e.g., price per /32, or any other prefix size of interest)  
could be described as the equilibrium price at that point in time.

In practice, however, that's a entirely "academic," if not utterly  
meaningless statement. In the absence of a mandatory central clearing  
house for all transfer transactions, the only "information" on  
prevailing prices that will be available to anyone -- buyers or  
sellers -- will be whatever whispered rumors you can pick up in the  
halls of the next ops or IETF or policy meeting. Of course all  
transfer transactions will inevitably be covered under NDA, and so the  
only parties who might hypothetically have an incentive to share  
information (i.e., shell-shocked buyers) will be officially unable to  
do so. So there will be an equilibrium price, but it will be about as  
accessible to you and I -- or to any aspiring buyer or seller -- as  
the last digit of pi (or about as knowable as it is today, in the  
shadow market that some have alleged already exists).

But even setting aside the problem of pervasive information  
asymmetries, there are several reasons to assume that the likely  
equilibrium price might be higher than you expect.

First of all, know that at almost every point in time (until something  
very dramatic changes), most if not all potential IPv4 sellers are  
very likely to maintain a steep "reservation price" for IPv4; those  
that don't absolutely require a high minimum will be cleaned out as  
quickly as they enter the market -- by buyers who will act this way,  
if they're willing to sell at all. Second, any sign of substantial  
ongoing demand for IPv4 transfers among established, IPv4-based  
operators is likely to have a perverse effect on the minimum  
reservation prices of any remaining potential IPv4 sellers. Consider:  
today some operators express confidence in an imminent future of  
relatively transparent IPv6-based inter-domain routing -- i.e., one in  
which they will not suffer commercially if they can only offer IPv6 to  
their new and still-growing customers. That confidence is  
(necessarily) founded on the assumption that most if not all other  
operators will either be making their customers and resources  
accessible via IPv6 (one way or another), or else will be exiting the  
market. What will happen to that confidence if/when those IPv6- 
oriented pioneers observe that some of their peers are willing to pay  
a high price for any surplus IPv4 that they'd be willing to sell? How  
many of then will assume that the aspiring buyers are all suckers who  
are doomed to failure because of their apparent unwilling to  
incorporate IPv6 promptly? Alternately, how many will begin to wonder  
whether they should raise their reservation prices even higher --  
either because the demand is there, or because their certainty in that  
IPv6-based future is marginally undermined? How many would decide to  
withhold their salable IPv4 altogether, at least until the future  
becomes a little less cloudy...?

And of course, if there are even a small number of speculators in the  
market, these doubts are likely to be greatly amplified. A speculator  
doesn't care about which addressing format is better for customers,  
because they don't have any. For a speculator, the relative merits of  
IPv6 actually represent a threat, because the more compelling those  
merits are, the less profitable / less durable their IPv4 brokerage  
business is likely to be. If enough speculators are able to  
participate in the market, their preferences could have a big impact  
on which addressing standard(s) -- if any -- will be operationally or  
commercially viable in the future. And there is no barrier to deter  
speculators from entering the market, other than the willingness of  
service-operating IPv4 buyers and sellers to altruistically refuse to  
deal with them (i.e., even when they make the best offers).

Granted, these observations reflect the kind of situation we're facing  
today, when very few resources are attached to the Internet with any  
form of IPv6, and very very few (if any) of those that are IPv6- 
attached are reachable from any other routing domain via any means  
that is not absolutely dependent on IPv4. People often point to this  
caveat by way of implying how different it will be when IPv6 is more  
widely deployed -- seemingly without noticing that such statements are  
tautological. Things will be different when they are different, no  
doubt -- but how will we get from here to there? Who's going to lead  
that charge so that others can make such statements with semantic  
content > 0 ?

I have heard quite a few current operators -- by definition, all IPv4  
holders -- suggest that post-IPv4 allocation-era new entrants will be  
the primary drivers for this transition. But from what we know from  
the allocation records and the routing table, etc., a nontrivial share  
of people saying (thinking?) this today must be among the vast  
majority of operators that do not currently offering native IPv6  
routing services. Perhaps there is no contradiction, and people are  
saying/thinking such things because, today, they fully expect to offer  
some form of IPv6 as soon as that must-have-IPv6 demand grows.  
However, when that time does arrive, will prospective upstream  
providers have an incentive to offer native IPv6 routing -- i.e., the  
kind that would provide the IPv6-only newbie with the same kind of  
status that they themselves enjoy (where the lines between customer  
vs. peer vs. provider status are dictated by  size and contract, not  
by inheritance or privileged access to a closed, proprietary  
technology)? Or, will the incumbent incentives favor offering the kind  
of IPv6 routing service that makes it substantially more difficult, if  
not structurally impossible, for the new entrant to organically  
transition into inter-domain peer or routing service provider roles as  
growth and other circumstances permit today?

If private commercial incentives favor the latter in many/most cases,  
is competition from other, more IPv6-friendly routing services  
providers likely to be sufficient to ultimately tip the balance in  
favor of substitutability of IPv4 and IPv6 in inter-domain routing?  
It's anyone's guess, but I think some insight might be gleaned by  
talking to, for example, tier-two and smaller providers in Latin  
America and Africa that were operating before the establishment of  
LACNIC and AfriNIC -- i.e., in a times/places when new entrants had  
little or no choice but to obtain address resources as well as routing  
services from an incumbent commercial operator.

> The point I'm making is that it doesn't seem sensible or even  
> possible to predict what these prices might be post run-out. Or  
> worry too much about that. Or to invent policies which somehow  
> influence or control those prices. [That might well have the look  
> and feel of a cartel.] It would be an interesting academic exercise  
> for economists to model the impact of various pricing scenarios  
> though I'm not sure how useful that would be in practice. That said,  
> it would be nice to have some sort of idea of the price points where  
> the trade-offs between buying IPv4 or using more NAT/ALG or  
> deploying IPv6 start to get fuzzy.


I agree wholeheartedly that quantitative models that seek to predict  
point-specific IPv4 transfers prices are not constructive -- if only  
because no one who really could use such information is likely to  
trust them, no matter how accurate they might actually be. That said,  
I think that the application of a little common sense plus industry  
experience/know-how to the basic question can take one a long way  
toward understanding what kinds of outcomes are marginally more vs.  
less likely, and perhaps which are quite unlikely.

> Any market that develops should be self-correcting.


That is axiomatically true, but then there are some self-corrections  
that may not be appealing to all stakeholders.

For those who are indifferent to the question of whether or not the  
inevitable correction will result in a future in which the IPv4/IPv6  
distinction disappears, and how (e.g., because IPv6 becomes a viable  
substitute for IPv4, or because IPv4 lock-in makes it a permanent  
mandatory requirement for any aspiring routing services provider),  
there is a lot less to worry about.

Others might want to give it some thought.

TV





From martin.hannigan at batelnet.bs  Thu Jul 23 08:40:36 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 23 Jul 2009 08:40:36 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <58174FA985B92A42B9E3142C4DD2CC0405EC09F7@PRVPVSMAIL07.corp.twcable.com>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC09F7@PRVPVSMAIL07.corp.twcable.com>
Message-ID: <4607e1d50907230540h18ba0a09p6de95af39e99928c@mail.gmail.com>

On Wed, Jul 22, 2009 at 6:02 PM, Sweeting,
John<john.sweeting at twcable.com> wrote:
> Marty,
>
> I have to fully agree with Cathy and I think you owe the AC members an
> apology for that remark. I know you don't believe it so not sure why you
> posted it. Call me when you get in town tomorrow.

Jeez, the sensitivity levels are at an all time high. I didn't intend
to blanket the AC. :-) Apologies offered.

I think that the real problem that I have is that the new process
isn't Coke v. Pepsi, it's more like Coke v Coke Classic. It has turned
ARIN into a quite different animal IMHO.

I'll be at Jackson's in RTC by 7! :-)

Marty


From BillD at cait.wustl.edu  Thu Jul 23 08:50:48 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 23 Jul 2009 07:50:48 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
References: <58174FA985B92A42B9E3142C4DD2CC0405EC09F7@PRVPVSMAIL07.corp.twcable.com>
	<4607e1d50907230540h18ba0a09p6de95af39e99928c@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087914E03@ex1.cait.wustl.edu>

Apologies accepted....none necessary in my opinion....
But how could I hold a grudge for this, if you didn't for me addressing you as Mary Hannigan in a distant post... ;-)

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan
Sent: Thu 7/23/2009 7:40 AM
To: Sweeting, John
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Advisory Council Meeting Results - July 2009
 
On Wed, Jul 22, 2009 at 6:02 PM, Sweeting,
John<john.sweeting at twcable.com> wrote:
> Marty,
>
> I have to fully agree with Cathy and I think you owe the AC members an
> apology for that remark. I know you don't believe it so not sure why you
> posted it. Call me when you get in town tomorrow.

Jeez, the sensitivity levels are at an all time high. I didn't intend
to blanket the AC. :-) Apologies offered.

I think that the real problem that I have is that the new process
isn't Coke v. Pepsi, it's more like Coke v Coke Classic. It has turned
ARIN into a quite different animal IMHO.

I'll be at Jackson's in RTC by 7! :-)

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.

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

From martin.hannigan at batelnet.bs  Thu Jul 23 09:04:18 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 23 Jul 2009 09:04:18 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087914E03@ex1.cait.wustl.edu>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC09F7@PRVPVSMAIL07.corp.twcable.com>
	<4607e1d50907230540h18ba0a09p6de95af39e99928c@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087914E03@ex1.cait.wustl.edu>
Message-ID: <4607e1d50907230604m1146eb4dwc92f2745b5e59453@mail.gmail.com>

On Thu, Jul 23, 2009 at 8:50 AM, Bill Darte<BillD at cait.wustl.edu> wrote:
> Apologies accepted....none necessary in my opinion....
> But how could I hold a grudge for this, if you didn't for me addressing you
> as Mary Hannigan in a distant post... ;-)


Hey now that's off topic! :-)


From schiller at uu.net  Thu Jul 23 12:08:00 2009
From: schiller at uu.net (Jason Schiller)
Date: Thu, 23 Jul 2009 12:08:00 -0400 (EDT)
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <4D8B3E14-5A5A-4CD3-9EAA-174E8C5163F7@delong.com>
Message-ID: <Pine.GSO.4.20.0907231049270.4641-100000@meno.corp.us.uu.net>

OK, first off let me say I am not arguing for a petition, but rather
trying to ask a question to see if a debate stirs up.  

(I often try to ask the hard questions when discussing policy because I
think they need to be considered and addressed.  Unfortunately I think
most people believe this makes me in favor or opposed to a particular
proposal...  Mr chairman, I am neither in favor nor against this proposal
until debate around my questions is discussed.) 

On Wed, 22 Jul 2009, Owen DeLong wrote:

> On Jul 22, 2009, at 1:53 PM, Martin Hannigan wrote:
> 
> Right.  It will push additional 4-byte allocations (after 2010) out by
> some amount of time (not much, IIRC). Until January, 2010, the
> distinction will remain and you can apply for whichever type of ASN
> you prefer.
> 
> Is that a problem? Why?

The original (now current) 2005-9 policy intended to set dates when ARIN
would:

1. start assigning 32 bit ASNs by request and 16 bit by default
2. start assigning 32 bit ASNs by default and 16 bit by request
3. make no distinction 

The rationale included:

1. allow providers to get a 32 bit ASN to enable them to prepare for
supporting 32 bit ASNs prior to the depletion of the 16 bit ASNs.

2. send a message to vendors that there is a real date when 32 bit ASNs
will need to be supported

3. Create some certainty about the date when 32 bit ASNs will become
common (and hence a reasonable expectation the providers will be ready to
support it by then).

-----

Marla's abandoned proposal 87 to "Extend 16 bit ASN Assignments" intended
to push the date where ARIN makes no distinction out by one year.  This is
to address the concern that more time is needed for the vendors and / or
providers to be able to support 32 bit ASNs in a real way.

-----

The current suggested implementation plan does address the concern of
extending the date when vendors and providers have to support 32 bit ASNs
in a real way.

However, it negates much of the original intent the now current policy
2005-9.  It removes the date where it is reasonable to expect that vendors
and providers should support 32 bit ASNs.  And based on my read of this
interpretation, post 2010 providers will not be able to request a higher
valued ASN (over the 16 bit boundary) in order to test and prepare for
supporting 32 bit ASN.  In other words I can get a 32 bit ASN through
December and test, but if I don't feel the need to test prior to December,
then my next chance to get one is whenever we run out of 16 bit ASNs.

-----

So the question is does the community still feel we need to send a message
to the vendors and the providers that they need to support 32 bit ASNs in
a real way?

Does the community feel there is value in arbitrarily setting a date to
aid in setting a reasonable expectation of when vendors and providers
need to be able to support 32 bit ASNs in a real way?

Or is vendor support and provider support sufficiently advanced that is is
no longer a concern?

If vendor support and / or provider support is not sufficiently advanced,
is the community confident that they will be on the date that 16 bit ASNs
deplete?

Does the community feel that removal of the date and giving out low
numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
needing to support 32 bit ASNs" will be out of sight and out of mind, and
then suddenly and surprisingly re-emerge on some unknown date when the
lowest valued 32 bit ASN clicks over that 16 bit boundary?

Does the community think there is value in being able to request a higher
valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
available to allow providers to test and prepare for supporting 32 bit
ASNs?  

----

The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
abandoned by the AC because the ARIN staff has now made an
implementation plan to combine both sets of numbers into one pool, and
issue in numerical order starting with the lowest numbers first
(starting in January 2010). With this plan in place the intention of
this proposal is addressed and the need for this proposal no longer
exists."
 
-----

> If you still feel that this policy is useful or necessary in light of  
> staff's
> clarification of how they would process requests after 1/1/2010,
> please do petition, and, please elaborate on why you think the
> policy is still needed.
> 

I think the question is rather if the community feels staff's recent
interpretation of the policy is in line with the original intent, and if
not, then a new proposal needs to be floated to give clear guidance to
staff.  That new proposal needs to also address Marla, et al, concerns
about extending the life of 16 bit ASNs to some extent.

__Jason



From martin.hannigan at batelnet.bs  Thu Jul 23 12:34:14 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 23 Jul 2009 12:34:14 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <Pine.GSO.4.20.0907231049270.4641-100000@meno.corp.us.uu.net>
References: <4D8B3E14-5A5A-4CD3-9EAA-174E8C5163F7@delong.com>
	<Pine.GSO.4.20.0907231049270.4641-100000@meno.corp.us.uu.net>
Message-ID: <4607e1d50907230934q2784deb3tc9e99db2bfe077c4@mail.gmail.com>

On Thu, Jul 23, 2009 at 12:08 PM, Jason Schiller<schiller at uu.net> wrote:
> OK, first off let me say I am not arguing for a petition, but rather
> trying to ask a question to see if a debate stirs up.
>
> (I often try to ask the hard questions when discussing policy because I
> think they need to be considered and addressed. ?Unfortunately I think
> most people believe this makes me in favor or opposed to a particular
> proposal... ?Mr chairman, I am neither in favor nor against this proposal
> until debate around my questions is discussed.)
>
> On Wed, 22 Jul 2009, Owen DeLong wrote:
>
>> On Jul 22, 2009, at 1:53 PM, Martin Hannigan wrote:
>>
>> Right. ?It will push additional 4-byte allocations (after 2010) out by
>> some amount of time (not much, IIRC). Until January, 2010, the
>> distinction will remain and you can apply for whichever type of ASN
>> you prefer.
>>
>> Is that a problem? Why?
>
> The original (now current) 2005-9 policy intended to set dates when ARIN
> would:
>
> 1. start assigning 32 bit ASNs by request and 16 bit by default
> 2. start assigning 32 bit ASNs by default and 16 bit by request
> 3. make no distinction
>
> The rationale included:
>
> 1. allow providers to get a 32 bit ASN to enable them to prepare for
> supporting 32 bit ASNs prior to the depletion of the 16 bit ASNs.
>
> 2. send a message to vendors that there is a real date when 32 bit ASNs
> will need to be supported
>
> 3. Create some certainty about the date when 32 bit ASNs will become
> common (and hence a reasonable expectation the providers will be ready to
> support it by then).
>
> -----
>
> Marla's abandoned proposal 87 to "Extend 16 bit ASN Assignments" intended
> to push the date where ARIN makes no distinction out by one year. ?This is
> to address the concern that more time is needed for the vendors and / or
> providers to be able to support 32 bit ASNs in a real way.
>
> -----
>
> The current suggested implementation plan does address the concern of
> extending the date when vendors and providers have to support 32 bit ASNs
> in a real way.
>
> However, it negates much of the original intent the now current policy
> 2005-9. ?It removes the date where it is reasonable to expect that vendors
> and providers should support 32 bit ASNs. ?And based on my read of this
> interpretation, post 2010 providers will not be able to request a higher
> valued ASN (over the 16 bit boundary) in order to test and prepare for
> supporting 32 bit ASN. ?In other words I can get a 32 bit ASN through
> December and test, but if I don't feel the need to test prior to December,
> then my next chance to get one is whenever we run out of 16 bit ASNs.
>
> -----
>
> So the question is does the community still feel we need to send a message
> to the vendors and the providers that they need to support 32 bit ASNs in
> a real way?
>
> Does the community feel there is value in arbitrarily setting a date to
> aid in setting a reasonable expectation of when vendors and providers
> need to be able to support 32 bit ASNs in a real way?
>
> Or is vendor support and provider support sufficiently advanced that is is
> no longer a concern?
>
> If vendor support and / or provider support is not sufficiently advanced,
> is the community confident that they will be on the date that 16 bit ASNs
> deplete?
>
> Does the community feel that removal of the date and giving out low
> numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
> needing to support 32 bit ASNs" will be out of sight and out of mind, and
> then suddenly and surprisingly re-emerge on some unknown date when the
> lowest valued 32 bit ASN clicks over that 16 bit boundary?
>
> Does the community think there is value in being able to request a higher
> valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
> available to allow providers to test and prepare for supporting 32 bit
> ASNs?
>
> ----
>
> The AC stated, "Proposal #87: Extend 16 bit ASN Assignments has been
> abandoned by the AC because the ARIN staff has now made an
> implementation plan to combine both sets of numbers into one pool, and
> issue in numerical order starting with the lowest numbers first
> (starting in January 2010). With this plan in place the intention of
> this proposal is addressed and the need for this proposal no longer
> exists."
>
> -----
>
>> If you still feel that this policy is useful or necessary in light of
>> staff's
>> clarification of how they would process requests after 1/1/2010,
>> please do petition, and, please elaborate on why you think the
>> policy is still needed.
>>
>
> I think the question is rather if the community feels staff's recent
> interpretation of the policy is in line with the original intent, and if
> not, then a new proposal needs to be floated to give clear guidance to
> staff. ?That new proposal needs to also address Marla, et al, concerns
> about extending the life of 16 bit ASNs to some extent.


I had intended to follow up with that and you did a superb job in a
much more detailed fashion. This was my original point in the earlier
message to Scott as well when I said that I felt that the "original
intent" had not been accounted for. The withdrawal of Marla's proposal
is fine by me; Marla doesn't need my protection. Administratively
addressing a proposal to modify a policy that had already reached
consenus to condense the workload  = FAIL in my [humble] opinion.

Best,

Martin


From bicknell at ufp.org  Thu Jul 23 13:35:48 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Jul 2009 13:35:48 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <Pine.GSO.4.20.0907231049270.4641-100000@meno.corp.us.uu.net>
References: <4D8B3E14-5A5A-4CD3-9EAA-174E8C5163F7@delong.com>
	<Pine.GSO.4.20.0907231049270.4641-100000@meno.corp.us.uu.net>
Message-ID: <20090723173548.GA77818@ussenterprise.ufp.org>

In a message written on Thu, Jul 23, 2009 at 12:08:00PM -0400, Jason Schiller wrote:
> So the question is does the community still feel we need to send a message
> to the vendors and the providers that they need to support 32 bit ASNs in
> a real way?

I believe that message was sent, and received.  While the vendors are
not quite where I would like them to be in terms of availability, I
don't think sending more messages at this point is going to be
productive.

> Does the community feel there is value in arbitrarily setting a date to
> aid in setting a reasonable expectation of when vendors and providers
> need to be able to support 32 bit ASNs in a real way?

I believe there is value in knowing the date, but it need not be
arbitrary.  For instance, 16 bit ASN's will run out in less than two
years it would appear, which is a fairly well known date.

> Or is vendor support and provider support sufficiently advanced that is is
> no longer a concern?

AFAIK, the vast majority of the vendors have working code at this point.
The issue is that it may not be in all of the various forms they release
code yet, but that is going to be a function of their release cycles and
no amount of policy will change that.

> Does the community feel that removal of the date and giving out low
> numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
> needing to support 32 bit ASNs" will be out of sight and out of mind, and
> then suddenly and surprisingly re-emerge on some unknown date when the
> lowest valued 32 bit ASN clicks over that 16 bit boundary?

I'm not sure I think it will surprisingly reemerge, as the run-out date
is fairly well predicted, but it will re-emerge.  From an ISP
perspective, it only takes one customer needing this feature for you to
have to go off and do the work to figure out what you need to do; so I
don't think a short reprieve makes us really go backwards in terms of
support.  If anything, it may provide for a smoother transition as
providers can roll out the code in normal cycles, rather than a router
at a time as customers demand it.

> Does the community think there is value in being able to request a higher
> valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
> available to allow providers to test and prepare for supporting 32 bit
> ASNs?  

This is the only area where I have some concern.  I think folks should
be able to show up and say "I want a 32 bit ASN" while there are 16 bit
ones still in the free pool, be it for testing or because they want to
leave 16 bit ones for those who need them.

That said, all indications are that you could probably count the number
of folks who would request and use 32 bit ASN's on one hand during the
timeframe in question.  Because of that I have my doubts it is worth the
community, ac, board and staff time to pass a policy at this point.  We
do have many other issues on the table. :)

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

From john.sweeting at twcable.com  Thu Jul 23 13:58:25 2009
From: john.sweeting at twcable.com (John Sweeting)
Date: Thu, 23 Jul 2009 13:58:25 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - July 2009
In-Reply-To: <20090723173548.GA77818@ussenterprise.ufp.org>
Message-ID: <C68E1D01.8002%john.sweeting@twcable.com>

I would just like to echo my support and agreement of the points Leo has
made below. Thanks.


On 7/23/09 1:35 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Thu, Jul 23, 2009 at 12:08:00PM -0400, Jason Schiller
> wrote:
>> > So the question is does the community still feel we need to send a message
>> > to the vendors and the providers that they need to support 32 bit ASNs in
>> > a real way?
> 
> I believe that message was sent, and received.  While the vendors are
> not quite where I would like them to be in terms of availability, I
> don't think sending more messages at this point is going to be
> productive.
> 
>> > Does the community feel there is value in arbitrarily setting a date to
>> > aid in setting a reasonable expectation of when vendors and providers
>> > need to be able to support 32 bit ASNs in a real way?
> 
> I believe there is value in knowing the date, but it need not be
> arbitrary.  For instance, 16 bit ASN's will run out in less than two
> years it would appear, which is a fairly well known date.
> 
>> > Or is vendor support and provider support sufficiently advanced that is is
>> > no longer a concern?
> 
> AFAIK, the vast majority of the vendors have working code at this point.
> The issue is that it may not be in all of the various forms they release
> code yet, but that is going to be a function of their release cycles and
> no amount of policy will change that.
> 
>> > Does the community feel that removal of the date and giving out low
>> > numbered 32 bit ASNs will slow adoption of 32 bit ASNs as the "problem of
>> > needing to support 32 bit ASNs" will be out of sight and out of mind, and
>> > then suddenly and surprisingly re-emerge on some unknown date when the
>> > lowest valued 32 bit ASN clicks over that 16 bit boundary?
> 
> I'm not sure I think it will surprisingly reemerge, as the run-out date
> is fairly well predicted, but it will re-emerge.  From an ISP
> perspective, it only takes one customer needing this feature for you to
> have to go off and do the work to figure out what you need to do; so I
> don't think a short reprieve makes us really go backwards in terms of
> support.  If anything, it may provide for a smoother transition as
> providers can roll out the code in normal cycles, rather than a router
> at a time as customers demand it.
> 
>> > Does the community think there is value in being able to request a higher
>> > valued (over the 16 bit boundary) 32 bit ASN when smaller valued ASNs are
>> > available to allow providers to test and prepare for supporting 32 bit
>> > ASNs? 
> 
> This is the only area where I have some concern.  I think folks should
> be able to show up and say "I want a 32 bit ASN" while there are 16 bit
> ones still in the free pool, be it for testing or because they want to
> leave 16 bit ones for those who need them.
> 
> That said, all indications are that you could probably count the number
> of folks who would request and use 32 bit ASN's on one hand during the
> timeframe in question.  Because of that I have my doubts it is worth the
> community, ac, board and staff time to pass a policy at this point.  We
> do have many other issues on the table. :)
> 
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> 
> 
> _______________________________________________
> 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 and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090723/109e5f49/attachment.htm>

From tedm at ipinc.net  Thu Jul 23 18:24:55 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 23 Jul 2009 15:24:55 -0700
Subject: [arin-ppml] The price of address space
In-Reply-To: <4A684903.60009@cisco.com>
References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A684903.60009@cisco.com>
Message-ID: <4A68E337.7010802@ipinc.net>

Eliot Lear wrote:
> On 7/22/09 11:50 PM, michael.dillon at bt.com wrote:
>> How cheap do IPv4 addresses need to be to make it worthwhile for an
>> equipment vendor to buy up addresses today to drive up the price and
>> make it worthwhile for the market to buy carrier grade NAT boxes?
>>    
> 
> If you attend next week's IETF in Sweden, you will see quite a number of 
> Cisco employees involved in nearly every aspect of IPv6, including 
> transition technologies.  We are there because we continue to believe 
> that there is no Plan B(*), that IPv6 is the best way for the Internet 
> to grow. 

Tell your coworkers that until Linksys-owned-by-Cisco gear gets IPv6
buttons in it, IPv6 ain't a real thing to any org under 50 employees.

The RVS4000 is a good first step - now, let's extend that code to the 
rest of the Linksys product line.

You don't want to be embarrassed by DD-WRT, after all, do you?

Ted


From ptimmins at clearrate.com  Thu Jul 23 19:31:31 2009
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Thu, 23 Jul 2009 19:31:31 -0400
Subject: [arin-ppml] The price of address space
In-Reply-To: <4A68E337.7010802@ipinc.net>
References: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net><4A684903.60009@cisco.com>
	<4A68E337.7010802@ipinc.net>
Message-ID: <B98837F93D40A74D8656EAE7C1F57C5659DBCF@EXCHANGE1.corp.clearrate.net>

And while you're at it, have them update the
Sipura-owned-by-Linksys-owned-by-Cisco gear too, as those often contain
routers too, and IPv6 support will end a lot of NAT headaches.

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Ted Mittelstaedt
Sent: Thursday, July 23, 2009 6:25 PM
To: Eliot Lear
Cc: ppml at arin.net; address-policy-wg at ripe.net
Subject: Re: [arin-ppml] The price of address space

Eliot Lear wrote:
> On 7/22/09 11:50 PM, michael.dillon at bt.com wrote:
>> How cheap do IPv4 addresses need to be to make it worthwhile for an
>> equipment vendor to buy up addresses today to drive up the price and
>> make it worthwhile for the market to buy carrier grade NAT boxes?
>>    
> 
> If you attend next week's IETF in Sweden, you will see quite a number
of 
> Cisco employees involved in nearly every aspect of IPv6, including 
> transition technologies.  We are there because we continue to believe 
> that there is no Plan B(*), that IPv6 is the best way for the Internet

> to grow. 

Tell your coworkers that until Linksys-owned-by-Cisco gear gets IPv6
buttons in it, IPv6 ain't a real thing to any org under 50 employees.

The RVS4000 is a good first step - now, let's extend that code to the 
rest of the Linksys product line.

You don't want to be embarrassed by DD-WRT, after all, do you?

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 scottleibrand at gmail.com  Fri Jul 24 14:36:04 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jul 2009 11:36:04 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation of
 IPv4 Blocks to RIRs
Message-ID: <4A69FF14.2010007@gmail.com>

All,

This is an update on the status of the Global Policy for the Allocation
of IPv4 Blocks to Regional Internet Registries, which is policy proposal
2009-3 here in the ARIN region. Please also see below for an updated
version of 2009-3.

At APNIC, the proposal (Proposal-069-v003) was adopted on 22 May 2009.

At AfriNIC, the proposal (Afpol-v4gb200903) was approved at their last
meeting, last call was completed on 6th June 2009, and the policy is
currently awaiting ratification.

At LACNIC, the proposal (LAC-2009-01 v2) has been approved and is in
Last Call until 27 July 2009:
http://lacnic.net/en/politicas/propuesta-politicas.html

At RIPE, the proposal (RIPE Policy Proposal 2009-01) is still under
discussion.

And here in the ARIN region, the proposal is also under discussion. In
addition, the ARIN AC just sent a revised version of the policy proposal
to ARIN for staff and legal review. This new version includes the
revised text I suggested to PPML on June 6, 2009 changing section A,
paragraph 2, and is included below.

Links to each RIR's proposal text, status pages, etc., can be found at
the bottom of:
http://www.icann.org/en/announcements/announcement-12may09-en.htm


The revised Policy statement here in the ARIN region reads:

This document describes the policy governing the allocation of IPv4
address space from the IANA to the Regional Internet Registries (RIRs).
This document does not stipulate performance requirements in the
provision of services by IANA to an RIR in accordance with this policy.
Such requirements should be specified by appropriate agreements among
the RIRs and ICANN.

This policy is to be implemented in two phases.

A. Phase I: Recovery of IPv4 Address Space

Upon ratification of this policy by the ICANN Board of Directors the
IANA shall establish a mechanism to receive IPv4 address space which is
returned to it by the RIRs, and hold that address space in a 'recovered
IPv4 pool'.

Each RIR through their respective chosen policies and strategies may
recover IPv4 address space which is under their administration and
designate any such space for return to the IANA. Each RIR shall at
quarterly intervals return any such designated address space to the IANA
in aggregated blocks of /24 or larger, for inclusion in the recovered
IPv4 pool.

During Phase I, no allocations will be made from the recovered IPv4
pool. Return of recovered address space (as described above) will
continue throughout Phase II.

B. Phase II: Allocation of Recovered IPv4 address space by the IANA

Upon ratification of this policy by the ICANN Board of Directors and a
declaration by the IANA that its existing free pool of unallocated IPv4
address space is depleted; Global Addressing Policy ASO-001-2 (adopted
by ICANN Board 8 April 2005) is rescinded. IANA will then commence to
allocate the IPv4 address space from the recovered IPv4 pool.

1. The following definitions apply to this policy:

a. Recovered Address Space. Recovered address space is that address
space that is returned to an RIR as a result of any activity that seeks
to reclaim unused address space or is voluntarily returned to the RIR or
is reclaimed by the RIR as a result of legal action or abuse
determination. Recovered address space does not include that address
space that is reclaimed because of non-payment of contractual fees whose
reclamation date is less than 1 year at the time of the report.

b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4
address space held by an RIR to include recovered address space not yet
returned less that address space that is committed in accordance with
the RIR's reservation policy and practices.

c. Aggregated address blocks. Aggregated address blocks are contiguous
prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24
and 10.0.1.0/24 are two contiguous prefixes that can be combined to form
an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two
contiguous prefixes that cannot be combined on a natural bit boundary to
form an aggregated block.

d. Legacy address space. IPv4 address space allocated or assigned prior
to the creation of the RIR.

2. Allocation of IPv4 Address Space

a. For the purposes of this policy, an 'IPv4 allocation period' is
defined as a 6-month period following 1 March or 1 September in each year.

b. At the beginning of each IPv4 allocation period, the IANA will
determine the 'IPv4 allocation unit' for that period, as 1/10 of its
IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary.
The minimum 'IPv4 allocation unit' size will be a /24.

c. In each allocation period, each RIR may issue one IPv4 request to the
IANA. Providing that the RIR satisfies the allocation criteria described
in paragraph B.2, the IANA will allocate a single allocation unit,
composed of the smallest possible number of blocks available in its IPv4
address pool.

3. IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA
when the total of its IPv4 address holdings is less than 50% of the
current IPv4 allocation unit, and providing that it has not already
received an IPv4 allocation from the IANA during the current IPv4
allocation period.

4. Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1)
allocation unit by the IANA. If an allocation unit is not available,
then the IANA will issue this block as soon as one is available. This
allocation will be made regardless of the newly formed RIR's projected
utilization figures and shall be independent of the IPv4 address space
that may have been transferred to the new RIR by the already existing
RIRs as part of the formal transition process.

5. Reporting

a. All returned space is to be recorded in an IANA-published log of IPv4
address space transactions, with each log entry detailing the returned
address block, the date of the return, and the returning RIR.

b. All allocated space is also to be recorded in this IANA-published log
of IPv4 address space transactions, with each log entry detailing the
address blocks, the date of the allocation and the recipient RIR.

c. The IANA will maintain a public registry of the current disposition
of all IPv4 address space, detailing all reservations and current
allocations and current IANA-held address space that is unallocated.

d) The IANA may make public announcements of IPv4 address block
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address Space"
page of the IANA website and may make announcements to its own
appropriate announcement lists. The IANA announcements will be limited
to which address ranges, the time of allocation and to which Registry
they have been allocated.


Rationale:

This is version 3 of the policy proposal. It is the form that reached
consensus following community discussion at the APNIC 27 Policy SIG on
Thursday 26 February 2008 and endorsement at the APNIC Member Meeting
(AMM) on Friday 27 February 2008. With the depletion of the IANA free
pool of IPv4 address space, the current policy regarding the allocation
of IPv4 address space to the RIRs will become obsolete. The RIRs may,
according to their individual policies and procedures, recover IPv4
address space. This policy provides a mechanism for the RIRs to retro
allocate the recovered IPv4 address space to the IANA and provides the
IANA the policy by which it can allocate it back to the RIRs on a needs
basis. This policy creates a new global pool of IPv4 address space that
can be allocated where it is needed on a global basis without a transfer
of address space between the RIRs.

Specifically this revision does the following:

a. Adds the definition of "aggregated block" as paragraph 1.3.

b. Adds to paragraph 2.b the minimum allocation size which can be
allocated by IANA.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Below are 3 exemplar scenarios of the execution of this policy after
Phase II is in force. These are not part of the rationale but are
provided for illustrative purposes.

Example 1:


On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 3,276 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /21 (2,048 addresses).

3. Each RIR can request and receive a single allocation unit equivalent
to a /21 worth of addresses.

4. While IANA may not be able to allocate a contiguous /21 and can
allocate noncontiguous smaller blocks equivalent to a /21 worth of
addresses.

Example 2:

On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 409 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /24 (256 addresses).

3. Each RIR can request and receive a single allocation unit equivalent
to a /24 worth of addresses.

4. As the minimum size of address space returned to IANA is /24, IANA
can allocate a contiguous range of addresses that amount to a /24.

Example 3:

On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses)
worth of IPv4 addresses.

1. IANA calculates that 1/10 of this space is 204 addresses.

2. IANA rounds this down to the next bit boundary, which creates a
minimum allocation size of /25 (128 addresses).

3. A /25 is smaller than the minimum permissible allocation size under
this policy. A /25 is smaller than the minimum permissible allocation
size under this policy. Therefore, IANA is unable to make an allocation
until more address space is received.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX


-Scott


From bill at herrin.us  Fri Jul 24 15:45:21 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 24 Jul 2009 15:45:21 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <4A69FF14.2010007@gmail.com>
References: <4A69FF14.2010007@gmail.com>
Message-ID: <3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>

On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com> wrote:
> This is an update on the status of the Global Policy for the Allocation
> of IPv4 Blocks to Regional Internet Registries, which is policy proposal
> 2009-3 here in the ARIN region. Please also see below for an updated
> version of 2009-3.
[...]
> Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration and
> designate any such space for return to the IANA. Each RIR shall at
> quarterly intervals return any such designated address space to the IANA
> in aggregated blocks of /24 or larger, for inclusion in the recovered
> IPv4 pool.

Scott,

Let's parse that: Each RIR [...] may [...] designate any such space
for return to the IANA.

I object to the intentionally ambiguous and potentially dishonest use
of the word "may" here. Policy should not describe what we might or
might not do, it should describe what we will and won't do.

If the intention is to establish an IANA method for accepting returns
which we might or might not later authorize in some other ARIN policy,
try replacing "may" with something more precise like "is permitted but
not required to."

If the intention is that we in fact do return space to IANA as a
consequence of this policy then replace "may" with "will" and describe
the criteria for which space returned to ARIN will be subsequently be
returned to IANA.

Regards,
Bill Herrin


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


From kkargel at polartel.com  Fri Jul 24 15:54:41 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 24 Jul 2009 14:54:41 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D89@mail>

> 
> Let's parse that: Each RIR [...] may [...] designate any such space
> for return to the IANA.
> 
> I object to the intentionally ambiguous and potentially dishonest use
> of the word "may" here. Policy should not describe what we might or
> might not do, it should describe what we will and won't do.

I agree.  Without an explicitly associated 'must' or 'may not' then 'may' is
meaningless.  The same applies to "is permitted" or "should".  We don't need
rules to allow anything that is not otherwise proscribed.

Anything that does not describe a requirement or an exception is just excess
verbiage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment.bin>

From kkargel at polartel.com  Fri Jul 24 15:55:18 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 24 Jul 2009 14:55:18 -0500
Subject: [arin-ppml] FW: Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8A@mail>


> 
> Let's parse that: Each RIR [...] may [...] designate any such space
> for return to the IANA.
> 
> I object to the intentionally ambiguous and potentially dishonest use
> of the word "may" here. Policy should not describe what we might or
> might not do, it should describe what we will and won't do.

I agree.  Without an explicitly associated 'must' or 'may not' then 'may' is
meaningless.  The same applies to "is permitted" or "should".  We don't need
rules to allow anything that is not otherwise proscribed.

Anything that does not describe a requirement or an exception is just excess
verbiage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin>

From scottleibrand at gmail.com  Fri Jul 24 16:03:34 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jul 2009 13:03:34 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
 of IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
Message-ID: <4A6A1396.6060901@gmail.com>



William Herrin wrote:
> On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com> wrote:
>   
>> This is an update on the status of the Global Policy for the Allocation
>> of IPv4 Blocks to Regional Internet Registries, which is policy proposal
>> 2009-3 here in the ARIN region. Please also see below for an updated
>> version of 2009-3.
>>     
> [...]
>   
>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration and
>> designate any such space for return to the IANA. Each RIR shall at
>> quarterly intervals return any such designated address space to the IANA
>> in aggregated blocks of /24 or larger, for inclusion in the recovered
>> IPv4 pool.
>>     
>
> Scott,
>
> Let's parse that: Each RIR [...] may [...] designate any such space
> for return to the IANA.
>
> I object to the intentionally ambiguous and potentially dishonest use
> of the word "may" here. Policy should not describe what we might or
> might not do, it should describe what we will and won't do.
>   

The background here, which I mentioned in a message on 6/18, is this:

"Those discussions finally made it clear to me that one of the reasons 
2009-3 is such a difficult policy to get consensus on is that the 
original policy, as proposed, is a global policy proposal that has some 
local policy aspects, namely that requires each RIR to return reclaimed 
space.  Ideally, global policies are supposed to maintain a clean 
separation from local policies: global policy is supposed to only govern 
the relationship between the IANA and the RIRs, and local policy defines 
what the RIR can do internally."

"As a side effect of the blurring of global and local policy in the 
current revision of 2009-3, we (and most of the other RIRs) are having 
an interesting debate about exactly which space should be covered by the 
policy (such as legacy vs. non-legacy), and some people are 
uncomfortable even with a legacy-only requirement.  So, as a result of a 
suggestion on the floor at LACNIC, and in an attempt to restore the 
proper separation between global and local policy, I drafted the 
following text for the 2nd paragraph of section A"

> If the intention is to establish an IANA method for accepting returns
> which we might or might not later authorize in some other ARIN policy,
> try replacing "may" with something more precise like "is permitted but
> not required to."
>   

That is exactly what is intended.  I have no objection to replacing 
"may" with "is permitted but
not required to", if folks think that would add clarity.  To me, they 
mean the same thing.


> If the intention is that we in fact do return space to IANA as a
> consequence of this policy then replace "may" with "will" and describe
> the criteria for which space returned to ARIN will be subsequently be
> returned to IANA.

As above, the intent is to move such policy out of the Global Policy and 
make it the subject of local policy.

-Scott


From bill at herrin.us  Fri Jul 24 16:40:55 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 24 Jul 2009 16:40:55 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <4A6A1396.6060901@gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
	<4A6A1396.6060901@gmail.com>
Message-ID: <3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>

On Fri, Jul 24, 2009 at 4:03 PM, Scott Leibrand<scottleibrand at gmail.com> wrote:
> William Herrin wrote:
>>
>> On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com>
>> wrote:
>>> This is an update on the status of the Global Policy for the Allocation
>>> of IPv4 Blocks to Regional Internet Registries, which is policy proposal
>>> 2009-3 here in the ARIN region. Please also see below for an updated
>>> version of 2009-3.
>>>
>> If the intention is to establish an IANA method for accepting returns
>> which we might or might not later authorize in some other ARIN policy,
>> try replacing "may" with something more precise like "is permitted but
>> not required to."
>>
>
> That is exactly what is intended. ?I have no objection to replacing "may"
> with "is permitted but
> not required to", if folks think that would add clarity. ?To me, they mean
> the same thing.

Hi Scott,

Just a quick stab at it then:

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

Instead:

Through their respective chosen policies and strategies, each RIR will
recover unused, misallocated and voluntarily returned IPv4 address
space under their administration from their registrants. Where the
RIR's policies authorize returning said IPv4 address space to IANA,
the RIR shall set the address space aside and designate it for return
to IANA.

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 24 16:55:41 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 24 Jul 2009 13:55:41 -0700
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <4A6A1396.6060901@gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
	<4A6A1396.6060901@gmail.com>
Message-ID: <05E2A619-2221-4C9D-B1AD-B107CD10A19E@delong.com>

Personally, I think "Is permitted but not required to" and "may" have  
identical
meanings and that speaking of extra words, using 10 syllables (6  
words) to
say what can be said with 1 (1 word) is, indeed, extra words.

Owen

On Jul 24, 2009, at 1:03 PM, Scott Leibrand wrote:

>
>
> William Herrin wrote:
>> On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com 
>> > wrote:
>>
>>> This is an update on the status of the Global Policy for the  
>>> Allocation
>>> of IPv4 Blocks to Regional Internet Registries, which is policy  
>>> proposal
>>> 2009-3 here in the ARIN region. Please also see below for an updated
>>> version of 2009-3.
>>>
>> [...]
>>
>>> Each RIR through their respective chosen policies and strategies may
>>> recover IPv4 address space which is under their administration and
>>> designate any such space for return to the IANA. Each RIR shall at
>>> quarterly intervals return any such designated address space to  
>>> the IANA
>>> in aggregated blocks of /24 or larger, for inclusion in the  
>>> recovered
>>> IPv4 pool.
>>>
>>
>> Scott,
>>
>> Let's parse that: Each RIR [...] may [...] designate any such space
>> for return to the IANA.
>>
>> I object to the intentionally ambiguous and potentially dishonest use
>> of the word "may" here. Policy should not describe what we might or
>> might not do, it should describe what we will and won't do.
>>
>
> The background here, which I mentioned in a message on 6/18, is this:
>
> "Those discussions finally made it clear to me that one of the  
> reasons 2009-3 is such a difficult policy to get consensus on is  
> that the original policy, as proposed, is a global policy proposal  
> that has some local policy aspects, namely that requires each RIR to  
> return reclaimed space.  Ideally, global policies are supposed to  
> maintain a clean separation from local policies: global policy is  
> supposed to only govern the relationship between the IANA and the  
> RIRs, and local policy defines what the RIR can do internally."
>
> "As a side effect of the blurring of global and local policy in the  
> current revision of 2009-3, we (and most of the other RIRs) are  
> having an interesting debate about exactly which space should be  
> covered by the policy (such as legacy vs. non-legacy), and some  
> people are uncomfortable even with a legacy-only requirement.  So,  
> as a result of a suggestion on the floor at LACNIC, and in an  
> attempt to restore the proper separation between global and local  
> policy, I drafted the following text for the 2nd paragraph of  
> section A"
>
>> If the intention is to establish an IANA method for accepting returns
>> which we might or might not later authorize in some other ARIN  
>> policy,
>> try replacing "may" with something more precise like "is permitted  
>> but
>> not required to."
>>
>
> That is exactly what is intended.  I have no objection to replacing  
> "may" with "is permitted but
> not required to", if folks think that would add clarity.  To me,  
> they mean the same thing.
>
>
>> If the intention is that we in fact do return space to IANA as a
>> consequence of this policy then replace "may" with "will" and  
>> describe
>> the criteria for which space returned to ARIN will be subsequently be
>> returned to IANA.
>
> As above, the intent is to move such policy out of the Global Policy  
> and make it the subject of local policy.
>
> -Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From kkargel at polartel.com  Fri Jul 24 17:19:29 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 24 Jul 2009 16:19:29 -0500
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocationof IPv4 Blocks to RIRs
In-Reply-To: <05E2A619-2221-4C9D-B1AD-B107CD10A19E@delong.com>
References: <4A69FF14.2010007@gmail.com><3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com><4A6A1396.6060901@gmail.com>
	<05E2A619-2221-4C9D-B1AD-B107CD10A19E@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8F@mail>

> 
> Personally, I think "Is permitted but not required to" and "may" have
> identical
> meanings and that speaking of extra words, using 10 syllables (6
> words) to
> say what can be said with 1 (1 word) is, indeed, extra words.
> 

To carry that further just leave the whole thing out.  You can say 'may'
simply by not saying 'may not'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090724/7213e8dd/attachment.bin>

From cgrundemann at gmail.com  Fri Jul 24 16:55:18 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 24 Jul 2009 14:55:18 -0600
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
	<4A6A1396.6060901@gmail.com>
	<3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>
Message-ID: <443de7ad0907241355k576240b7j6674a1bc121ac1c9@mail.gmail.com>

On Fri, Jul 24, 2009 at 14:40, William Herrin<bill at herrin.us> wrote:
> On Fri, Jul 24, 2009 at 4:03 PM, Scott Leibrand<scottleibrand at gmail.com> wrote:
>> William Herrin wrote:
>>>
>>> On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com>
>>> wrote:
>>>> This is an update on the status of the Global Policy for the Allocation
>>>> of IPv4 Blocks to Regional Internet Registries, which is policy proposal
>>>> 2009-3 here in the ARIN region. Please also see below for an updated
>>>> version of 2009-3.
>>>>
>>> If the intention is to establish an IANA method for accepting returns
>>> which we might or might not later authorize in some other ARIN policy,
>>> try replacing "may" with something more precise like "is permitted but
>>> not required to."
>>>
>>
>> That is exactly what is intended. ?I have no objection to replacing "may"
>> with "is permitted but
>> not required to", if folks think that would add clarity. ?To me, they mean
>> the same thing.
>
> Hi Scott,
>
> Just a quick stab at it then:
>
>>>> Each RIR through their respective chosen policies and strategies may
>>>> recover IPv4 address space which is under their administration and
>>>> designate any such space for return to the IANA.
>
> Instead:
>
> Through their respective chosen policies and strategies, each RIR will
> recover unused, misallocated and voluntarily returned IPv4 address
> space under their administration from their registrants. Where the
> RIR's policies authorize returning said IPv4 address space to IANA,
> the RIR shall set the address space aside and designate it for return
> to IANA.

The problem with that Bill, is that it seems to be setting the policy
of what will be returned in the global policy text itself, which I
believe is exactly what Scott is attempting to avoid.

Without voicing support or opposition to the policy, commenting on the
revision alone; I believe that a "shall" would make for better policy
text and in this new context do exactly what <at least some> want:

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

To me this reads that each RIR sets their own policies for what they
will or will not recover for return and how they will acquire it;
which I (and I think Scott) believe(s) was the basic consensus from
the last meeting.  In other words, we could then adopt the global
policy with out any affects - until we passed the policy to define
what would be recovered for return and how.

In addition to maintaining Scott's intent while removing ambiguity, I
think this has the added benefit of being more likely to be accepted
by the regions who have already started adoption of this global
proposal due to the (maybe only slightly) stronger verbiage.

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





-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From bill at herrin.us  Fri Jul 24 17:32:32 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 24 Jul 2009 17:32:32 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <443de7ad0907241355k576240b7j6674a1bc121ac1c9@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
	<4A6A1396.6060901@gmail.com>
	<3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>
	<443de7ad0907241355k576240b7j6674a1bc121ac1c9@mail.gmail.com>
Message-ID: <3c3e3fca0907241432k76a35446y3c4fde847aaba052@mail.gmail.com>

On Fri, Jul 24, 2009 at 4:55 PM, Chris Grundemann<cgrundemann at gmail.com> wrote:
> Each RIR through their respective chosen policies and strategies shall
> recover IPv4 address space which is under their administration and
> designate such space for return to the IANA.


Hi Chris,

Here's another stab at wordsmithing:

Each RIR shall recover IPv4 address space which is under their
administration. Where authorized by their respective chosen policies
and strategies, each RIR shall designate such space for return to the
IANA.

The prior version too weakly makes the point that this policy only
describes -how- space will be returned to IANA. Some other local
policy is required to authorize any space's return in the first place.

One could reasonably interpret the prior language to mean that all
recovered space will be returned. Why talk about returning space at
all if you don't intend for space to be returned? You might not read
it that way, but such a reading is not unreasonable. Which means that
some folks will read it that way. Which means that either ARIN will
end up following that interpretation or the folks who read it that way
will be very upset with us for failing to.

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 rudi.daniel at gmail.com  Fri Jul 24 17:48:27 2009
From: rudi.daniel at gmail.com (RudOlph Daniel)
Date: Fri, 24 Jul 2009 17:48:27 -0400
Subject: [arin-ppml] Global policy- use of "may & should" ARIN-PPML
	Digest, Vol 49, Issue 15
Message-ID: <8aeeaff60907241448h6e2b354arfbe05327dbb9fa4@mail.gmail.com>

My tendency is to agree with Bill Herrin and Kevin on the use of "may" and
"should" in policy statemebts; but does the AC have a motive in the use of
such?

Rudi Daniel

>
>
> On Fri, Jul 24, 2009 at 2:36 PM, Scott Leibrand<scottleibrand at gmail.com>
> wrote:
> > This is an update on the status of the Global Policy for the Allocation
> > of IPv4 Blocks to Regional Internet Registries, which is policy proposal
> > 2009-3 here in the ARIN region. Please also see below for an updated
> > version of 2009-3.
> [...]
> > Each RIR through their respective chosen policies and strategies may
> > recover IPv4 address space which is under their administration and
> > designate any such space for return to the IANA. Each RIR shall at
> > quarterly intervals return any such designated address space to the IANA
> > in aggregated blocks of /24 or larger, for inclusion in the recovered
> > IPv4 pool.
>
> Scott,
>
> Let's parse that: Each RIR [...] may [...] designate any such space
> for return to the IANA.
>
> I object to the intentionally ambiguous and potentially dishonest use
> of the word "may" here. Policy should not describe what we might or
> might not do, it should describe what we will and won't do.
>
> If the intention is to establish an IANA method for accepting returns
> which we might or might not later authorize in some other ARIN policy,
> try replacing "may" with something more precise like "is permitted but
> not required to."
>
> If the intention is that we in fact do return space to IANA as a
> consequence of this policy then replace "may" with "will" and describe
> the criteria for which space returned to ARIN will be subsequently be
> returned to IANA.
>
> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 24 Jul 2009 14:54:41 -0500
> From: "Kevin Kargel" <kkargel at polartel.com>
> To: "William Herrin" <bill at herrin.us>,  "Scott Leibrand"
>        <scottleibrand at gmail.com>
> Cc: PPML <ppml at arin.net>
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
>        Allocationof IPv4 Blocks to RIRs
> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D89 at mail>
> Content-Type: text/plain; charset="us-ascii"
>
> >
> > Let's parse that: Each RIR [...] may [...] designate any such space
> > for return to the IANA.
> >
> > I object to the intentionally ambiguous and potentially dishonest use
> > of the word "may" here. Policy should not describe what we might or
> > might not do, it should describe what we will and won't do.
>
> I agree.  Without an explicitly associated 'must' or 'may not' then 'may'
> is
> meaningless.  The same applies to "is permitted" or "should".  We don't
> need
> rules to allow anything that is not otherwise proscribed.
>
> Anything that does not describe a requirement or an exception is just
> excess
> verbiage.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3224 bytes
> Desc: not available
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 24 Jul 2009 14:55:18 -0500
> From: "Kevin Kargel" <kkargel at polartel.com>
> To: "PPML" <ppml at arin.net>
> Subject: [arin-ppml] FW: Update on 2009-3: Global Policy for the
>        Allocationof IPv4 Blocks to RIRs
> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8A at mail>
> Content-Type: text/plain; charset="us-ascii"
>
>
> >
> > Let's parse that: Each RIR [...] may [...] designate any such space
> > for return to the IANA.
> >
> > I object to the intentionally ambiguous and potentially dishonest use
> > of the word "may" here. Policy should not describe what we might or
> > might not do, it should describe what we will and won't do.
>
> I agree.  Without an explicitly associated 'must' or 'may not' then 'may'
> is
> meaningless.  The same applies to "is permitted" or "should".  We don't
> need
> rules to allow anything that is not otherwise proscribed.
>
> Anything that does not describe a requirement or an exception is just
> excess
> verbiage.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3224 bytes
> Desc: not available
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 49, Issue 15
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090724/451ca71d/attachment.htm>

From scottleibrand at gmail.com  Fri Jul 24 17:53:00 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jul 2009 14:53:00 -0700
Subject: [arin-ppml] Global policy- use of "may & should" ARIN-PPML
 Digest, Vol 49, Issue 15
In-Reply-To: <8aeeaff60907241448h6e2b354arfbe05327dbb9fa4@mail.gmail.com>
References: <8aeeaff60907241448h6e2b354arfbe05327dbb9fa4@mail.gmail.com>
Message-ID: <4A6A2D3C.8070804@gmail.com>

My main reason for wording it the way I did was to accomplish something 
very similar to what Bill suggested, while keeping the text as close as 
possible to the original text.  Rewritten from scratch, I'd probably go 
with something closer to Bill's wording.

Does anyone else have any detailed feedback on how we should word this?

Thanks much,
Scott

RudOlph Daniel wrote:
> My tendency is to agree with Bill Herrin and Kevin on the use of "may" 
> and "should" in policy statemebts; but does the AC have a motive in 
> the use of such?
>
> Rudi Daniel
>
>
>
>     On Fri, Jul 24, 2009 at 2:36 PM, Scott
>     Leibrand<scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>>
>     wrote:
>     > This is an update on the status of the Global Policy for the
>     Allocation
>     > of IPv4 Blocks to Regional Internet Registries, which is policy
>     proposal
>     > 2009-3 here in the ARIN region. Please also see below for an updated
>     > version of 2009-3.
>     [...]
>     > Each RIR through their respective chosen policies and strategies may
>     > recover IPv4 address space which is under their administration and
>     > designate any such space for return to the IANA. Each RIR shall at
>     > quarterly intervals return any such designated address space to
>     the IANA
>     > in aggregated blocks of /24 or larger, for inclusion in the
>     recovered
>     > IPv4 pool.
>
>     Scott,
>
>     Let's parse that: Each RIR [...] may [...] designate any such space
>     for return to the IANA.
>
>     I object to the intentionally ambiguous and potentially dishonest use
>     of the word "may" here. Policy should not describe what we might or
>     might not do, it should describe what we will and won't do.
>
>     If the intention is to establish an IANA method for accepting returns
>     which we might or might not later authorize in some other ARIN policy,
>     try replacing "may" with something more precise like "is permitted but
>     not required to."
>
>     If the intention is that we in fact do return space to IANA as a
>     consequence of this policy then replace "may" with "will" and describe
>     the criteria for which space returned to ARIN will be subsequently be
>     returned to IANA.
>
>     Regards,
>     Bill Herrin
>
>
>     --
>     William D. Herrin ................ herrin at dirtside.com
>     <mailto:herrin at dirtside.com>  bill at herrin.us <mailto:bill at herrin.us>
>     3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>     Falls Church, VA 22042-3004
>
>
>     ------------------------------
>
>     Message: 3
>     Date: Fri, 24 Jul 2009 14:54:41 -0500
>     From: "Kevin Kargel" <kkargel at polartel.com
>     <mailto:kkargel at polartel.com>>
>     To: "William Herrin" <bill at herrin.us <mailto:bill at herrin.us>>,
>      "Scott Leibrand"
>            <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>>
>     Cc: PPML <ppml at arin.net <mailto:ppml at arin.net>>
>     Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the
>            Allocationof IPv4 Blocks to RIRs
>     Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D89 at mail>
>     Content-Type: text/plain; charset="us-ascii"
>
>     >
>     > Let's parse that: Each RIR [...] may [...] designate any such space
>     > for return to the IANA.
>     >
>     > I object to the intentionally ambiguous and potentially
>     dishonest use
>     > of the word "may" here. Policy should not describe what we might or
>     > might not do, it should describe what we will and won't do.
>
>     I agree.  Without an explicitly associated 'must' or 'may not'
>     then 'may' is
>     meaningless.  The same applies to "is permitted" or "should".  We
>     don't need
>     rules to allow anything that is not otherwise proscribed.
>
>     Anything that does not describe a requirement or an exception is
>     just excess
>     verbiage.
>     -------------- next part --------------
>     A non-text attachment was scrubbed...
>     Name: smime.p7s
>     Type: application/x-pkcs7-signature
>     Size: 3224 bytes
>     Desc: not available
>     URL:
>     <http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/cbe35cde/attachment-0001.bin>
>
>     ------------------------------
>
>     Message: 4
>     Date: Fri, 24 Jul 2009 14:55:18 -0500
>     From: "Kevin Kargel" <kkargel at polartel.com
>     <mailto:kkargel at polartel.com>>
>     To: "PPML" <ppml at arin.net <mailto:ppml at arin.net>>
>     Subject: [arin-ppml] FW: Update on 2009-3: Global Policy for the
>            Allocationof IPv4 Blocks to RIRs
>     Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49D8A at mail>
>     Content-Type: text/plain; charset="us-ascii"
>
>
>     >
>     > Let's parse that: Each RIR [...] may [...] designate any such space
>     > for return to the IANA.
>     >
>     > I object to the intentionally ambiguous and potentially
>     dishonest use
>     > of the word "may" here. Policy should not describe what we might or
>     > might not do, it should describe what we will and won't do.
>
>     I agree.  Without an explicitly associated 'must' or 'may not'
>     then 'may' is
>     meaningless.  The same applies to "is permitted" or "should".  We
>     don't need
>     rules to allow anything that is not otherwise proscribed.
>
>     Anything that does not describe a requirement or an exception is
>     just excess
>     verbiage.
>     -------------- next part --------------
>     A non-text attachment was scrubbed...
>     Name: smime.p7s
>     Type: application/x-pkcs7-signature
>     Size: 3224 bytes
>     Desc: not available
>     URL:
>     <http://lists.arin.net/pipermail/arin-ppml/attachments/20090724/d161873f/attachment.bin>
>
>     ------------------------------
>
>     _______________________________________________
>     ARIN-PPML mailing list
>     ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>
>     End of ARIN-PPML Digest, Vol 49, Issue 15
>     *****************************************
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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  Fri Jul 24 17:53:30 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 24 Jul 2009 15:53:30 -0600
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <3c3e3fca0907241432k76a35446y3c4fde847aaba052@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>
	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>
	<4A6A1396.6060901@gmail.com>
	<3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>
	<443de7ad0907241355k576240b7j6674a1bc121ac1c9@mail.gmail.com>
	<3c3e3fca0907241432k76a35446y3c4fde847aaba052@mail.gmail.com>
Message-ID: <443de7ad0907241453u318332f2t59059dc7e3987adb@mail.gmail.com>

On Fri, Jul 24, 2009 at 15:32, William Herrin<bill at herrin.us> wrote:
> On Fri, Jul 24, 2009 at 4:55 PM, Chris Grundemann<cgrundemann at gmail.com> wrote:
>> Each RIR through their respective chosen policies and strategies shall
>> recover IPv4 address space which is under their administration and
>> designate such space for return to the IANA.
>
>
> Hi Chris,
>
> Here's another stab at wordsmithing:
>
> Each RIR shall recover IPv4 address space which is under their
> administration. Where authorized by their respective chosen policies
> and strategies, each RIR shall designate such space for return to the
> IANA.

I like this best so far.

> The prior version too weakly makes the point that this policy only
> describes -how- space will be returned to IANA. Some other local
> policy is required to authorize any space's return in the first place.
>
> One could reasonably interpret the prior language to mean that all
> recovered space will be returned. Why talk about returning space at
> all if you don't intend for space to be returned? You might not read
> it that way, but such a reading is not unreasonable. Which means that
> some folks will read it that way. Which means that either ARIN will
> end up following that interpretation or the folks who read it that way
> will be very upset with us for failing to.

I can see that, and must agree - my vote is for revising the policy,
again, with your verbiage above -- I could probably even support it at
that point...
~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
>


-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From rudi.daniel at gmail.com  Fri Jul 24 17:57:57 2009
From: rudi.daniel at gmail.com (RudOlph Daniel)
Date: Fri, 24 Jul 2009 17:57:57 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 49, Issue 16
In-Reply-To: <mailman.4602.1248470748.14984.arin-ppml@arin.net>
References: <mailman.4602.1248470748.14984.arin-ppml@arin.net>
Message-ID: <8aeeaff60907241457q64e6c265xe4f76dd0151ea4db@mail.gmail.com>

>> Each RIR through their respective chosen policies and strategies may
>> recover IPv4 address space which is under their administration and
>> designate any such space for return to the IANA. Each RIR shall at
>> quarterly intervals return any such designated address space to the IANA
>> in aggregated blocks of /24 or larger, for inclusion in the recovered
>> IPv4 pool.

I would like to suggest "chosen policies and strategies (shall attempt to)
recover IPv4 address space"....

-- 
Rudi Daniel
Independent Consultant
e Business Implementation
www.svgpso.org
1 784 533 7321
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090724/57a2382d/attachment.htm>

From martin.hannigan at batelnet.bs  Fri Jul 24 21:23:15 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 24 Jul 2009 21:23:15 -0400
Subject: [arin-ppml] The price of address space
In-Reply-To: <28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
References: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com>
	<28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com>

There's already factual data and a derived host value that has been
published and presented at various RIR meetings.

That price was determined by an actual for cash transaction.

We also have hard evidence of ip addr leasing in the form of media.

This is old news at best. Search engines are your friends.

Yes, maybe it comes crashing down. Maybe. Too soon to tell.



On 7/22/09, michael.dillon at bt.com <michael.dillon at bt.com> wrote:
>> To be serious, I think it's unwise to extrapolate from your
>> anecdote about someone offering a six figure sum for a /20.
>
> Not at all. In several years of discussion of IP address markets,
> this is the first time that I have seen someone put an actual
> dollar value on an address block. Granted, it was an offered
> amount that did not result in a sale, but it is the best data
> point that I have seen so far.
>
>> For one thing, who could possibly know
>> for sure if the figure you quoted that was offered recently
>> will be the going rate for a /20 after the IPv4 run-out?
>
> I think that we all realise that in a real market, prices go
> up and down with every transaction. So, given that someone is
> willing to offer 100,000 USD for a /20 today, when there are
> free alternatives at the RIR, what do you think the going rate
> will be after the free alternative is gone?
>
>> If we assume there will be a market in IPv4 after the
>> run-out, we should expect the usual laws of supply and demand
>> will mean there's some sort of price equilibrium in the
>> market.
>
> Equilibrium? When I learned basic economics, scarcity caused
> prices to rise. After IPv4 runout, every block sold just makes
> IPv4 addresses scarcer which means that there will be no equilibrium,
> just increases until nobody can afford to pay the price. I would
> expect that to be a stairstep increase because everyone knows that
> addresses are scarcer and scarcer as time goes on.
>
> Then the whole thing comes crashing down when IPv6 gathers enough
> momentum and people start releasing large amounts of IPv4 addresses.
>
>> Just like
>> any predictions for the prices of shares or exchange rates or
>> commodities N years in the future.
>
> You may not be able to predict exact prices, but you can do pretty good
> at predicting minimum and maximum prices relative to a hard currency,
> i.e. ounces of gold or barrels of crude, or Big Macs.
>
>> For instance more use of NAT and ALG
>> (if these turn out to be cheaper than buying a /20 or
>> whatever).
>
> How cheap do IPv4 addresses need to be to make it worthwhile for an
> equipment vendor to buy up addresses today to drive up the price and
> make it worthwhile for the market to buy carrier grade NAT boxes?
>
>> The point I'm making is that it doesn't seem sensible or even
>> possible to predict what these prices might be post run-out.
>
> We could prohibit 3rd part transfers and only allow returns to
> the RIR in which case we can confidently predict that the price
> will be zero. In any case, it is very sensible to do these types
> of scenario analysis as part of the policymaking process.
>
>> Or to invent policies which
>> somehow influence or control those prices. [That might well
>> have the look and feel of a cartel.]
>
> We have a cartel today and the price is zero. It's been like
> that for many years now and nobody is complaining or investigating
> the RIRs.
>
>> It would be an
>> interesting academic exercise for economists to model the
>> impact of various pricing scenarios though I'm not sure how
>> useful that would be in practice. That said, it would be nice
>> to have some sort of idea of the price points where the
>> trade-offs between buying
>> IPv4 or using more NAT/ALG or deploying IPv6 start to get fuzzy.
>
> I agree on that. Where are all the economics grad students?
>
> --Michael Dillon
>
> P.S. My position is that IPv6 is the answer and post runout, most
> larger ISPs should be able to satisfy growth of IPv4 in one area
> of their business by migrating lower margin services onto pure IPv6
> in order to free the IPv4 addresses for the sluggish corporates who
> are willing to pay a higher margin for service using legacy technology.
> Note that an economist might well consider this to be a market
> alternative
> because money is exchanged in return for IPv4 network services with
> IPv4 addresses bundled in.
>
> _______________________________________________
> 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 tvest at eyeconomics.com  Sat Jul 25 02:16:57 2009
From: tvest at eyeconomics.com (tvest at eyeconomics.com)
Date: Sat, 25 Jul 2009 08:16:57 +0200
Subject: [arin-ppml] Spectrum and IP address reservations / More from
	NERA
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233EFA@SUEX07-MBX-04.ad.syr.edu>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>,
	<997551.95719.qm@web63304.mail.re1.yahoo.com>
	<75822E125BCB994F8446858C4B19F0D77B233EFA@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <77A72092-BE1B-49C3-9896-0AB9555E409B@eyeconomics.com>


On Jul 21, 2009, at 6:38 PM, Milton L Mueller wrote:

>>  On the other hand, the advocates of nonmarket resource allocation  
>> policies are often making equally strict and bizarre assumptions  
>> about human behavior, but their theories are often too flaccid to  
>> specify what those assumptions are, and so they are unable to  
>> derive good models of their implications. For example, when people  
>> say you can fix market imperfections by "regulating" the market,  
>> are they not assuming that:

Be careful Milton -- you seem to be skirting dangerously close to  
making one of those "larger arguments" that Milton Friedman cautioned  
you against making when it's politically risky.[1]

Remember that the institution whose policy development process you're  
seeking to influence here is the product of cooperative, non-market  
decision making. Nearly 100% of its ongoing activities could be  
characterized as cooperative, non-market decision making. Although RFC  
2050 is probably best described as a "codifying" rather than  
"defining" document, its contents are generally considered to  
accurately reflect the rationale for the RIRs' establishment and  
administrative practices. Would you care you identify those elements  
in RFC 2050 that you regard as "bizzare" and/or "flaccid"? I think  
that would help other list members greatly in understanding the  
context of your remarks here, and your recent interest in IP address  
distribution more generally.

Thanks,

TV


[1] Brian Doherty, Radicals for Capitalism: A Freewheeling History of  
the Modern Libertarian Movement (Public Affairs, 2007), p. 611.
http://www.amazon.com/Radicals-Capitalism-Freewheeling-American-Libertarian/dp/1586485725/ref=sr_1_1?ie=UTF8&s=books&qid=1244380499&sr=1-1
(use the "search inside" feature to look for: "Milton Friedman, for  
example, once advised Students for a Libertarian Society leader Milton  
Mueller...")

Doherty draws this anecdote from a familiar source:
Milton Mueller, "The Movement," _Libertarian Review_ (April 1979, p.  
18).







From randy at psg.com  Sat Jul 25 02:59:40 2009
From: randy at psg.com (Randy Bush)
Date: Sat, 25 Jul 2009 08:59:40 +0200
Subject: [arin-ppml] Spectrum and IP address reservations / More
	from	NERA
In-Reply-To: <77A72092-BE1B-49C3-9896-0AB9555E409B@eyeconomics.com>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <m2hbx1qmcj.wl%randy@psg.com>

> Remember that the institution whose policy development process you're  
> seeking to influence here is the product of cooperative, non-market  
> decision making.

what are you smoking?  90% of he players here are up to our necks in the
market.

randy


From tvest at eyeconomics.com  Sat Jul 25 04:17:12 2009
From: tvest at eyeconomics.com (tvest at eyeconomics.com)
Date: Sat, 25 Jul 2009 10:17:12 +0200
Subject: [arin-ppml] Spectrum and IP address reservations / More
	from	NERA
In-Reply-To: <m2hbx1qmcj.wl%randy@psg.com>
References: <9A0282E3-8271-46E2-A74F-31CA492F7E79@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87D5@SUEX07-MBX-04.ad.syr.edu>
	<D8E0D161-3914-4642-A5DF-40A202F6D347@eyeconomics.com>
	<75822E125BCB994F8446858C4B19F0D77B1A87F2@SUEX07-MBX-04.ad.syr.edu>
	<m2hbx1qmcj.wl%randy@psg.com>
Message-ID: <E540DF3D-5B38-4013-8A5E-8C9E0472EE19@eyeconomics.com>


On Jul 25, 2009, at 8:59 AM, Randy Bush wrote:

>> Remember that the institution whose policy development process you're
>> seeking to influence here is the product of cooperative, non-market
>> decision making.
>
> what are you smoking?  90% of he players here are up to our necks in  
> the
> market.
>
> randy

Hi Randy,

No one denies that -- not me anyway. 90%+ of the players in the  
conventional economy are neck-deep in market opportunities/pressures/ 
demands too.
They also rely absolutely on the continued functioning of various (now  
mostly national) currencies -- either their own, or someone else's --  
to make those interactions possible, and meaningful, and (at least  
potentially) profitable. And generally speaking, on most days most of  
those currencies do "work" exactly as they're expected to -- even  
though all 200+ of them are currently managed through non-market  
mechanisms (many through direct gov fiat, some like the US Federal  
Reserve Bank System, though private "industry self-governance"  
mechanisms).

In this narrow*** sense, the relationship of the RIRs to the IP- 
mediated economy is very much like the relationship between the  
various (mostly national) monetary policy administration mechanisms  
and all of the other private players in the national/global economies,  
all of whom need need that stable liquidity mechanism to pursue their  
various private commercial interests. The fact that the one  
institution most closely associated with maintaining the liquidity  
mechanism for the conventional economy is not a private, profit- 
seeking enterprise doesn't imply anything about the rest of the  
conventional economy, either.

What I need is to smoke some of whatever it is that makes people think  
that  such coordinating mechanisms can just be abruptly privatized  
without severely injuring, if not killing, the economies that they  
support. In case you hadn't noticed, they ran that experiment in the  
conventional economy over the last decade or so, after most of the  
system management positions were captured by individuals who wanted to  
be placeholders, because they knew that the market could take care of  
itself...

TV

***Anyone still reading these threads will probably know that I think  
that there are many more / more important parallels than this, but  
none of those other claims is implicated by or necessary to this one  
specific comparison.




From bonomi at mail.r-bonomi.com  Sat Jul 25 13:27:28 2009
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sat, 25 Jul 2009 12:27:28 -0500 (CDT)
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
Message-ID: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>


> On Fri, Jul 24, 2009 at 4:55 PM, Chris Grundemann<cgrundemann at gmail.com> =
wrote:
>> Each RIR through their respective chosen policies and strategies shall
>> recover IPv4 address space which is under their administration and
>> designate such space for return to the IANA.
>
>
> Hi Chris,
>
> Here's another stab at wordsmithing:
>
> Each RIR shall recover IPv4 address space which is under their
> administration. Where authorized by their respective chosen policies
> and strategies, each RIR shall designate such space for return to the
> IANA.


This language is *FAR* better than anything previous.

There are a couple of minor tweaks still needed.
  1) "shall recover IPv4 address space", is an 'imperative' to do so, _without_
     _qualification_.   As written, it "doesn't matter" if people are still
     using those IPv4 addresses, the RIR _shall_ recover them.  One can 
     (reasonably) argue that that is in 'extremist' reading, but it -is- what
     the literal language says. <wry grin>  Best to write in a way that 'cannot'
     (insofar as possible) be mis-interpreted. :)

  2) 'designate such space for return' does NOT put any requirement on the
     RIR to _actually_return_ said space to the IANA.   They can 'designate'
     it so, and then sit on it, 'until time of need', then 're-purpose' it
     in accord with 'chosen policies and strategies'.


Suggested tweaks:

     Each RIR shall use their best efforts  {{alternative language: "make all
     reasonable effort"}}  to recover IPv4 address space which is under their
     administration. 

     Each RIR shall, in accordance with their established policies, return to
     the IANA all such reclaimed space that is in excesss of their near-term 
     needs.

Clear, unambiguous, and doesn't impose "beyond reason" requirements.  :)





From tony at lava.net  Sat Jul 25 13:36:41 2009
From: tony at lava.net (Antonio Querubin)
Date: Sat, 25 Jul 2009 07:36:41 -1000 (HST)
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
 of IPv4 Blocks to RIRs
In-Reply-To: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
Message-ID: <alpine.OSX.1.00.0907250734280.558@cust11794.lava.net>

On Sat, 25 Jul 2009, Robert Bonomi wrote:

> Suggested tweaks:
>
>     Each RIR shall use their best efforts  {{alternative language: "make all
>     reasonable effort"}}  to recover IPv4 address space which is under their
>     administration.
>
>     Each RIR shall, in accordance with their established policies, return to
>     the IANA all such reclaimed space that is in excesss of their near-term
>     needs.
>
> Clear, unambiguous, and doesn't impose "beyond reason" requirements.  :)

Not quite.  If we want to be more precise, how about adding the word 
'unused' or 'unneeded' before 'IPv4 address space'?

Tony


From bonomi at mail.r-bonomi.com  Sat Jul 25 16:36:41 2009
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sat, 25 Jul 2009 15:36:41 -0500 (CDT)
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
Message-ID: <200907252036.n6PKafMj028434@mail.r-bonomi.com>

> From tony at lava.net  Sat Jul 25 12:36:54 2009
> Date: Sat, 25 Jul 2009 07:36:41 -1000 (HST)
> From: Antonio Querubin <tony at lava.net>
> To: Robert Bonomi <bonomi at mail.r-bonomi.com>
> cc: ppml at arin.net
> Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
>  of IPv4 Blocks to RIRs
>
> On Sat, 25 Jul 2009, Robert Bonomi wrote:
>
> > Suggested tweaks:
> >
> >     Each RIR shall use their best efforts  {{alternative language: "make all
> >     reasonable effort"}}  to recover IPv4 address space which is under their
> >     administration.
> >
> >     Each RIR shall, in accordance with their established policies, return to
> >     the IANA all such reclaimed space that is in excesss of their near-term
> >     needs.
> >
> > Clear, unambiguous, and doesn't impose "beyond reason" requirements.  :)
>
> Not quite.  If we want to be more precise, how about adding the word 
> 'unused' or 'unneeded' before 'IPv4 address space'?

WHAT??? 

It's already policy, isn't it, to encourage people to use/move to IPv6?
That's just one way that RIRs can 'make the effort' to reclaim v4 addresses
that are in use.       <*B*I*G* grin>





From jcurran at arin.net  Sat Jul 25 21:35:57 2009
From: jcurran at arin.net (John Curran)
Date: Sat, 25 Jul 2009 21:35:57 -0400
Subject: [arin-ppml] The price of address space
In-Reply-To: <4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com>
References: <51AA4CA9-122E-4E58-A05D-D3AF5023885B@rfc1035.com>
	<28E139F46D45AF49A31950F88C497458024924BA@E03MVZ2-UKDY.domain1.systemhost.net>
	<4607e1d50907241823h2ade5641r6bde9149b8f2ba9d@mail.gmail.com>
Message-ID: <337F33A6-2A1B-4531-9F26-CE210480A7CA@arin.net>

On Jul 24, 2009, at 9:23 PM, Martin Hannigan wrote:
> ...
> There's already factual data and a derived host value that has been
> published and presented at various RIR meetings.

To the extent folks suspect Internet number resource fraud, please
report it here: <https://www.arin.net/resources/fraud/>

Thanks!
/John

John Curran
President and CEO
ARIN



From info at arin.net  Mon Jul 27 10:35:15 2009
From: info at arin.net (Member Services)
Date: Mon, 27 Jul 2009 10:35:15 -0400
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small ISPs
Message-ID: <4A6DBB23.5040605@arin.net>

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

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

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

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

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

1. Policy Proposal Name: Last Minute Assistance for Small ISPs

2. Proposal Originator: Ted Mittelstaedt

3. Proposal Version: 1

4. Date: 7/24/2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Under section 4.2.2. Initial allocation to ISPs

Section 4.2.2.1.1 (Use of /20) will be modified to be the following:

Sentence:

"Until ARIN has assigned 90% of it's remaining IP addressing,"

will be inserted at the beginning of the paragraph.

The following four paragraphs will be added:

When ARIN has reached 90% allocation of it's remaining IP free pool,
the minimum allocation of /20 requirement will be changed to a minimum
allocation of /21 in this section and all other sections that reference
the /20 minimum EXCEPT for transfers under section 8.3.

When ARIN has reached 95% allocation of it's remaining IP free pool,
the minimum allocation of /21 requirement will be changed to a minimum
allocation of /22 in this section and all other sections that reference
the /21 minimum EXCEPT for transfers under section 8.3.

When ARIN has reached 97% allocation of it's remaining IP free pool,
the minimum allocation of /22 requirement will be changed to a minimum
allocation of /23 in this section and all other sections that reference
the /22 minimum EXCEPT for transfers under section 8.3.

When ARIN has exhausted all of it's remaining IP free pool, for any
transfers under section 8.3, the minimum allocation size will remain at
  /20, in this section and all other sections that reference a minimum
allocation size.  It will remain at /23 for IPv4 that is voluntarily
returned to ARIN.

8. Rationale:

Once ARIN is no longer able to assign IPv4, there will be many smaller
ISP's who never qualified for an initial allocation under section
4.2.2.1.1. of the NRPM, who are using multiple /24 assignments from an
upstream provider, and who will see their costs for continuing to use
IPv4 numbering from their upstreams increasing as the "market price" set
by section 8.3 of the NRPM applies a price on IPv4 numbers.  For
example, it would be perfectly logical for a large network that observes
the price of a /20 transfer under section 8.3 at $10,000 to decide to
apply a yearly usage price of $600 to any /24's they have assigned to
their customers.

As the "transfer market" setup under section 8.3 continues to operate
post IPv4 runout, and costs of yearly IPv4 assignment fees from
LIR's diverge further and further from the yearly fees for allocations
from the RIR's, LIR's will have small ISP's using multiple /24
assignments at an extreme disadvantage.

Those small ISP's will be unable to get IPv4 from ARIN even if they
qualify at some time post-runout, they will be unable to afford to pay
large sums of money for transfers under section 8.3 (and likely wouldn't
meet minimum utilization requirements for the blocks that would be
transferred under section 8.3 even if they could), and if they go to
a competitive upstream, they will be essentially "going from the frying
pan to the fire".  It is likely that this could force many of them out
of business.

What this proposal attempts to do is give those small ISP's a chance
to obtain some small amount of portable numbering BEFORE IPv4 runout,
so that they can use this in conjunction with NAT or other technologies
post-IPv4 runout to manage until the userbase on the Internet switches
to IPv6.

ARIN's original rationale for setting the minimum allocation at /20 was
to prevent extreme fragmentation of the dfz and prevent it from growing
to impossibly large levels.  This goal has been pretty much met.  And
when 95% of the assignable IPv4 has been handed out by ARIN under the
"/20 minimum" rule, even if the rest of the IP was handed out as /24's,
it won't appreciably affect fragmentation in the dfz.  In addition, as
the years pass post-IPv4 runout, and organizations search around for
available IPv4 it's logical to assume that many more small allocations
that were assigned as "legacy" assignments, and are currently idle, will
be found and put into use - policy should discourage this and encourage
them to be returned to ARIN to be aggregated with other small
allocations.  Post IPv4 runout, the Internet should be transitioning to
IPv6, this policy should therefore be regarded primarily as a stopgap to
help small ISP's over the hump.

The small ISPs will still be required to show that they can make
efficient utilization of their requested block, still be required
to pay fees and meet all the other obligations any org must meet.
The only thing that changes is lowering the minimum limit.

9. Timetable for implementation; immediate





From bill at herrin.us  Mon Jul 27 12:03:56 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Jul 2009 12:03:56 -0400
Subject: [arin-ppml] Rationale for /22
Message-ID: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>

Question for y'all:

What is the rationale behind a /22 minimum size for multihomed
organizations? Why not a /24?

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

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

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

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

Excluding conspiracy theories (the big bad ISPs want lock in) I'd like
to hear ideas, answers and even recollections from folks who were
there when the size was set as to why we should prefer /22 as the
minimum multihomed size assignable by ARIN.

Regards,
Bill Herrin


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


From petelists at templin.org  Mon Jul 27 12:22:17 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 27 Jul 2009 11:22:17 -0500
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
 ISPs
In-Reply-To: <4A6DBB23.5040605@arin.net>
References: <4A6DBB23.5040605@arin.net>
Message-ID: <4A6DD439.5010304@templin.org>

Member Services wrote:

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

First, a request for typographical corrections:

> "Until ARIN has assigned 90% of it's remaining IP addressing,"

s/it's/its/

> When ARIN has reached 90% allocation of it's remaining IP free pool,

s/it's/its/

> When ARIN has reached 95% allocation of it's remaining IP free pool,

s/it's/its/

> When ARIN has reached 97% allocation of it's remaining IP free pool,

s/it's/its/

> When ARIN has exhausted all of it's remaining IP free pool, for any

s/it's/its/

> Once ARIN is no longer able to assign IPv4, there will be many smaller
> ISP's who never qualified for an initial allocation under section

s/ISP's/ISPs/

> LIR's diverge further and further from the yearly fees for allocations
> from the RIR's, LIR's will have small ISP's using multiple /24

s/LIR's/LIRs/; s/RIR's/RIRs/; s/ISP's/ISPs/

> Those small ISP's will be unable to get IPv4 from ARIN even if they

s/ISP's/ISPs/

> What this proposal attempts to do is give those small ISP's a chance

s/ISP's/ISPs/

> help small ISP's over the hump.

s/ISP's/ISPs/


Commentary to follow separately.

pt


From farmer at umn.edu  Mon Jul 27 13:01:37 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 27 Jul 2009 12:01:37 -0500
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <4A6DBB23.5040605@arin.net>
References: <4A6DBB23.5040605@arin.net>
Message-ID: <4A6D9721.10299.EA687FC@farmer.umn.edu>

On 27 Jul 2009 Member Services wrote:

> 1. Policy Proposal Name: Last Minute Assistance for Small ISPs
> 
> 2. Proposal Originator: Ted Mittelstaedt
> 
> 3. Proposal Version: 1
> 
> 4. Date: 7/24/2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> Under section 4.2.2. Initial allocation to ISPs
> 
> Section 4.2.2.1.1 (Use of /20) will be modified to be the
> following:
> 
> Sentence:
> 
> "Until ARIN has assigned 90% of it's remaining IP addressing,"


This probably needs an additional clause, something like, "Until ARIN has 
been allocated its last /8 per section 10.4.2.2, and ARIN has assigned 90% 
of it's remaining IP addressing."

I'm not sure the percentages are actually meaningful without setting the 
starting point.  I haven't run the numbers, but it is possible that ARIN has 
already allocated 90% of the IPv4 address space that it will allocate.  If this 
isn't the intent, then maybe you need to be much more specific where the 
measurement starts.  

Maybe a better way is to provide specific CIDR-based threshold triggers 
rather than percentages anyway.  Maybe say the last /11 instead of 90% 
(87.5% of a /8), /12 instead of 95% (93.75% of a /8), and /13 instead of 97% 
(96.875% of a /8). This way you probablly don't need to explicitly say start 
with the last /8.

> will be inserted at the beginning of the paragraph.
> 
> The following four paragraphs will be added:
> 
> When ARIN has reached 90% allocation of it's remaining IP free pool, the
> minimum allocation of /20 requirement will be changed to a minimum
> allocation of /21 in this section and all other sections that reference
> the /20 minimum EXCEPT for transfers under section 8.3. 
> 
> When ARIN has reached 95% allocation of it's remaining IP free pool, the
> minimum allocation of /21 requirement will be changed to a minimum
> allocation of /22 in this section and all other sections that reference
> the /21 minimum EXCEPT for transfers under section 8.3. 
> 
> When ARIN has reached 97% allocation of it's remaining IP free pool, the
> minimum allocation of /22 requirement will be changed to a minimum
> allocation of /23 in this section and all other sections that reference
> the /22 minimum EXCEPT for transfers under section 8.3. 
> 
> When ARIN has exhausted all of it's remaining IP free pool, for any
> transfers under section 8.3, the minimum allocation size will remain at
> /20, in this section and all other sections that reference a minimum
> allocation size.  It will remain at /23 for IPv4 that is voluntarily
> returned to ARIN. 
> 
> 8. Rationale:
> 
> Once ARIN is no longer able to assign IPv4, there will be many smaller
> ISP's who never qualified for an initial allocation under section
> 4.2.2.1.1. of the NRPM, who are using multiple /24 assignments from an
> upstream provider, and who will see their costs for continuing to use
> IPv4 numbering from their upstreams increasing as the "market price"
> set by section 8.3 of the NRPM applies a price on IPv4 numbers.  For
> example, it would be perfectly logical for a large network that
> observes the price of a /20 transfer under section 8.3 at $10,000 to
> decide to apply a yearly usage price of $600 to any /24's they have
> assigned to their customers. 
> 
> As the "transfer market" setup under section 8.3 continues to operate
> post IPv4 runout, and costs of yearly IPv4 assignment fees from LIR's
> diverge further and further from the yearly fees for allocations from
> the RIR's, LIR's will have small ISP's using multiple /24 assignments
> at an extreme disadvantage. 
> 
> Those small ISP's will be unable to get IPv4 from ARIN even if they
> qualify at some time post-runout, they will be unable to afford to pay
> large sums of money for transfers under section 8.3 (and likely
> wouldn't meet minimum utilization requirements for the blocks that
> would be transferred under section 8.3 even if they could), and if they
> go to a competitive upstream, they will be essentially "going from the
> frying pan to the fire".  It is likely that this could force many of
> them out of business. 
> 
> What this proposal attempts to do is give those small ISP's a chance to
> obtain some small amount of portable numbering BEFORE IPv4 runout, so
> that they can use this in conjunction with NAT or other technologies
> post-IPv4 runout to manage until the userbase on the Internet switches
> to IPv6. 
> 
> ARIN's original rationale for setting the minimum allocation at /20 was
> to prevent extreme fragmentation of the dfz and prevent it from growing
> to impossibly large levels.  This goal has been pretty much met. And
> when 95% of the assignable IPv4 has been handed out by ARIN under the
> "/20 minimum" rule, even if the rest of the IP was handed out as /24's,
> it won't appreciably affect fragmentation in the dfz.  In addition, as
> the years pass post-IPv4 runout, and organizations search around for
> available IPv4 it's logical to assume that many more small allocations
> that were assigned as "legacy" assignments, and are currently idle,
> will be found and put into use - policy should discourage this and
> encourage them to be returned to ARIN to be aggregated with other small
> allocations.  Post IPv4 runout, the Internet should be transitioning to
> IPv6, this policy should therefore be regarded primarily as a stopgap
> to help small ISP's over the hump. 
> 
> The small ISPs will still be required to show that they can make
> efficient utilization of their requested block, still be required
> to pay fees and meet all the other obligations any org must meet.
> The only thing that changes is lowering the minimum limit.
> 
> 9. Timetable for implementation; immediate

How would you envision this working with other policy proposals?  Such as 
93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run 
Out by Allocation Window.  Would you do this instead of one or both of those 
or would you do this and one or both of those too?



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



From tedm at ipinc.net  Mon Jul 27 13:49:19 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 10:49:19 -0700
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
 ISPs
In-Reply-To: <4A6DD439.5010304@templin.org>
References: <4A6DBB23.5040605@arin.net> <4A6DD439.5010304@templin.org>
Message-ID: <4A6DE89F.8000009@ipinc.net>

My it's got the sh its, eh? ;-)

Damn, I always make that mistake!

Thanks
Ted

Pete Templin wrote:
> Member Services wrote:
> 
>> In the meantime, the AC invites everyone to comment on the proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their deliberations.
> 
> First, a request for typographical corrections:
> 
>> "Until ARIN has assigned 90% of it's remaining IP addressing,"
> 
> s/it's/its/
> 
>> When ARIN has reached 90% allocation of it's remaining IP free pool,
> 
> s/it's/its/
> 
>> When ARIN has reached 95% allocation of it's remaining IP free pool,
> 
> s/it's/its/
> 
>> When ARIN has reached 97% allocation of it's remaining IP free pool,
> 
> s/it's/its/
> 
>> When ARIN has exhausted all of it's remaining IP free pool, for any
> 
> s/it's/its/
> 
>> Once ARIN is no longer able to assign IPv4, there will be many smaller
>> ISP's who never qualified for an initial allocation under section
> 
> s/ISP's/ISPs/
> 
>> LIR's diverge further and further from the yearly fees for allocations
>> from the RIR's, LIR's will have small ISP's using multiple /24
> 
> s/LIR's/LIRs/; s/RIR's/RIRs/; s/ISP's/ISPs/
> 
>> Those small ISP's will be unable to get IPv4 from ARIN even if they
> 
> s/ISP's/ISPs/
> 
>> What this proposal attempts to do is give those small ISP's a chance
> 
> s/ISP's/ISPs/
> 
>> help small ISP's over the hump.
> 
> s/ISP's/ISPs/
> 
> 
> Commentary to follow separately.
> 
> pt
> _______________________________________________
> 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 BillD at cait.wustl.edu  Mon Jul 27 14:18:53 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 27 Jul 2009 13:18:53 -0500
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <4A6DE89F.8000009@ipinc.net>
References: <4A6DBB23.5040605@arin.net> <4A6DD439.5010304@templin.org>
	<4A6DE89F.8000009@ipinc.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087934B3A@ex1.cait.wustl.edu>

Of course ARIN staff will be looking at your proposal from an edits and
understandability point of view.

Cathy Arnson and I will be shepherding this proposal on behalf of the AC
and the community at large.

My initial thoughts are operational and definitional....

"When ARIN has reached 90% allocation of it's remaining IP free
pool"....for instance.
free pool would have to be defined a bit more precisely and of course,
that 90% threshold may vary even during a request being processed with
returns, etc.

Could this proposal trigger the change in mimimum assignment during the
process of receiving the next IANA allocation? What happens then?

IF the last /8 that ARIN could get existed as a free pool, then as the
process described in this proposal takes shape, there would only be
4200+ /20s available, but given that any size of allocation/assignment
request may come in, it is entirely possible thresholds of 90%, 95% and
97% might get crossed rather quickly.....

Additionally, when a given threshold is met, it is increasingly likely
that a single large and justified request could wipe out the entire free
pool without other 'end times' policy as have been/are being proposed
and considered.

I'd be interested to hear other members of the community comment.

bd

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
> Sent: Monday, July 27, 2009 12:49 PM
> To: Pete Templin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Last Minute 
> Assistance for Small ISPs
> 
> My it's got the sh its, eh? ;-)
> 
> Damn, I always make that mistake!
> 
> Thanks
> Ted
> 
> Pete Templin wrote:
> > Member Services wrote:
> > 
> >> In the meantime, the AC invites everyone to comment on the 
> proposal 
> >> on the PPML, particularly their support or non-support and the 
> >> reasoning behind their opinion. Such participation 
> contributes to a 
> >> thorough vetting and provides important guidance to the AC 
> in their deliberations.
> > 
> > First, a request for typographical corrections:
> > 
> >> "Until ARIN has assigned 90% of it's remaining IP addressing,"
> > 
> > s/it's/its/
> > 
> >> When ARIN has reached 90% allocation of it's remaining IP 
> free pool,
> > 
> > s/it's/its/
> > 
> >> When ARIN has reached 95% allocation of it's remaining IP 
> free pool,
> > 
> > s/it's/its/
> > 
> >> When ARIN has reached 97% allocation of it's remaining IP 
> free pool,
> > 
> > s/it's/its/
> > 
> >> When ARIN has exhausted all of it's remaining IP free pool, for any
> > 
> > s/it's/its/
> > 
> >> Once ARIN is no longer able to assign IPv4, there will be many 
> >> smaller ISP's who never qualified for an initial allocation under 
> >> section
> > 
> > s/ISP's/ISPs/
> > 
> >> LIR's diverge further and further from the yearly fees for 
> >> allocations from the RIR's, LIR's will have small ISP's using 
> >> multiple /24
> > 
> > s/LIR's/LIRs/; s/RIR's/RIRs/; s/ISP's/ISPs/
> > 
> >> Those small ISP's will be unable to get IPv4 from ARIN even if they
> > 
> > s/ISP's/ISPs/
> > 
> >> What this proposal attempts to do is give those small 
> ISP's a chance
> > 
> > s/ISP's/ISPs/
> > 
> >> help small ISP's over the hump.
> > 
> > s/ISP's/ISPs/
> > 
> > 
> > Commentary to follow separately.
> > 
> > pt
> > _______________________________________________
> > 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 tedm at ipinc.net  Mon Jul 27 14:23:15 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 11:23:15 -0700
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
 ISPs
In-Reply-To: <4A6D9721.10299.EA687FC@farmer.umn.edu>
References: <4A6DBB23.5040605@arin.net> <4A6D9721.10299.EA687FC@farmer.umn.edu>
Message-ID: <4A6DF093.7040203@ipinc.net>

David Farmer wrote:
> On 27 Jul 2009 Member Services wrote:
> 
>> 1. Policy Proposal Name: Last Minute Assistance for Small ISPs
>>
>> 2. Proposal Originator: Ted Mittelstaedt
>>
>> 3. Proposal Version: 1
>>
>> 4. Date: 7/24/2009
>>
>> 5. Proposal type: new
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> Under section 4.2.2. Initial allocation to ISPs
>>
>> Section 4.2.2.1.1 (Use of /20) will be modified to be the
>> following:
>>
>> Sentence:
>>
>> "Until ARIN has assigned 90% of it's remaining IP addressing,"
> 
> 
> This probably needs an additional clause, something like, "Until ARIN has 
> been allocated its last /8 per section 10.4.2.2, and ARIN has assigned 90% 
> of it's remaining IP addressing."
> 

Your right, bad, bad, bad mistake on my part!

> I'm not sure the percentages are actually meaningful without setting the 
> starting point.  I haven't run the numbers, but it is possible that ARIN has 
> already allocated 90% of the IPv4 address space that it will allocate.  If this 
> isn't the intent, then maybe you need to be much more specific where the 
> measurement starts.  
> 

I was intending the last /8 of IANA-assigned.

> Maybe a better way is to provide specific CIDR-based threshold triggers 
> rather than percentages anyway.  Maybe say the last /11 instead of 90% 
> (87.5% of a /8), /12 instead of 95% (93.75% of a /8), and /13 instead of 97% 
> (96.875% of a /8). This way you probablly don't need to explicitly say start 
> with the last /8.
> 

Yes, this probably is a much better way to do it.  Question for you, 
what do you think of the curve?  Do you think the percentages, or
CIDR-equivalents of the last /8 are good?

>> will be inserted at the beginning of the paragraph.
>>
>> The following four paragraphs will be added:
>>
>> When ARIN has reached 90% allocation of it's remaining IP free pool, the
>> minimum allocation of /20 requirement will be changed to a minimum
>> allocation of /21 in this section and all other sections that reference
>> the /20 minimum EXCEPT for transfers under section 8.3. 
>>
>> When ARIN has reached 95% allocation of it's remaining IP free pool, the
>> minimum allocation of /21 requirement will be changed to a minimum
>> allocation of /22 in this section and all other sections that reference
>> the /21 minimum EXCEPT for transfers under section 8.3. 
>>
>> When ARIN has reached 97% allocation of it's remaining IP free pool, the
>> minimum allocation of /22 requirement will be changed to a minimum
>> allocation of /23 in this section and all other sections that reference
>> the /22 minimum EXCEPT for transfers under section 8.3. 
>>
>> When ARIN has exhausted all of it's remaining IP free pool, for any
>> transfers under section 8.3, the minimum allocation size will remain at
>> /20, in this section and all other sections that reference a minimum
>> allocation size.  It will remain at /23 for IPv4 that is voluntarily
>> returned to ARIN. 
>>
>> 8. Rationale:
>>
>> Once ARIN is no longer able to assign IPv4, there will be many smaller
>> ISP's who never qualified for an initial allocation under section
>> 4.2.2.1.1. of the NRPM, who are using multiple /24 assignments from an
>> upstream provider, and who will see their costs for continuing to use
>> IPv4 numbering from their upstreams increasing as the "market price"
>> set by section 8.3 of the NRPM applies a price on IPv4 numbers.  For
>> example, it would be perfectly logical for a large network that
>> observes the price of a /20 transfer under section 8.3 at $10,000 to
>> decide to apply a yearly usage price of $600 to any /24's they have
>> assigned to their customers. 
>>
>> As the "transfer market" setup under section 8.3 continues to operate
>> post IPv4 runout, and costs of yearly IPv4 assignment fees from LIR's
>> diverge further and further from the yearly fees for allocations from
>> the RIR's, LIR's will have small ISP's using multiple /24 assignments
>> at an extreme disadvantage. 
>>
>> Those small ISP's will be unable to get IPv4 from ARIN even if they
>> qualify at some time post-runout, they will be unable to afford to pay
>> large sums of money for transfers under section 8.3 (and likely
>> wouldn't meet minimum utilization requirements for the blocks that
>> would be transferred under section 8.3 even if they could), and if they
>> go to a competitive upstream, they will be essentially "going from the
>> frying pan to the fire".  It is likely that this could force many of
>> them out of business. 
>>
>> What this proposal attempts to do is give those small ISP's a chance to
>> obtain some small amount of portable numbering BEFORE IPv4 runout, so
>> that they can use this in conjunction with NAT or other technologies
>> post-IPv4 runout to manage until the userbase on the Internet switches
>> to IPv6. 
>>
>> ARIN's original rationale for setting the minimum allocation at /20 was
>> to prevent extreme fragmentation of the dfz and prevent it from growing
>> to impossibly large levels.  This goal has been pretty much met. And
>> when 95% of the assignable IPv4 has been handed out by ARIN under the
>> "/20 minimum" rule, even if the rest of the IP was handed out as /24's,
>> it won't appreciably affect fragmentation in the dfz.  In addition, as
>> the years pass post-IPv4 runout, and organizations search around for
>> available IPv4 it's logical to assume that many more small allocations
>> that were assigned as "legacy" assignments, and are currently idle,
>> will be found and put into use - policy should discourage this and
>> encourage them to be returned to ARIN to be aggregated with other small
>> allocations.  Post IPv4 runout, the Internet should be transitioning to
>> IPv6, this policy should therefore be regarded primarily as a stopgap
>> to help small ISP's over the hump. 
>>
>> The small ISPs will still be required to show that they can make
>> efficient utilization of their requested block, still be required
>> to pay fees and meet all the other obligations any org must meet.
>> The only thing that changes is lowering the minimum limit.
>>
>> 9. Timetable for implementation; immediate
> 
> How would you envision this working with other policy proposals?  Such as 
> 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run 
> Out by Allocation Window. 

I think both of those proposals will suffer the same fate as
2007-05-02, "IPv4 Soft Landing"

Unless my read of the ARIN participatory membership is incorrect,
people are generally opposed to trying to keep chewing the
gum once all the flavor is gone.

There's not a lot of point to making the IPv4 requesting
criteria so stringent that practically nobody can get an
allocation.  It reminds me of North Korea's 4 authorized "Christian"
churches that are attended by nobody, and do nothing, but allow
the regime to claim they are tolerant.

Sure, if you make criteria for IPv4 so tough that nobody can
meet it, you can claim that ARIN hasn't run out of IPv4 yet
for the next 3-4 decades.

 > Would you do this instead of one or both of those
> or would you do this and one or both of those too?
> 

I'm generally opposed to both of those proposals but my gut
feel is they will be shot down anyway so I don't really feel
"threatened" by them, nor do I really even bother to think
about them.  When I came up with
this proposal I wasn't viewing it as an "opposition" proposal
to those proposals.

I can see, though, how someone might consider this to be diametrically
opposed to those proposals.  I'm suggesting we make it easier to get 
IPv4 at the last minute - those proposals are making it harder.

But this depends on how you view IPv4 runout.  I view IPv4 runout
as a fundamental fact, no amount of wriggling on the hook is
going to get the worm off, it's gonna happen no matter how much
IPv4 we dig out of the archives.

Others who may view IPv4 runout as something that we actually have
control over, and can manipulate, would probably feel that a
proposal like mine undercuts the entire IPv4 addressing scheme.

If people who are actively opposing those proposals want to use
this proposal as a hill to rally behind, I don't care one way or
the other.  It wasn't intended as such, however.

Where I'm coming from is simple - we all know that there's small
fry out there, we all know that some of those small fry are gonna
get stomped hard by IPv4 runout, and since the small fry definitely
didn't cause IPv4 runout, I just felt it was kind of unfair to allow
that to happen without throwing them a lifeline.  After all it's
not like it would really be a lot of skin off our collective nose
to do this for them for a few years, and it would mean a great
deal of difference to many of them.

Ted


From schiller at uu.net  Mon Jul 27 14:45:07 2009
From: schiller at uu.net (Jason Schiller)
Date: Mon, 27 Jul 2009 14:45:07 -0400 (EDT)
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087934B3A@ex1.cait.wustl.edu>
Message-ID: <Pine.GSO.4.20.0907271431440.5024-100000@meno.corp.us.uu.net>

On Mon, 27 Jul 2009, Bill Darte wrote:

> My initial thoughts are operational and definitional....
> 
> "When ARIN has reached 90% allocation of it's remaining IP free
> pool"....for instance.
> free pool would have to be defined a bit more precisely and of course,
> that 90% threshold may vary even during a request being processed with
> returns, etc.
> 
> Could this proposal trigger the change in mimimum assignment during the
> process of receiving the next IANA allocation? What happens then?
> 
> IF the last /8 that ARIN could get existed as a free pool, then as the
> process described in this proposal takes shape, there would only be
> 4200+ /20s available, but given that any size of allocation/assignment
> request may come in, it is entirely possible thresholds of 90%, 95% and
> 97% might get crossed rather quickly.....
> 
> Additionally, when a given threshold is met, it is increasingly likely
> that a single large and justified request could wipe out the entire free
> pool without other 'end times' policy as have been/are being proposed
> and considered.
> 
> I'd be interested to hear other members of the community comment.
> 
I think there needs to be more clarity here. First off I assume
assignments also count towards the measurment of the free pool?  What
about reserved space?  

As you and David Farmer point out, there is some concern on what you
measure the percentage against.  According to the NRO 06/2009 numbers ARIN
has been allocated 21.33 /8s.  That meanse is 19.197 /8s are allocated or
assigned then would we be in the post 90% phase already?

Secondly are the words "free pool".  What exactly is the ARIN free
pool? Does this include the last /8 allocted under section 10.4 (it 
seems the intention of this policy was for these addresses to be
special use and not part of the normal allocation / assignment
phase)?  Does this include special use space, like the /24s reserved for
Critical Infrastructure in section 4.4?  Does this include the /10 that is
dedicated to IPv6 transition mechanisms in section 4.10?  Does this
include fragments that are smaller than the current minium allocation?

__Jason





From BillD at cait.wustl.edu  Mon Jul 27 14:48:18 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 27 Jul 2009 13:48:18 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>

Every effort to lower minimum allocations throughout the years has met
with resistance.  Each successful policy managed a 'bit at a time' to
ensure 'nothing bad happened'....

In recent years, there have been few calls for a further lengthening and
those that emerged gained little support.

Proposals are always welcome...

Bill Darte
ARIN AC 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Monday, July 27, 2009 11:04 AM
> To: ARIN PPML
> Subject: [arin-ppml] Rationale for /22
> 
> Question for y'all:
> 
> What is the rationale behind a /22 minimum size for 
> multihomed organizations? Why not a /24?
> 
> The reason behind /20 for single-homed orgs is fairly straightforward:
> an ARIN allocation adds a route to the BGP table which 
> wouldn't otherwise be needed. Routes are expensive and the 
> cost falls into overhead since it isn't recoverable directly 
> from the org announcing the route. And we're not really 
> certain how many routes we can handle before the network 
> falls over. So, we restrict the availability of 
> non-aggregable IP addresses to just very large organizations. 
> For smaller orgs, renumbering sucks but at least it only 
> costs the renumbering org, not everyone else.
> 
> The reason behind nothing smaller than a /24 is also straightforward:
> many if not most ISPs filter out BGP announcements smaller than /24.
> There is tremendous inertia behind /24 as the minimum 
> backbone-routable quantity going back to the pre-CIDR days of 
> class-C addresses. So, an ARIN allocation smaller than /24 
> would generally be wasted addresses, unusable on the Internet.
> 
> But why peg multihomed orgs at /22 instead of /24? 
> Multivendor multihomed orgs have to announce a route anyway, 
> regardless of whether the addresses are from an ISP or 
> directly from ARIN. Their routes are not aggregable, even if 
> assigned from ISP space. That's the way the technology works 
> and no new tech in the pipeline is likely to change it.
> 
> With load balanced server clusters and NAT you can pack a 
> heck of a lot of punch into a multihomed /24 if you want to. 
> And as a community it's to our benefit to want registrants to 
> pack the maximum punch into their address space: IPv4 
> addresses are becoming scarce. So why do we restrict ARIN 
> assignments to folks who can write papers which justify a /22?
> 
> Excluding conspiracy theories (the big bad ISPs want lock in) 
> I'd like to hear ideas, answers and even recollections from 
> folks who were there when the size was set as to why we 
> should prefer /22 as the minimum multihomed size assignable by ARIN.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> _______________________________________________
> 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 27 15:12:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 12:12:27 -0700
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
 ISPs
In-Reply-To: <Pine.GSO.4.20.0907271431440.5024-100000@meno.corp.us.uu.net>
References: <Pine.GSO.4.20.0907271431440.5024-100000@meno.corp.us.uu.net>
Message-ID: <4A6DFC1B.2080508@ipinc.net>

Jason Schiller wrote:
> On Mon, 27 Jul 2009, Bill Darte wrote:
> 
>> My initial thoughts are operational and definitional....
>>
>> "When ARIN has reached 90% allocation of it's remaining IP free
>> pool"....for instance.
>> free pool would have to be defined a bit more precisely and of course,
>> that 90% threshold may vary even during a request being processed with
>> returns, etc.
>>
>> Could this proposal trigger the change in mimimum assignment during the
>> process of receiving the next IANA allocation? What happens then?
>>
>> IF the last /8 that ARIN could get existed as a free pool, then as the
>> process described in this proposal takes shape, there would only be
>> 4200+ /20s available, but given that any size of allocation/assignment
>> request may come in, it is entirely possible thresholds of 90%, 95% and
>> 97% might get crossed rather quickly.....
>>
>> Additionally, when a given threshold is met, it is increasingly likely
>> that a single large and justified request could wipe out the entire free
>> pool without other 'end times' policy as have been/are being proposed
>> and considered.
>>
>> I'd be interested to hear other members of the community comment.
>>
> I think there needs to be more clarity here. First off I assume
> assignments also count towards the measurment of the free pool?  

Yes and no.  It frankly depends on how ARIN slices up the last /8

If ARIN takes the last /8 and cuts it in half, with a /9 reserved to
allocations and a /9 reserved to assignments, then this would mean
95% of the last /9, not the last /8

I don't think ARIN operates this way, but no matter.

"free pool" is simply whatever ARIN has decided will be handed out
as allocations under that section of the policy.  I don't know
that ARIN uses the terminology "free pool" internally at all, perhaps
they don't.

I would welcome AC input on this - but keep in mind that policies
should avoid interference with operational details as much as
possible.  I think ARIN staff is smart enough that they can discern
the meaning of a policy and work out the internal implementation of it.

> What
> about reserved space?  
> 
> As you and David Farmer point out, there is some concern on what you
> measure the percentage against.  According to the NRO 06/2009 numbers ARIN
> has been allocated 21.33 /8s.  That meanse is 19.197 /8s are allocated or
> assigned then would we be in the post 90% phase already?
> 
> Secondly are the words "free pool".  What exactly is the ARIN free
> pool? Does this include the last /8 allocted under section 10.4 (it 
> seems the intention of this policy was for these addresses to be
> special use and not part of the normal allocation / assignment
> phase)?  Does this include special use space, like the /24s reserved for
> Critical Infrastructure in section 4.4?  Does this include the /10 that is
> dedicated to IPv6 transition mechanisms in section 4.10?  Does this
> include fragments that are smaller than the current minium allocation?
> 

"Free pool" simply means "the pool of numbers that ARIN uses to make
allocations to ISP's.

If ARIN wants to take the last /8 and make it all reserved, then the
"free pool" would be the next-to-the-last-/8.  Same as it is right
now I suppose.

Ted

> __Jason
> 
> 
> 



From farmer at umn.edu  Mon Jul 27 15:11:44 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 27 Jul 2009 14:11:44 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
Message-ID: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>

I've been meaning to ask this for several weeks now, where 
has the summer gone?

Leo and I are the AC Shepards for the two IPv4 Run Out 
Proposals, they are;

93. Predicable IPv4 Run Out by Prefix Size 
http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html

94. Predictable IPv4 Run Out by Allocation Window
http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html

Leo, I, and I believe much of the AC, think that these proposals 
shouldn't move forward separately, but that one or the other, or 
a merged version of the two, should move forward to Draft 
Policy to be discussed at ARIN XXIV in Dearborn.

Therefore, Leo and I would like feed back on these two 
proposals, and your ideas on the following options;

1. Should they be merged together and move forward as a 
single Draft Policy?

2. Should "Predicable IPv4 Run Out by Prefix Size" move 
forward to Draft Policy alone?

3. Should "Predictable IPv4 Run Out by Allocation Window" 
move forward to Draft Policy alone?

4. Should they move forward as two separate Draft Policies?

5. Should they both be abandoned? 

In order to make it on to the agenda for Dearborn, Draft Policy 
text must be ready for Staff and Legal Review by the end of 
this week.  

So please get any suggestions you have in as soon as 
possible, I'm going to start on a merged version of the text in 
case the consensus is to go that way, I will share it on PPML in 
the next day or two.

Thank you for your feed back.


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



From plzakr at gmail.com  Mon Jul 27 15:02:10 2009
From: plzakr at gmail.com (Ray Plzak)
Date: Mon, 27 Jul 2009 15:02:10 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the
	Allocation	of IPv4 Blocks to RIRs
In-Reply-To: <443de7ad0907241453u318332f2t59059dc7e3987adb@mail.gmail.com>
References: <4A69FF14.2010007@gmail.com>	<3c3e3fca0907241245k7f9268b1v2ae3a5cfabef2a69@mail.gmail.com>	<4A6A1396.6060901@gmail.com>	<3c3e3fca0907241340m39f2bc3t599834252a57752d@mail.gmail.com>	<443de7ad0907241355k576240b7j6674a1bc121ac1c9@mail.gmail.com>	<3c3e3fca0907241432k76a35446y3c4fde847aaba052@mail.gmail.com>
	<443de7ad0907241453u318332f2t59059dc7e3987adb@mail.gmail.com>
Message-ID: <007001ca0eec$c1039a70$430acf50$@com>

These words "Each RIR shall recover IPv4 address space which is under their
administration." in effect create a policy that requires each RIR  to
recover IPv4 address space. Is this what is wanted?

Ray

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Chris Grundemann
Sent: Friday, July 24, 2009 17:53
To: William Herrin
Cc: PPML
Subject: Re: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
of IPv4 Blocks to RIRs

On Fri, Jul 24, 2009 at 15:32, William Herrin<bill at herrin.us> wrote:
> On Fri, Jul 24, 2009 at 4:55 PM, Chris Grundemann<cgrundemann at gmail.com>
wrote:
>> Each RIR through their respective chosen policies and strategies shall
>> recover IPv4 address space which is under their administration and
>> designate such space for return to the IANA.
>
>
> Hi Chris,
>
> Here's another stab at wordsmithing:
>
> Each RIR shall recover IPv4 address space which is under their
> administration. Where authorized by their respective chosen policies
> and strategies, each RIR shall designate such space for return to the
> IANA.

I like this best so far.

> The prior version too weakly makes the point that this policy only
> describes -how- space will be returned to IANA. Some other local
> policy is required to authorize any space's return in the first place.
>
> One could reasonably interpret the prior language to mean that all
> recovered space will be returned. Why talk about returning space at
> all if you don't intend for space to be returned? You might not read
> it that way, but such a reading is not unreasonable. Which means that
> some folks will read it that way. Which means that either ARIN will
> end up following that interpretation or the folks who read it that way
> will be very upset with us for failing to.

I can see that, and must agree - my vote is for revising the policy,
again, with your verbiage above -- I could probably even support it at
that point...
~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
>


-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
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 tedm at ipinc.net  Mon Jul 27 15:30:18 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 12:30:18 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
Message-ID: <4A6E004A.30308@ipinc.net>

How I always understood it is that the idea was that it's pretty
easy to get /24's from just about any commercial ISP, and even /23's 
from most commercial ISPs, - at least, definitely from anyone large
enough to make it worth a large org's time to buy service from.

Thus, if the commercial ISP who assigned the /24 or /23 to a
multihomed org regards it as "golden handcuffs" and starts screwing the 
org for inordinate amounts of money, it would not be a huge amount of 
difficulty for the org to explain to the screwing ISP that there's 
plenty other ISP's out there they can get service from.  Renumbering
a /24 or /23 isn't that difficult.

Once you start getting bigger than a /23 then renumbering becomes
much more difficult thus those golden handcuffs actually start
to have some teeth.

Use of NAT really is tangential to this.  Your either renumbering
your NAT devices or your individually assigned hosts.

The end of IPv4 assignments from the RIR's probably means, if
your a multihomed org with a /23 or /24, your probably going to
be locked into your current providers, so you better get cracking
on IPv6.  Thus you might consider going to at least one upstream
who actually supports IPv6 natively, now, particularly if they can
give you a /23 or /24 since it's for damn sure that if whoever
has assigned you a /23 or /24 doesn't have IPv6 now, they sure
as heck will want to drag their feet on offering it in the future
when you can't go anywhere else for IPv4 numbers.

Ted


William Herrin wrote:
> Question for y'all:
> 
> What is the rationale behind a /22 minimum size for multihomed
> organizations? Why not a /24?
> 
> The reason behind /20 for single-homed orgs is fairly straightforward:
> an ARIN allocation adds a route to the BGP table which wouldn't
> otherwise be needed. Routes are expensive and the cost falls into
> overhead since it isn't recoverable directly from the org announcing
> the route. And we're not really certain how many routes we can handle
> before the network falls over. So, we restrict the availability of
> non-aggregable IP addresses to just very large organizations. For
> smaller orgs, renumbering sucks but at least it only costs the
> renumbering org, not everyone else.
> 
> The reason behind nothing smaller than a /24 is also straightforward:
> many if not most ISPs filter out BGP announcements smaller than /24.
> There is tremendous inertia behind /24 as the minimum
> backbone-routable quantity going back to the pre-CIDR days of class-C
> addresses. So, an ARIN allocation smaller than /24 would generally be
> wasted addresses, unusable on the Internet.
> 
> But why peg multihomed orgs at /22 instead of /24? Multivendor
> multihomed orgs have to announce a route anyway, regardless of whether
> the addresses are from an ISP or directly from ARIN. Their routes are
> not aggregable, even if assigned from ISP space. That's the way the
> technology works and no new tech in the pipeline is likely to change
> it.
> 
> With load balanced server clusters and NAT you can pack a heck of a
> lot of punch into a multihomed /24 if you want to. And as a community
> it's to our benefit to want registrants to pack the maximum punch into
> their address space: IPv4 addresses are becoming scarce. So why do we
> restrict ARIN assignments to folks who can write papers which justify
> a /22?
> 
> Excluding conspiracy theories (the big bad ISPs want lock in) I'd like
> to hear ideas, answers and even recollections from folks who were
> there when the size was set as to why we should prefer /22 as the
> minimum multihomed size assignable by ARIN.
> 
> Regards,
> Bill Herrin
> 
> 



From tedm at ipinc.net  Mon Jul 27 15:31:50 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 12:31:50 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>
Message-ID: <4A6E00A6.90109@ipinc.net>

David Farmer wrote:
> I've been meaning to ask this for several weeks now, where 
> has the summer gone?
> 
> Leo and I are the AC Shepards for the two IPv4 Run Out 
> Proposals, they are;
> 
> 93. Predicable IPv4 Run Out by Prefix Size 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html
> 
> 94. Predictable IPv4 Run Out by Allocation Window
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html
> 
> Leo, I, and I believe much of the AC, think that these proposals 
> shouldn't move forward separately, but that one or the other, or 
> a merged version of the two, should move forward to Draft 
> Policy to be discussed at ARIN XXIV in Dearborn.
> 
> Therefore, Leo and I would like feed back on these two 
> proposals, and your ideas on the following options;
> 
> 1. Should they be merged together and move forward as a 
> single Draft Policy?
> 

yes.

Ted

> 2. Should "Predicable IPv4 Run Out by Prefix Size" move 
> forward to Draft Policy alone?
> 
> 3. Should "Predictable IPv4 Run Out by Allocation Window" 
> move forward to Draft Policy alone?
> 
> 4. Should they move forward as two separate Draft Policies?
> 
> 5. Should they both be abandoned? 
> 
> In order to make it on to the agenda for Dearborn, Draft Policy 
> text must be ready for Staff and Legal Review by the end of 
> this week.  
> 
> So please get any suggestions you have in as soon as 
> possible, I'm going to start on a merged version of the text in 
> case the consensus is to go that way, I will share it on PPML in 
> the next day or two.
> 
> Thank you for your feed back.
> 
> 
> ===============================================
> David Farmer                                      Email:farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota		       Phone: 612-626-0815
> 2218 University Ave SE		       Cell: 612-812-9952
> Minneapolis, MN 55414-3029	       FAX: 612-626-1818
> ===============================================
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Mon Jul 27 16:51:28 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Jul 2009 16:51:28 -0400
Subject: [arin-ppml] Update on 2009-3: Global Policy for the Allocation
	of IPv4 Blocks to RIRs
In-Reply-To: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
References: <200907251727.n6PHRS0b026343@mail.r-bonomi.com>
Message-ID: <3c3e3fca0907271351k2f4a805cn3135d37d49ff92a4@mail.gmail.com>

On Sat, Jul 25, 2009 at 1:27 PM, Robert Bonomi<bonomi at mail.r-bonomi.com> wrote:
>>> Each RIR through their respective chosen policies and strategies shall
>>> recover IPv4 address space which is under their administration and
>>> designate such space for return to the IANA.
>>
>> Each RIR shall recover IPv4 address space which is under their
>> administration. Where authorized by their respective chosen policies
>> and strategies, each RIR shall designate such space for return to the
>> IANA.
>
> This language is *FAR* better than anything previous.
>
> There are a couple of minor tweaks still needed.
> ?1) "shall recover IPv4 address space", is an 'imperative' to do so, _without_
> ? ? _qualification_.

Hi Robert,

Let's tweak it a little bit more then:

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


How's that? It's still mostly the same words as the original,
hopefully close enough to be considered the same as the other regions'
versions for IANA's purposes, but it clarifies that some additional
policy is needed to recover addresses or determine which if any will
be so designated.

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 cgrundemann at gmail.com  Mon Jul 27 17:34:14 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 27 Jul 2009 15:34:14 -0600
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6E00A6.90109@ipinc.net>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu> <4A6E00A6.90109@ipinc.net>
Message-ID: <443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>

On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>
> David Farmer wrote:
>>
>> I've been meaning to ask this for several weeks now, where has the summer gone?
>>
>> Leo and I are the AC Shepards for the two IPv4 Run Out Proposals, they are;
>>
>> 93. Predicable IPv4 Run Out by Prefix Size http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html
>>
>> 94. Predictable IPv4 Run Out by Allocation Window
>> http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html
>>
>> Leo, I, and I believe much of the AC, think that these proposals shouldn't move forward separately, but that one or the other, or a merged version of the two, should move forward to Draft Policy to be discussed at ARIN XXIV in Dearborn.
>>
>> Therefore, Leo and I would like feed back on these two proposals, and your ideas on the following options;
>>
>> 1. Should they be merged together and move forward as a single Draft Policy?
>>
>
> yes.

+1

My recommendation is that proposal 94 is merged into proposal 93,
leaving the fairly arbitrary date based method of reduction behind in
favor of a remaining resources based implementation (and limit it to
IPv4 explicitly); such as "when ARIN receives its last /8, an
organization may choose to request up to a 6 month supply of IPv4
resources" or some more finely graduated but similarly triggered
reduction.

$0.02,
~Chris

>
> Ted
>
>> 2. Should "Predicable IPv4 Run Out by Prefix Size" move forward to Draft Policy alone?
>>
>> 3. Should "Predictable IPv4 Run Out by Allocation Window" move forward to Draft Policy alone?
>>
>> 4. Should they move forward as two separate Draft Policies?
>>
>> 5. Should they both be abandoned?
>> In order to make it on to the agenda for Dearborn, Draft Policy text must be ready for Staff and Legal Review by the end of this week.
>> So please get any suggestions you have in as soon as possible, I'm going to start on a merged version of the text in case the consensus is to go that way, I will share it on PPML in the next day or two.
>>
>> Thank you for your feed back.
>>
>>
>> ===============================================
>> David Farmer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Email:farmer at umn.edu
>> Office of Information Technology
>> Networking & Telecomunication Services
>> University of Minnesota ? ? ? ? ? ? ? ?Phone: 612-626-0815
>> 2218 University Ave SE ? ? ? ? ? ? ? ? Cell: 612-812-9952
>> Minneapolis, MN 55414-3029 ? ? ? ? ? ? FAX: 612-626-1818
>> ===============================================
>>
>> _______________________________________________
>> 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.



--
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From bill at herrin.us  Mon Jul 27 18:06:15 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Jul 2009 18:06:15 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
Message-ID: <3c3e3fca0907271506l2b0702aha27e1587ce56787b@mail.gmail.com>

On Mon, Jul 27, 2009 at 2:48 PM, Bill Darte<BillD at cait.wustl.edu> wrote:
> In recent years, there have been few calls for a further lengthening and
> those that emerged gained little support.

March and April of 2007 for proposal 2007-6.
http://lists.arin.net/pipermail/arin-ppml/

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

* Could make it easier for spammers. This seems to reflect some
general concern at the time over whether ARIN's policies made things
easy for spammers to hop IP addresses and was probably a red herring.
Spammers and other criminals aren't known to be eager to register with
anybody. They want address space as anonymously as possible for as
long as possible as cheaply as possible exerting as little effort as
possible. And they'd really like to hijack your computer and Internet
link too so they don't have to spend as much of their own money. All
of these things make direct ARIN address space generally unattractive
to spammers.

* Could create a land rush. Doesn't seem likely since a registrant
could get the same addresses from his ISP causing the ISP to roll it
up into their next request. Still, it could probably be mitigated with
a continuous use on the Internet clause for the sub-/22 assignments.

* Could create a new swamp which burns up routing slots. Seems like we
could find a way to mitigate this risk.

* Unfair to ISPs since it only applied to end users.

* Staff worried that it could increase request workload. Fees are
supposed to be adjusted to meet workload, right?


Would you say that's a fair summary of the criticisms of 2007-6?


> Proposals are always welcome...

I'm thinking about writing one, but I'd like to get picture of the
legitimate reasons why -not- to extend the allocation size to /24 so
that the proposal can address them.

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 sethm at rollernet.us  Mon Jul 27 18:43:43 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 27 Jul 2009 15:43:43 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907271506l2b0702aha27e1587ce56787b@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<3c3e3fca0907271506l2b0702aha27e1587ce56787b@mail.gmail.com>
Message-ID: <4A6E2D9F.8060401@rollernet.us>

William Herrin wrote:
> 
> I'm thinking about writing one, but I'd like to get picture of the
> legitimate reasons why -not- to extend the allocation size to /24 so
> that the proposal can address them.
> 


ISPs give away /24's like candy; they aren't hard to get especially if
you're multihoming with it. When I started and I couldn't a /22 from
ARIN (due to being honest) I got a /24 from each upstream no questions
asked. I don't feel there have been any valid arguments presented beyond
the "golden handcuffs" situation. PI space gives you freedom from
upstream lock-in at the /24 level; that's about it.

Perhaps if there is another proposal and we really do go down to /24, we
limit someone to a single /24 and their next step up is a /22 and they
have to return the /24?

~Seth


From tedm at ipinc.net  Mon Jul 27 19:26:47 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Jul 2009 16:26:47 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6E2D9F.8060401@rollernet.us>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<3c3e3fca0907271506l2b0702aha27e1587ce56787b@mail.gmail.com>
	<4A6E2D9F.8060401@rollernet.us>
Message-ID: <4A6E37B7.9040208@ipinc.net>

Seth Mattinen wrote:
> William Herrin wrote:
>> I'm thinking about writing one, but I'd like to get picture of the
>> legitimate reasons why -not- to extend the allocation size to /24 so
>> that the proposal can address them.
>>
> 
> 
> ISPs give away /24's like candy; they aren't hard to get especially if
> you're multihoming with it. When I started and I couldn't a /22 from
> ARIN (due to being honest) I got a /24 from each upstream no questions
> asked. I don't feel there have been any valid arguments presented beyond
> the "golden handcuffs" situation. PI space gives you freedom from
> upstream lock-in at the /24 level; that's about it.
> 
> Perhaps if there is another proposal and we really do go down to /24, we
> limit someone to a single /24 and their next step up is a /22 and they
> have to return the /24?
> 

I feel this is really a moot issue because after IPv4 runout, the
RIR's won't HAVE /24's to hand out, even if they wanted to, much
less having /22s.

I also feel it's a slippery slope to permit /24's because if you
do your going to permanently establish them - because by the time
the orgs that get them want to "trade up" to a /22 they won't
be able to since the RIR's won't have any more IP.

Ted


From farmer at umn.edu  Mon Jul 27 19:37:04 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 27 Jul 2009 18:37:04 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>, <4A6E00A6.90109@ipinc.net>,
	<443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>
Message-ID: <4A6DF3D0.506.101099CE@farmer.umn.edu>

On 27 Jul 2009 Chris Grundemann wrote:

> On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> >
> > David Farmer wrote:
> >> 1. Should they be merged together and move forward as a single Draft Policy?
> >>
> >
> > yes.
> 
> +1
> 
> My recommendation is that proposal 94 is merged into proposal 93,
> leaving the fairly arbitrary date based method of reduction behind in
> favor of a remaining resources based implementation (and limit it to
> IPv4 explicitly); such as "when ARIN receives its last /8, an
> organization may choose to request up to a 6 month supply of IPv4
> resources" or some more finely graduated but similarly triggered
> reduction.
> 
> $0.02,
> ~Chris
 
I think I see what you are getting at;  

How about something like this;

IANA pool down to X /8s, triggers 9 month allocation window
IANA pool down to Y /8s, triggers 6 month allocation window
IANA pool down to Z /8s, triggers 3 month allocation window
ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN 
free pool per allocation. 

Maybe with X=25, Y=15,  Z=10, but I need think about the numbers more.

The one advantage of setting arbitrary dates for the allocation window 
changes are everyone knows when they will happen.  

With something like this you won't have arbitrary dates anymore, but you 
won't know exactly when the changes will hit either, and the threshold of 
number of /8s left are probably somewhat arbitrary instead of the dates.

So which would people prefer?

1. Well known dates, or;
2. Triggers based on the actual resources left

I really need feed back on how people want to see this, and if you support 
this kind of proposal or not.

There was a bunch of discussion on the ARIN-Discuss list last week about 
recovering legacy space, it is much easier to set policy on how we are going 
to divvy up what is left of the IPv4 space than it is to get anyone to give any 
back.  So maybe we can put as much energy into creating policy about the 
IPv4 space that is left than was put into the discussion about trying to 
recover space last week.  Personally I'm much more optimistic that we can 
do something about Run-Out policies than I'm about the chances to get 
people to give back space.

Thanks

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



From gtb at slac.stanford.edu  Mon Jul 27 19:58:12 2009
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Mon, 27 Jul 2009 16:58:12 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6DF3D0.506.101099CE@farmer.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>, <4A6E00A6.90109@ipinc.net>,
	<443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>
	<4A6DF3D0.506.101099CE@farmer.umn.edu>
Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FD37E@exch-mail2.win.slac.stanford.edu>

> So which would people prefer?
> 
> 1. Well known dates, or;
> 2. Triggers based on the actual resources left

Triggers on resources left.  I understand the
date argument, but it "feels" better to have
resource allocation policies directly connected
to the lack of resources(*).

Gary 

(*) And a date based choice might simply result
    in another policy proposal to change the
    dates should a new estimate of the date of
    run-out be made.


From joelja at bogus.com  Tue Jul 28 04:43:41 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jul 2009 10:43:41 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
Message-ID: <4A6EBA3D.8020800@bogus.com>



Bill Darte wrote:
> Every effort to lower minimum allocations throughout the years has met
> with resistance.  Each successful policy managed a 'bit at a time' to
> ensure 'nothing bad happened'....

Realistically is it in the interest of a prospective multihomer to a
recieve a prefix that's likely longer than the one they already use?

How quickly does one chew up /32s /30 /28s in the process of multihoming
the internet facing infrastructure in a smple-multihomed network?

> In recent years, there have been few calls for a further lengthening and
> those that emerged gained little support.
> 
> Proposals are always welcome...
> 
> Bill Darte
> ARIN AC 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
>> Sent: Monday, July 27, 2009 11:04 AM
>> To: ARIN PPML
>> Subject: [arin-ppml] Rationale for /22
>>
>> Question for y'all:
>>
>> What is the rationale behind a /22 minimum size for 
>> multihomed organizations? Why not a /24?
>>
>> The reason behind /20 for single-homed orgs is fairly straightforward:
>> an ARIN allocation adds a route to the BGP table which 
>> wouldn't otherwise be needed. Routes are expensive and the 
>> cost falls into overhead since it isn't recoverable directly 
>> from the org announcing the route. And we're not really 
>> certain how many routes we can handle before the network 
>> falls over. So, we restrict the availability of 
>> non-aggregable IP addresses to just very large organizations. 
>> For smaller orgs, renumbering sucks but at least it only 
>> costs the renumbering org, not everyone else.
>>
>> The reason behind nothing smaller than a /24 is also straightforward:
>> many if not most ISPs filter out BGP announcements smaller than /24.
>> There is tremendous inertia behind /24 as the minimum 
>> backbone-routable quantity going back to the pre-CIDR days of 
>> class-C addresses. So, an ARIN allocation smaller than /24 
>> would generally be wasted addresses, unusable on the Internet.
>>
>> But why peg multihomed orgs at /22 instead of /24? 
>> Multivendor multihomed orgs have to announce a route anyway, 
>> regardless of whether the addresses are from an ISP or 
>> directly from ARIN. Their routes are not aggregable, even if 
>> assigned from ISP space. That's the way the technology works 
>> and no new tech in the pipeline is likely to change it.
>>
>> With load balanced server clusters and NAT you can pack a 
>> heck of a lot of punch into a multihomed /24 if you want to. 
>> And as a community it's to our benefit to want registrants to 
>> pack the maximum punch into their address space: IPv4 
>> addresses are becoming scarce. So why do we restrict ARIN 
>> assignments to folks who can write papers which justify a /22?
>>
>> Excluding conspiracy theories (the big bad ISPs want lock in) 
>> I'd like to hear ideas, answers and even recollections from 
>> folks who were there when the size was set as to why we 
>> should prefer /22 as the minimum multihomed size assignable by ARIN.
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>> 3005 Crane Dr. ...................... Web: 
>> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
>> _______________________________________________
>> 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 michael.dillon at bt.com  Tue Jul 28 05:27:54 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Jul 2009 10:27:54 +0100
Subject: [arin-ppml] Grammar assitance (was: Policy Proposal: Last Minute
	Assistance for Small ISPs)
In-Reply-To: <4A6DE89F.8000009@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C497458025C4BA2@E03MVZ2-UKDY.domain1.systemhost.net>


> My it's got the sh its, eh? ;-)

Just remember who it belongs to, his, hers and its.

And I'm, he's, she's and it's gonna be all right.



From michael.dillon at bt.com  Tue Jul 28 05:34:47 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Jul 2009 10:34:47 +0100
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <4A6DF093.7040203@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C497458025C4BC1@E03MVZ2-UKDY.domain1.systemhost.net>


> Where I'm coming from is simple - we all know that there's 
> small fry out there, we all know that some of those small fry 
> are gonna get stomped hard by IPv4 runout, and since the 
> small fry definitely didn't cause IPv4 runout, I just felt it 
> was kind of unfair to allow that to happen without throwing 
> them a lifeline.  

Small fry have less work to do to deploy IPv6.

Also, small fry who want to deploy carrier grade NAT don't need 
to wait for IETF work and vendor implementations because they are
small enough to do the job with existing NAT software. 

You can realistically run a small ISP using only free software 
for routing and everything else by using Linux, FreeBSD, OpenBSD
and/or OpenSolaris.

Small size carries some advantages as well as disadvantages. It is
a mistake to assume that IPv4 runout will crush small ISPs just because
they are small. IPv4 runout will only crush poorly run businesses
with lazy managers who lack foresight, regardless of whether those
businesses are big or small.

--Michael Dillon



From michael.dillon at bt.com  Tue Jul 28 05:39:19 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Jul 2009 10:39:19 +0100
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458025C4BE0@E03MVZ2-UKDY.domain1.systemhost.net>

> 93. Predicable IPv4 Run Out by Prefix Size 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html
> 
> 94. Predictable IPv4 Run Out by Allocation Window 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html

> 1. Should they be merged together and move forward as a 
> single Draft Policy?

Yes. Hash out the merged wording on this list and go with whatever
seems to be better supported.

> 5. Should they both be abandoned? 

No, because that would only cause a bunch of new similar proposals.

> In order to make it on to the agenda for Dearborn, Draft 
> Policy text must be ready for Staff and Legal Review by the 
> end of this week.  

It wouldn't hurt to miss that deadline, but do some work at 
Dearborn on a merger of the two ideas.

--Michael Dillon


From bill at herrin.us  Tue Jul 28 10:01:48 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jul 2009 10:01:48 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6EBA3D.8020800@bogus.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
Message-ID: <3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>

On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> Bill Darte wrote:
>> Every effort to lower minimum allocations throughout the years has met
>> with resistance. ?Each successful policy managed a 'bit at a time' to
>> ensure 'nothing bad happened'....
>
> Realistically is it in the interest of a prospective multihomer to a
> recieve a prefix that's likely longer than the one they already use?

Joel,

I don't follow your logic here. Why would a multihomer request less IP
addresses than he already uses, regardless of the minimum prefix size?


> How quickly does one chew up /32s /30 /28s in the process of multihoming
> the internet facing infrastructure in a smple-multihomed network?

When I was at the DNC, I structured the network to justify a /22. I
really wanted a /23 but a /22 was what I could get.

I'm faced with a similar situation today. I need a /24 but I'll
structure the network so that it justifies a /22. Just to be clear, I
won't tell a single lie. I'll simply structure the network so that
everything which could consume a public IP address does.

I doubt my experience is unique. I expect that many if not most of the
/22 end-user requests are similarly padded, not because the registrant
actually wants that many addresses but because that's what they can
get.

Given the shortage of IPv4 addresses, why structure the policies so
that we give anyone more than they actually want?

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 joelja at bogus.com  Tue Jul 28 10:32:56 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jul 2009 16:32:56 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
Message-ID: <4A6F0C18.1000107@bogus.com>



William Herrin wrote:
> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>> Bill Darte wrote:
>>> Every effort to lower minimum allocations throughout the years has met
>>> with resistance.  Each successful policy managed a 'bit at a time' to
>>> ensure 'nothing bad happened'....
>> Realistically is it in the interest of a prospective multihomer to a
>> recieve a prefix that's likely longer than the one they already use?
> 
> Joel,
> 
> I don't follow your logic here. Why would a multihomer request less IP
> addresses than he already uses, regardless of the minimum prefix size?
> 
> 
>> How quickly does one chew up /32s /30 /28s in the process of multihoming
>> the internet facing infrastructure in a smple-multihomed network?
> 
> When I was at the DNC, I structured the network to justify a /22. I
> really wanted a /23 but a /22 was what I could get.
> 
> I'm faced with a similar situation today. I need a /24 but I'll
> structure the network so that it justifies a /22. Just to be clear, I
> won't tell a single lie. I'll simply structure the network so that
> everything which could consume a public IP address does.
> 
> I doubt my experience is unique. I expect that many if not most of the
> /22 end-user requests are similarly padded, not because the registrant
> actually wants that many addresses but because that's what they can
> get.
> 
> Given the shortage of IPv4 addresses, why structure the policies so
> that we give anyone more than they actually want?


The minimum number of addresses that can be used may not in fact reflect
the minimum that should be used.

	For the purposes of minimizing fragmention.

	Supporting basic network operation (it's nice when traceroute
	and pmtud work) because your intermediate routers are privately
	numbered.
	
	Limiting the consequences of imagination failure, which may
	sound flippant but renumbering, requesting an additional block,
	or and point one and two are good reasons to make a potential
	multi-homer justify the assignment of a block of the appropriate
	size for that activity.


> Regards,
> Bill Herrin
> 
> 


From kkargel at polartel.com  Tue Jul 28 11:19:05 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 10:19:05 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F0C18.1000107@bogus.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>

I haven't been following this closely, sometimes work intrudes, but have we
all forgotten all the rationals that say that unaggregated /24's break
things?  Or are we assuming that everyone will be able to handle huge
routing tables or are we assuming that the /24 recipients don't care if they
can route beyond peers?  

I realize that IP's will become a smaller pool, so maybe the thinking is
that when this triggers there won't be enough /24's left to significantly
affect the routing tables?

I am still in the camp of "Keep doing what we are doing and when it runs out
it runs out."  Rationing is not always a good idea.  Trying to stretch out
resources indefinitely will be an exercize in futility.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Joel Jaeggli
> Sent: Tuesday, July 28, 2009 9:33 AM
> To: William Herrin
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> 
> 
> William Herrin wrote:
> > On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> >> Bill Darte wrote:
> >>> Every effort to lower minimum allocations throughout the years has met
> >>> with resistance.  Each successful policy managed a 'bit at a time' to
> >>> ensure 'nothing bad happened'....
> >> Realistically is it in the interest of a prospective multihomer to a
> >> recieve a prefix that's likely longer than the one they already use?
> >
> > Joel,
> >
> > I don't follow your logic here. Why would a multihomer request less IP
> > addresses than he already uses, regardless of the minimum prefix size?
> >
> >
> >> How quickly does one chew up /32s /30 /28s in the process of
> multihoming
> >> the internet facing infrastructure in a smple-multihomed network?
> >
> > When I was at the DNC, I structured the network to justify a /22. I
> > really wanted a /23 but a /22 was what I could get.
> >
> > I'm faced with a similar situation today. I need a /24 but I'll
> > structure the network so that it justifies a /22. Just to be clear, I
> > won't tell a single lie. I'll simply structure the network so that
> > everything which could consume a public IP address does.
> >
> > I doubt my experience is unique. I expect that many if not most of the
> > /22 end-user requests are similarly padded, not because the registrant
> > actually wants that many addresses but because that's what they can
> > get.
> >
> > Given the shortage of IPv4 addresses, why structure the policies so
> > that we give anyone more than they actually want?
> 
> 
> The minimum number of addresses that can be used may not in fact reflect
> the minimum that should be used.
> 
> 	For the purposes of minimizing fragmention.
> 
> 	Supporting basic network operation (it's nice when traceroute
> 	and pmtud work) because your intermediate routers are privately
> 	numbered.
> 
> 	Limiting the consequences of imagination failure, which may
> 	sound flippant but renumbering, requesting an additional block,
> 	or and point one and two are good reasons to make a potential
> 	multi-homer justify the assignment of a block of the appropriate
> 	size for that activity.
> 
> 
> > Regards,
> > Bill Herrin
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/17197b6e/attachment.bin>

From scottleibrand at gmail.com  Tue Jul 28 11:22:08 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 28 Jul 2009 08:22:08 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
Message-ID: <4A6F17A0.50000@gmail.com>

Let me ask the inverse (or is it converse?) question:

Do you have evidence that unaggregated /24's (still) break things?  I 
haven't seen any evidence myself in the last 5 years...

Thanks,
Scott

Kevin Kargel wrote:
> I haven't been following this closely, sometimes work intrudes, but have we
> all forgotten all the rationals that say that unaggregated /24's break
> things?  Or are we assuming that everyone will be able to handle huge
> routing tables or are we assuming that the /24 recipients don't care if they
> can route beyond peers?  
>
> I realize that IP's will become a smaller pool, so maybe the thinking is
> that when this triggers there won't be enough /24's left to significantly
> affect the routing tables?
>
> I am still in the camp of "Keep doing what we are doing and when it runs out
> it runs out."  Rationing is not always a good idea.  Trying to stretch out
> resources indefinitely will be an exercize in futility.
>
>   
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Joel Jaeggli
>> Sent: Tuesday, July 28, 2009 9:33 AM
>> To: William Herrin
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>>
>>
>> William Herrin wrote:
>>     
>>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>>       
>>>> Bill Darte wrote:
>>>>         
>>>>> Every effort to lower minimum allocations throughout the years has met
>>>>> with resistance.  Each successful policy managed a 'bit at a time' to
>>>>> ensure 'nothing bad happened'....
>>>>>           
>>>> Realistically is it in the interest of a prospective multihomer to a
>>>> recieve a prefix that's likely longer than the one they already use?
>>>>         
>>> Joel,
>>>
>>> I don't follow your logic here. Why would a multihomer request less IP
>>> addresses than he already uses, regardless of the minimum prefix size?
>>>
>>>
>>>       
>>>> How quickly does one chew up /32s /30 /28s in the process of
>>>>         
>> multihoming
>>     
>>>> the internet facing infrastructure in a smple-multihomed network?
>>>>         
>>> When I was at the DNC, I structured the network to justify a /22. I
>>> really wanted a /23 but a /22 was what I could get.
>>>
>>> I'm faced with a similar situation today. I need a /24 but I'll
>>> structure the network so that it justifies a /22. Just to be clear, I
>>> won't tell a single lie. I'll simply structure the network so that
>>> everything which could consume a public IP address does.
>>>
>>> I doubt my experience is unique. I expect that many if not most of the
>>> /22 end-user requests are similarly padded, not because the registrant
>>> actually wants that many addresses but because that's what they can
>>> get.
>>>
>>> Given the shortage of IPv4 addresses, why structure the policies so
>>> that we give anyone more than they actually want?
>>>       
>> The minimum number of addresses that can be used may not in fact reflect
>> the minimum that should be used.
>>
>> 	For the purposes of minimizing fragmention.
>>
>> 	Supporting basic network operation (it's nice when traceroute
>> 	and pmtud work) because your intermediate routers are privately
>> 	numbered.
>>
>> 	Limiting the consequences of imagination failure, which may
>> 	sound flippant but renumbering, requesting an additional block,
>> 	or and point one and two are good reasons to make a potential
>> 	multi-homer justify the assignment of a block of the appropriate
>> 	size for that activity.
>>
>>
>>     
>>> Regards,
>>> Bill Herrin
>>>
>>>
>>>       
>> _______________________________________________
>> 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 tedm at ipinc.net  Tue Jul 28 11:25:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 08:25:27 -0700
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
 ISPs
In-Reply-To: <28E139F46D45AF49A31950F88C497458025C4BC1@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458025C4BC1@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A6F1867.1050501@ipinc.net>

michael.dillon at bt.com wrote:
>> Where I'm coming from is simple - we all know that there's 
>> small fry out there, we all know that some of those small fry 
>> are gonna get stomped hard by IPv4 runout, and since the 
>> small fry definitely didn't cause IPv4 runout, I just felt it 
>> was kind of unfair to allow that to happen without throwing 
>> them a lifeline.  
> 
> Small fry have less work to do to deploy IPv6.
> 
> Also, small fry who want to deploy carrier grade NAT don't need 
> to wait for IETF work and vendor implementations because they are
> small enough to do the job with existing NAT software. 
> 
> You can realistically run a small ISP using only free software 
> for routing and everything else by using Linux, FreeBSD, OpenBSD
> and/or OpenSolaris.
> 

You can realistically run a LARGE ISP using only free software.
Yahoo runs off it.  Hotmail ran off it before MS bought it to use as a 
testbed to perfect Windows Server.

Even if you deploy NAT on your own infrastructure you still have to
have public IP addresses somewhere.  And, when your customers themselves 
are running NAT what are you supposed to do?  Put them behind yet 
another NAT?  How many levels of NAT devices are we supposed to use on 
the Internet?

> Small size carries some advantages as well as disadvantages. It is
> a mistake to assume that IPv4 runout will crush small ISPs just because
> they are small. 

I don't assume it will crush small ISP's just because they are small.

I do assume that for SOME small ISPs they are operating in spaces where
there is a single monopoly upstream provider who is going to use the
IPv4 runout as reason to significantly raise costs for the small ISP. 
I'm not thinking of metropolitan areas where competition will prevent 
this from happening, I'm thinking of rural areas in particular.

> IPv4 runout will only crush poorly run businesses
> with lazy managers who lack foresight, regardless of whether those
> businesses are big or small.
> 

It is pretty clear from posts on this list and elsewhere that it is 
going to take a few years after ARIN assigns the last IPv4 address
for all major carriers to have native IPv6 offerings.  IPv4 is going
to have to get scarce and expensive before IPv6 becomes an issue for
a lot of people.

I agree that if an ISP right now is not pressuring their upstream for
native IPv6 and that if their upstream isn't natively running IPv6 that 
both of them are probably in the "poorly run businesses with lazy 
managers" category.

But if anything, allowing the smallest ISP's to obtain numbering from
ARIN will actually increase pressure on the 2nd tier networks to get
it in gear and deploy IPv6.

Look at it this way.  Say you have a small ISP with, say 500 customers
who is doing OK, out in Podunk MI.  The only network in their rural
area capable of even bringing fiber to them is PaBell Telco.  PaBell
also sells Internet connectivity and is staffed by lazy business 
managers who wouldn't know an IPv6 address if it bit them in the ass.

PaBell has been seeing a small erosion of their Internet customers to
Podunk ISP, but they are too lazy to do anything about it.  Podunk has
been bugging them to get IPv6 but PaBell lazy managers are too lazy to
bother with it right now.

I think that the ARIN community would like to see both PaBell and Podunk 
to go to IPv6.  Podunk ISP can and will do it because they are small
and it's easy to do.  But PaBell isn't going to do it until they are
pushed against the wall with a gun on them.  They would just as soon
buy IPv4 post runout under the directed transfer section of the NRPM.
As long as Podunk is dependent on PaBell for IPv4 numbering, if Podunk
seriously challenges PaBell by taking many customers away from them,
PaBell will merely react by raising prices on the IPv4 they have 
assigned to Podunk, pushing them out of business.

Now, you can argue that PaBell could also do this by jacking up 
connectivity rates.  But, they can't do this without running afoul
of restraint of trade unless they also jack up connectivity rates for
all their other customers at the same time - which defeats the
purpose since that won't cause customers to migrate back to PaBell from
Podunk.  That is why PaBell would most likely choose to attack Podunk
through fees on IPv4.  After all, the directed transfer market that
was approved in the NRPM - over my objections I might add- gives PaBell
a perfect excuse to claim that their fees for IPv4 are going up, so
they have a perfect right to jack up costs for numbering they have
assigned to Podunk ISP.

One last thing I will say about this - the truth is, my proposal is
actually putting things back the way they were originally.  Years ago
it was possible to obtain not just a /23 directly, but a /24 as well.


Ted



> --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 cgrundemann at gmail.com  Tue Jul 28 11:26:17 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jul 2009 09:26:17 -0600
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6DF3D0.506.101099CE@farmer.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu> <4A6E00A6.90109@ipinc.net>
	<443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>
	<4A6DF3D0.506.101099CE@farmer.umn.edu>
Message-ID: <443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>

On Mon, Jul 27, 2009 at 17:37, David Farmer<farmer at umn.edu> wrote:
> On 27 Jul 2009 Chris Grundemann wrote:
>
>> On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>> >
>> > David Farmer wrote:
>> >> 1. Should they be merged together and move forward as a single Draft Policy?
>> >>
>> >
>> > yes.
>>
>> +1
>>
>> My recommendation is that proposal 94 is merged into proposal 93,
>> leaving the fairly arbitrary date based method of reduction behind in
>> favor of a remaining resources based implementation (and limit it to
>> IPv4 explicitly); such as "when ARIN receives its last /8, an
>> organization may choose to request up to a 6 month supply of IPv4
>> resources" or some more finely graduated but similarly triggered
>> reduction.
>>
>> $0.02,
>> ~Chris
>
> I think I see what you are getting at;
>
> How about something like this;
>
> IANA pool down to X /8s, triggers 9 month allocation window
> IANA pool down to Y /8s, triggers 6 month allocation window
> IANA pool down to Z /8s, triggers 3 month allocation window
> ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN
> free pool per allocation.

Yes, this is exactly what my intention was.

> Maybe with X=25, Y=15, ?Z=10, but I need think about the numbers more.

Some facts to help the discussion (correct me if I am wrong):

There are currently 30 /8s Unallocated by IANA.
So far 4 /8s have been allocated this year.
In 2008 IANA allocated 9 /8s.
In 2007 IANA allocated 13 /8s. [1]

There have been an average of 207 /24s requested from ARIN per month
this year. [2]
The average for 2008 was 200 /24s per month.
The average for 2007 was 197 /24s per month. [3]

So if we make things simple for ourselves we could say that 10 /8s
will last about a year and that ARIN hands out about 10 /16s in that
year.  These numbers are admittedly fuzzy and of course become even
less absolute once we get closer to free pool exhaustion and start
playing with the allocations but I think they work ok for my purposes
here, at least for the moment.


The original text set the policy to start limiting the allocation
window a year from now, I think that is reasonable and if we want to
stick close to that, I think X=20.

Then, imo, we should stagger into the next two reductions,
incrementally shortening the time that we keep each subsequent
allocation window.  So perhaps Y=12 (leaving us at a 9 month window
for 8 /8s) and Z=6 (keeping the 6 month window for 6 /8s) and then
trigger the maximum allocation at 1 /8 (having maintained a 3 month
window for 5 /8s).

There obviously needs to be some further discussion around these
triggers but those tweaks could happen after the merged policy is
presented in Dearborn, imho.


> The one advantage of setting arbitrary dates for the allocation window
> changes are everyone knows when they will happen.
>
> With something like this you won't have arbitrary dates anymore, but you
> won't know exactly when the changes will hit either, and the threshold of
> number of /8s left are probably somewhat arbitrary instead of the dates.

I am sure some (perhaps many) will complain that dates are more
predictable and that businesses can better plan for them, etc. But I
think that the remaining available space is so much more relevant to a
policy such as this that it outweighs that bit of uncertainty.  I
would also point out (again) that the prudent business plan here
should be a migration strategy to a network which is IPv6 capable (I
did not say exclusive), not solely an IPv4 address request tactic.

> So which would people prefer?
>
> 1. Well known dates, or;
> 2. Triggers based on the actual resources left
>
> I really need feed back on how people want to see this, and if you support
> this kind of proposal or not.
>
> There was a bunch of discussion on the ARIN-Discuss list last week about
> recovering legacy space, it is much easier to set policy on how we are going
> to divvy up what is left of the IPv4 space than it is to get anyone to give any
> back. ?So maybe we can put as much energy into creating policy about the
> IPv4 space that is left than was put into the discussion about trying to
> recover space last week. ?Personally I'm much more optimistic that we can
> do something about Run-Out policies than I'm about the chances to get
> people to give back space.
>
> Thanks
>
> ===============================================
> David Farmer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Email:farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota ? ? ? ? ? ? ? ?Phone: 612-626-0815
> 2218 University Ave SE ? ? ? ? ? ? ? ? Cell: 612-812-9952
> Minneapolis, MN 55414-3029 ? ? ? ? ? ? FAX: 612-626-1818
> ===============================================
>

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From bill at herrin.us  Tue Jul 28 11:29:35 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jul 2009 11:29:35 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F0C18.1000107@bogus.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
Message-ID: <3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>

On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> William Herrin wrote:
>> Given the shortage of IPv4 addresses, why structure the policies so
>> that we give anyone more than they actually want?
>
> The minimum number of addresses that can be used may not in fact reflect
> the minimum that should be used.
>
> ? ? ? ?For the purposes of minimizing fragmention.
>
> ? ? ? ?Supporting basic network operation (it's nice when traceroute
> ? ? ? ?and pmtud work) because your intermediate routers are privately
> ? ? ? ?numbered.
>
> ? ? ? ?Limiting the consequences of imagination failure, which may
> ? ? ? ?sound flippant but renumbering, requesting an additional block,
> ? ? ? ?or and point one and two are good reasons to make a potential
> ? ? ? ?multi-homer justify the assignment of a block of the appropriate
> ? ? ? ?size for that activity.

Hi Joel,

I could almost see that argument on the ISP side but it doesn't make
sense to me on the end-user side, particularly when they may be
trivially multihomed. I surely wouldn't want to presume that I know
every registrant's address count needs better than he does though. f
you don't mind, let's just focus on the downside risk.

So, the registrant asks for a /24 and a year later his replacement who
is a better network engineer figures out he really needs a /22 after
all. What's the impact? Other than insisting on giving him a /22 up
front, is there another way to mitigate that impact?

Regards,
Bill Herrin


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


From tedm at ipinc.net  Tue Jul 28 11:33:00 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 08:33:00 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
Message-ID: <4A6F1A2C.1010008@ipinc.net>

Kevin Kargel wrote:
> I haven't been following this closely, sometimes work intrudes, but have we
> all forgotten all the rationals that say that unaggregated /24's break
> things?  Or are we assuming that everyone will be able to handle huge
> routing tables or are we assuming that the /24 recipients don't care if they
> can route beyond peers?  
> 

For years we advertised a single /24 on a dialup pool, that was an old
direct assignment that a customer of ours had got then abandoned.  I
did this mainly to test the hypothesis that a /24 is too small to be
fully routed.  I waited years for a customer complaint that they 
couldn't reach some place, and never got one.

Granted, I finally let the /24 go back in 2004 so things might have
changed since then.

Ted

PS   That /24 is still abandoned.

> I realize that IP's will become a smaller pool, so maybe the thinking is
> that when this triggers there won't be enough /24's left to significantly
> affect the routing tables?
> 
> I am still in the camp of "Keep doing what we are doing and when it runs out
> it runs out."  Rationing is not always a good idea.  Trying to stretch out
> resources indefinitely will be an exercize in futility.
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Joel Jaeggli
>> Sent: Tuesday, July 28, 2009 9:33 AM
>> To: William Herrin
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>>
>>
>> William Herrin wrote:
>>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>>> Bill Darte wrote:
>>>>> Every effort to lower minimum allocations throughout the years has met
>>>>> with resistance.  Each successful policy managed a 'bit at a time' to
>>>>> ensure 'nothing bad happened'....
>>>> Realistically is it in the interest of a prospective multihomer to a
>>>> recieve a prefix that's likely longer than the one they already use?
>>> Joel,
>>>
>>> I don't follow your logic here. Why would a multihomer request less IP
>>> addresses than he already uses, regardless of the minimum prefix size?
>>>
>>>
>>>> How quickly does one chew up /32s /30 /28s in the process of
>> multihoming
>>>> the internet facing infrastructure in a smple-multihomed network?
>>> When I was at the DNC, I structured the network to justify a /22. I
>>> really wanted a /23 but a /22 was what I could get.
>>>
>>> I'm faced with a similar situation today. I need a /24 but I'll
>>> structure the network so that it justifies a /22. Just to be clear, I
>>> won't tell a single lie. I'll simply structure the network so that
>>> everything which could consume a public IP address does.
>>>
>>> I doubt my experience is unique. I expect that many if not most of the
>>> /22 end-user requests are similarly padded, not because the registrant
>>> actually wants that many addresses but because that's what they can
>>> get.
>>>
>>> Given the shortage of IPv4 addresses, why structure the policies so
>>> that we give anyone more than they actually want?
>>
>> The minimum number of addresses that can be used may not in fact reflect
>> the minimum that should be used.
>>
>> 	For the purposes of minimizing fragmention.
>>
>> 	Supporting basic network operation (it's nice when traceroute
>> 	and pmtud work) because your intermediate routers are privately
>> 	numbered.
>>
>> 	Limiting the consequences of imagination failure, which may
>> 	sound flippant but renumbering, requesting an additional block,
>> 	or and point one and two are good reasons to make a potential
>> 	multi-homer justify the assignment of a block of the appropriate
>> 	size for that activity.
>>
>>
>>> Regards,
>>> Bill Herrin
>>>
>>>
>> _______________________________________________
>> 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 tedm at ipinc.net  Tue Jul 28 11:37:40 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 08:37:40 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu> <4A6E00A6.90109@ipinc.net>	
	<443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>	
	<4A6DF3D0.506.101099CE@farmer.umn.edu>
	<443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>
Message-ID: <4A6F1B44.1050903@ipinc.net>

Chris Grundemann wrote:
> On Mon, Jul 27, 2009 at 17:37, David Farmer<farmer at umn.edu> wrote:
>> On 27 Jul 2009 Chris Grundemann wrote:
>>
>>> On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>>>> David Farmer wrote:
>>>>> 1. Should they be merged together and move forward as a single Draft Policy?
>>>>>
>>>> yes.
>>> +1
>>>
>>> My recommendation is that proposal 94 is merged into proposal 93,
>>> leaving the fairly arbitrary date based method of reduction behind in
>>> favor of a remaining resources based implementation (and limit it to
>>> IPv4 explicitly); such as "when ARIN receives its last /8, an
>>> organization may choose to request up to a 6 month supply of IPv4
>>> resources" or some more finely graduated but similarly triggered
>>> reduction.
>>>
>>> $0.02,
>>> ~Chris
>> I think I see what you are getting at;
>>
>> How about something like this;
>>
>> IANA pool down to X /8s, triggers 9 month allocation window
>> IANA pool down to Y /8s, triggers 6 month allocation window
>> IANA pool down to Z /8s, triggers 3 month allocation window
>> ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN
>> free pool per allocation.
> 
> Yes, this is exactly what my intention was.
> 
>> Maybe with X=25, Y=15,  Z=10, but I need think about the numbers more.
> 
> Some facts to help the discussion (correct me if I am wrong):
> 
> There are currently 30 /8s Unallocated by IANA.
> So far 4 /8s have been allocated this year.
> In 2008 IANA allocated 9 /8s.
> In 2007 IANA allocated 13 /8s. [1]
> 
> There have been an average of 207 /24s requested from ARIN per month
> this year. [2]
> The average for 2008 was 200 /24s per month.
> The average for 2007 was 197 /24s per month. [3]
> 
> So if we make things simple for ourselves we could say that 10 /8s
> will last about a year and that ARIN hands out about 10 /16s in that
> year.  These numbers are admittedly fuzzy and of course become even
> less absolute once we get closer to free pool exhaustion and start
> playing with the allocations but I think they work ok for my purposes
> here, at least for the moment.
> 
> 
> The original text set the policy to start limiting the allocation
> window a year from now, I think that is reasonable and if we want to
> stick close to that, I think X=20.
> 
> Then, imo, we should stagger into the next two reductions,
> incrementally shortening the time that we keep each subsequent
> allocation window.  So perhaps Y=12 (leaving us at a 9 month window
> for 8 /8s) and Z=6 (keeping the 6 month window for 6 /8s) and then
> trigger the maximum allocation at 1 /8 (having maintained a 3 month
> window for 5 /8s).
> 
> There obviously needs to be some further discussion around these
> triggers but those tweaks could happen after the merged policy is
> presented in Dearborn, imho.
> 
> 
>> The one advantage of setting arbitrary dates for the allocation window
>> changes are everyone knows when they will happen.
>>
>> With something like this you won't have arbitrary dates anymore, but you
>> won't know exactly when the changes will hit either, and the threshold of
>> number of /8s left are probably somewhat arbitrary instead of the dates.
> 
> I am sure some (perhaps many) will complain that dates are more
> predictable and that businesses can better plan for them, etc. But I
> think that the remaining available space is so much more relevant to a
> policy such as this that it outweighs that bit of uncertainty. 

While this is fine for policy I think it cannot be underestimated the
impact that an actual date has on the general public - and consider
your CEO's members of the general public when it comes to this issue.

Ted


From joelja at bogus.com  Tue Jul 28 11:39:47 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 28 Jul 2009 17:39:47 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F17A0.50000@gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com>
Message-ID: <4A6F1BC3.6000305@bogus.com>

Scott Leibrand wrote:
> Let me ask the inverse (or is it converse?) question:
> 
> Do you have evidence that unaggregated /24's (still) break things?  I
> haven't seen any evidence myself in the last 5 years...

Not convinced that the growth in the number of dfz advertised prefixes
needs additional incentives beyond those already cooked in.

The assertion that cidr allowed us to step back from the abyss in the
era of 10k prefixs is I think well founded. As is the contribution of
stub AS to overall update rates.

It seems likely that at some point networks will likely routinely accept
longer prefixes than /24. There is already some good evidence of the
reachability of /25s. That something is inevitable, is in itself not a
reason to discourage it.

joel

> Thanks,
> Scott
> 
> Kevin Kargel wrote:
>> I haven't been following this closely, sometimes work intrudes, but
>> have we
>> all forgotten all the rationals that say that unaggregated /24's break
>> things?  Or are we assuming that everyone will be able to handle huge
>> routing tables or are we assuming that the /24 recipients don't care
>> if they
>> can route beyond peers? 
>> I realize that IP's will become a smaller pool, so maybe the thinking is
>> that when this triggers there won't be enough /24's left to significantly
>> affect the routing tables?
>>
>> I am still in the camp of "Keep doing what we are doing and when it
>> runs out
>> it runs out."  Rationing is not always a good idea.  Trying to stretch
>> out
>> resources indefinitely will be an exercize in futility.
>>
>>  
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of Joel Jaeggli
>>> Sent: Tuesday, July 28, 2009 9:33 AM
>>> To: William Herrin
>>> Cc: ARIN PPML
>>> Subject: Re: [arin-ppml] Rationale for /22
>>>
>>>
>>>
>>> William Herrin wrote:
>>>    
>>>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>>>      
>>>>> Bill Darte wrote:
>>>>>        
>>>>>> Every effort to lower minimum allocations throughout the years has
>>>>>> met
>>>>>> with resistance.  Each successful policy managed a 'bit at a time' to
>>>>>> ensure 'nothing bad happened'....
>>>>>>           
>>>>> Realistically is it in the interest of a prospective multihomer to a
>>>>> recieve a prefix that's likely longer than the one they already use?
>>>>>         
>>>> Joel,
>>>>
>>>> I don't follow your logic here. Why would a multihomer request less IP
>>>> addresses than he already uses, regardless of the minimum prefix size?
>>>>
>>>>
>>>>      
>>>>> How quickly does one chew up /32s /30 /28s in the process of
>>>>>         
>>> multihoming
>>>    
>>>>> the internet facing infrastructure in a smple-multihomed network?
>>>>>         
>>>> When I was at the DNC, I structured the network to justify a /22. I
>>>> really wanted a /23 but a /22 was what I could get.
>>>>
>>>> I'm faced with a similar situation today. I need a /24 but I'll
>>>> structure the network so that it justifies a /22. Just to be clear, I
>>>> won't tell a single lie. I'll simply structure the network so that
>>>> everything which could consume a public IP address does.
>>>>
>>>> I doubt my experience is unique. I expect that many if not most of the
>>>> /22 end-user requests are similarly padded, not because the registrant
>>>> actually wants that many addresses but because that's what they can
>>>> get.
>>>>
>>>> Given the shortage of IPv4 addresses, why structure the policies so
>>>> that we give anyone more than they actually want?
>>>>       
>>> The minimum number of addresses that can be used may not in fact reflect
>>> the minimum that should be used.
>>>
>>>     For the purposes of minimizing fragmention.
>>>
>>>     Supporting basic network operation (it's nice when traceroute
>>>     and pmtud work) because your intermediate routers are privately
>>>     numbered.
>>>
>>>     Limiting the consequences of imagination failure, which may
>>>     sound flippant but renumbering, requesting an additional block,
>>>     or and point one and two are good reasons to make a potential
>>>     multi-homer justify the assignment of a block of the appropriate
>>>     size for that activity.
>>>
>>>
>>>    
>>>> Regards,
>>>> Bill Herrin
>>>>
>>>>
>>>>       
>>> _______________________________________________
>>> 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.
> 


From kkargel at polartel.com  Tue Jul 28 11:53:53 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 10:53:53 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F17A0.50000@gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DCB@mail>

I believe that the reason there is not a huge problem with unaggregated
/24's is that there are not very many unaggregated /24's being delivered.

Current wisdom says it is a bad idea, so people are not doing it, so there
is not a big problem.

People very rarely poke sharp sticks in their eyes, so there is not a big
problem with eye injuries from intentional sharp stick jabs.  I do not
believe that poking yourself in the eye with a sharp stick should be ok
because there is not current evidence of a problem from that action.  

A few extra routing table entries from infrequent gratuitous /24's is not a
problem.  If we start flooding the tables with them it may be a problem.  As
I said before this will be self limiting because of the finite number of
/24's to hand out.

I am not stomping my foot and saying there will absolutely be an issue, I
would just like to be reassured that it has been considered.



> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Tuesday, July 28, 2009 10:22 AM
> To: Kevin Kargel
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Let me ask the inverse (or is it converse?) question:
> 
> Do you have evidence that unaggregated /24's (still) break things?  I
> haven't seen any evidence myself in the last 5 years...
> 
> Thanks,
> Scott
> 
> Kevin Kargel wrote:
> > I haven't been following this closely, sometimes work intrudes, but have
> we
> > all forgotten all the rationals that say that unaggregated /24's break
> > things?  Or are we assuming that everyone will be able to handle huge
> > routing tables or are we assuming that the /24 recipients don't care if
> they
> > can route beyond peers?
> >
> > I realize that IP's will become a smaller pool, so maybe the thinking is
> > that when this triggers there won't be enough /24's left to
> significantly
> > affect the routing tables?
> >
> > I am still in the camp of "Keep doing what we are doing and when it runs
> out
> > it runs out."  Rationing is not always a good idea.  Trying to stretch
> out
> > resources indefinitely will be an exercize in futility.
> >
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> >> Behalf Of Joel Jaeggli
> >> Sent: Tuesday, July 28, 2009 9:33 AM
> >> To: William Herrin
> >> Cc: ARIN PPML
> >> Subject: Re: [arin-ppml] Rationale for /22
> >>
> >>
> >>
> >> William Herrin wrote:
> >>
> >>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> >>>
> >>>> Bill Darte wrote:
> >>>>
> >>>>> Every effort to lower minimum allocations throughout the years has
> met
> >>>>> with resistance.  Each successful policy managed a 'bit at a time'
> to
> >>>>> ensure 'nothing bad happened'....
> >>>>>
> >>>> Realistically is it in the interest of a prospective multihomer to a
> >>>> recieve a prefix that's likely longer than the one they already use?
> >>>>
> >>> Joel,
> >>>
> >>> I don't follow your logic here. Why would a multihomer request less IP
> >>> addresses than he already uses, regardless of the minimum prefix size?
> >>>
> >>>
> >>>
> >>>> How quickly does one chew up /32s /30 /28s in the process of
> >>>>
> >> multihoming
> >>
> >>>> the internet facing infrastructure in a smple-multihomed network?
> >>>>
> >>> When I was at the DNC, I structured the network to justify a /22. I
> >>> really wanted a /23 but a /22 was what I could get.
> >>>
> >>> I'm faced with a similar situation today. I need a /24 but I'll
> >>> structure the network so that it justifies a /22. Just to be clear, I
> >>> won't tell a single lie. I'll simply structure the network so that
> >>> everything which could consume a public IP address does.
> >>>
> >>> I doubt my experience is unique. I expect that many if not most of the
> >>> /22 end-user requests are similarly padded, not because the registrant
> >>> actually wants that many addresses but because that's what they can
> >>> get.
> >>>
> >>> Given the shortage of IPv4 addresses, why structure the policies so
> >>> that we give anyone more than they actually want?
> >>>
> >> The minimum number of addresses that can be used may not in fact
> reflect
> >> the minimum that should be used.
> >>
> >> 	For the purposes of minimizing fragmention.
> >>
> >> 	Supporting basic network operation (it's nice when traceroute
> >> 	and pmtud work) because your intermediate routers are privately
> >> 	numbered.
> >>
> >> 	Limiting the consequences of imagination failure, which may
> >> 	sound flippant but renumbering, requesting an additional block,
> >> 	or and point one and two are good reasons to make a potential
> >> 	multi-homer justify the assignment of a block of the appropriate
> >> 	size for that activity.
> >>
> >>
> >>
> >>> Regards,
> >>> Bill Herrin
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/de49e63b/attachment.bin>

From bill at herrin.us  Tue Jul 28 11:56:00 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jul 2009 11:56:00 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
Message-ID: <3c3e3fca0907280856tf36141dl8f0cb82fe647324d@mail.gmail.com>

On Tue, Jul 28, 2009 at 11:19 AM, Kevin Kargel<kkargel at polartel.com> wrote:
> I haven't been following this closely, sometimes work intrudes, but have we
> all forgotten all the rationals that say that unaggregated /24's break
> things? ?Or are we assuming that everyone will be able to handle huge
> routing tables or are we assuming that the /24 recipients don't care if they
> can route beyond peers?

Hi Kevin,

I thought the problem was a large number of disaggregate announcements
from an org's single network topology needlessly fill expensive TCAMs.
I'm not aware that the size of the announcements has anything to do
with it; just the count. Right?

Anyway, we're talking about multihomers here, so I don't think we're
talking about adding new route announcements at all, are we? We're
talking about folks who are announcing a cut-out /24 from an ISP's
larger block (NRPM 4.2.3.6) and allowing them to announce a direct
ARIN assignment instead. Same address count. Same consumption in the
routing table. But without all of the nasty problems associated with
cutting a /24 out of an ISP's block.

Some of the problems with cutting a /24 out of an ISP's block include:

* Causes major grief with reverse path filtering / spoofing
protection. If the ISP implements this at all, multihomed cutouts have
to be explicitly excluded. In effect, ties the ISP's hands with
respect to his internal network management.

* There are some funky issues with BGP which make withdrawing a cutout
route a lot slower than re-establishing an independent route.

* Grief with SWIP reporting errors that cause administrative hassles
getting the addresses announced properly.

* RIR boundary filtering that causes multihoming to malfunction during
major network partition events (when you most want multihoming to work
right)

* Renumbering when you change vendors.


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 dlw+arin at tellme.com  Tue Jul 28 11:52:41 2009
From: dlw+arin at tellme.com (David Williamson)
Date: Tue, 28 Jul 2009 08:52:41 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
Message-ID: <20090728155241.GR4935@shell02.cell.sv2.tellme.com>

You suggest that this proposal (or anything like 2007-6) will "break
things".  By "things", I assume you mean the ongoing growth of the
routing table.  Two things:

While I think mast of us are concerned about routing table growth, it's
a problem that is unrelated to good stewardship of the address space.  That's
why routability of any given block is explicitly note to not be guaranteed
by the NRPM.

Also, please tell me how this contributes to routing table growth.  If
you are a multihomed org, you are already consuming a routing slot (and
probably a /24).  It's just not yours, and you are stuck with some
provider's space, and have to renumber when you change primary
providers.  (Your other providers also have to change their configs to
route your ne space, and there's probably a transition when the org is
consuming two routing slots in the DFZ instead of one.)

I'm sorry, but I don't buy this argument.  It's just a different block
in the DFZ, but it won't add to overall consumption.  It's also
interesting to me that the other RIRs allow /24
allocations/assignments, and we haven't seen any added routing table
growth (beyond the normal explosive growth) as a result of that.

-David


On Tue, Jul 28, 2009 at 10:19:05AM -0500, Kevin Kargel wrote:
> I haven't been following this closely, sometimes work intrudes, but have we
> all forgotten all the rationals that say that unaggregated /24's break
> things?  Or are we assuming that everyone will be able to handle huge
> routing tables or are we assuming that the /24 recipients don't care if they
> can route beyond peers?  
> 
> I realize that IP's will become a smaller pool, so maybe the thinking is
> that when this triggers there won't be enough /24's left to significantly
> affect the routing tables?
> 
> I am still in the camp of "Keep doing what we are doing and when it runs out
> it runs out."  Rationing is not always a good idea.  Trying to stretch out
> resources indefinitely will be an exercize in futility.
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of Joel Jaeggli
> > Sent: Tuesday, July 28, 2009 9:33 AM
> > To: William Herrin
> > Cc: ARIN PPML
> > Subject: Re: [arin-ppml] Rationale for /22
> > 
> > 
> > 
> > William Herrin wrote:
> > > On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > >> Bill Darte wrote:
> > >>> Every effort to lower minimum allocations throughout the years has met
> > >>> with resistance.  Each successful policy managed a 'bit at a time' to
> > >>> ensure 'nothing bad happened'....
> > >> Realistically is it in the interest of a prospective multihomer to a
> > >> recieve a prefix that's likely longer than the one they already use?
> > >
> > > Joel,
> > >
> > > I don't follow your logic here. Why would a multihomer request less IP
> > > addresses than he already uses, regardless of the minimum prefix size?
> > >
> > >
> > >> How quickly does one chew up /32s /30 /28s in the process of
> > multihoming
> > >> the internet facing infrastructure in a smple-multihomed network?
> > >
> > > When I was at the DNC, I structured the network to justify a /22. I
> > > really wanted a /23 but a /22 was what I could get.
> > >
> > > I'm faced with a similar situation today. I need a /24 but I'll
> > > structure the network so that it justifies a /22. Just to be clear, I
> > > won't tell a single lie. I'll simply structure the network so that
> > > everything which could consume a public IP address does.
> > >
> > > I doubt my experience is unique. I expect that many if not most of the
> > > /22 end-user requests are similarly padded, not because the registrant
> > > actually wants that many addresses but because that's what they can
> > > get.
> > >
> > > Given the shortage of IPv4 addresses, why structure the policies so
> > > that we give anyone more than they actually want?
> > 
> > 
> > The minimum number of addresses that can be used may not in fact reflect
> > the minimum that should be used.
> > 
> > 	For the purposes of minimizing fragmention.
> > 
> > 	Supporting basic network operation (it's nice when traceroute
> > 	and pmtud work) because your intermediate routers are privately
> > 	numbered.
> > 
> > 	Limiting the consequences of imagination failure, which may
> > 	sound flippant but renumbering, requesting an additional block,
> > 	or and point one and two are good reasons to make a potential
> > 	multi-homer justify the assignment of a block of the appropriate
> > 	size for that activity.
> > 
> > 
> > > Regards,
> > > Bill Herrin
> > >
> > >
> > _______________________________________________
> > 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 cgrundemann at gmail.com  Tue Jul 28 12:03:20 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jul 2009 10:03:20 -0600
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DCB@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DCB@mail>
Message-ID: <443de7ad0907280903t44a56d0ao36e63337e6067800@mail.gmail.com>

On Tue, Jul 28, 2009 at 09:53, Kevin Kargel<kkargel at polartel.com> wrote:
> I believe that the reason there is not a huge problem with unaggregated
> /24's is that there are not very many unaggregated /24's being delivered.

A quick look at the routing table on one of my employer's peering
routers shows 155,060 /24s currently, not counting any from our own
AS.

> Current wisdom says it is a bad idea, so people are not doing it, so there
> is not a big problem.

Unfortunately a lot of big ISPs are doing it, take a look at NANOGs
Weekly Routing Table Report:

"
Analysis Summary
----------------
BGP routing table entries examined:              292250
   Prefixes after maximum aggregation:           138369
   Deaggregation factor:                         2.11


ARIN Region per AS prefix count summary
---------------------------------------
 ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     4241       3643         324   bellsouth.net, inc.
 4323     1899       1050         386   Time Warner Telecom
 1785     1713        714         139   PaeTec Communications, Inc.
 7018     1511       5907        1047   AT&T WorldNet Services
20115     1423       1461         678   Charter Communications
 2386     1272        670         924   AT&T Data Communications Serv
 6478     1242        275         315   AT&T Worldnet Services
 3356     1190      10960         441   Level 3 Communications, LLC
11492     1128        208          12   Cable One
22773     1077       2604          66   Cox Communications, Inc.
"

As others have stated, this may actually allow those ISPs to better
aggregate their space - because they won't have to allow the smaller
announcements to keep from breaking their small multihomed
customers...

> People very rarely poke sharp sticks in their eyes, so there is not a big
> problem with eye injuries from intentional sharp stick jabs. ?I do not
> believe that poking yourself in the eye with a sharp stick should be ok
> because there is not current evidence of a problem from that action.
>
> A few extra routing table entries from infrequent gratuitous /24's is not a
> problem. ?If we start flooding the tables with them it may be a problem. ?As
> I said before this will be self limiting because of the finite number of
> /24's to hand out.
>
> I am not stomping my foot and saying there will absolutely be an issue, I
> would just like to be reassured that it has been considered.

Agreed, is there a way to quantify the increase in demand (if any) for
/24s should ARIN be the one handing them out, instead of ISPs?

I think the larger concern may be a faster burn of ASNs?

~Chris
>
>
>
>> -----Original Message-----
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>> Sent: Tuesday, July 28, 2009 10:22 AM
>> To: Kevin Kargel
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>> Let me ask the inverse (or is it converse?) question:
>>
>> Do you have evidence that unaggregated /24's (still) break things? ?I
>> haven't seen any evidence myself in the last 5 years...
>>
>> Thanks,
>> Scott
>>
>> Kevin Kargel wrote:
>> > I haven't been following this closely, sometimes work intrudes, but have
>> we
>> > all forgotten all the rationals that say that unaggregated /24's break
>> > things? ?Or are we assuming that everyone will be able to handle huge
>> > routing tables or are we assuming that the /24 recipients don't care if
>> they
>> > can route beyond peers?
>> >
>> > I realize that IP's will become a smaller pool, so maybe the thinking is
>> > that when this triggers there won't be enough /24's left to
>> significantly
>> > affect the routing tables?
>> >
>> > I am still in the camp of "Keep doing what we are doing and when it runs
>> out
>> > it runs out." ?Rationing is not always a good idea. ?Trying to stretch
>> out
>> > resources indefinitely will be an exercize in futility.
>> >
>> >
>> >> -----Original Message-----
>> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> >> Behalf Of Joel Jaeggli
>> >> Sent: Tuesday, July 28, 2009 9:33 AM
>> >> To: William Herrin
>> >> Cc: ARIN PPML
>> >> Subject: Re: [arin-ppml] Rationale for /22
>> >>
>> >>
>> >>
>> >> William Herrin wrote:
>> >>
>> >>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>> >>>
>> >>>> Bill Darte wrote:
>> >>>>
>> >>>>> Every effort to lower minimum allocations throughout the years has
>> met
>> >>>>> with resistance. ?Each successful policy managed a 'bit at a time'
>> to
>> >>>>> ensure 'nothing bad happened'....
>> >>>>>
>> >>>> Realistically is it in the interest of a prospective multihomer to a
>> >>>> recieve a prefix that's likely longer than the one they already use?
>> >>>>
>> >>> Joel,
>> >>>
>> >>> I don't follow your logic here. Why would a multihomer request less IP
>> >>> addresses than he already uses, regardless of the minimum prefix size?
>> >>>
>> >>>
>> >>>
>> >>>> How quickly does one chew up /32s /30 /28s in the process of
>> >>>>
>> >> multihoming
>> >>
>> >>>> the internet facing infrastructure in a smple-multihomed network?
>> >>>>
>> >>> When I was at the DNC, I structured the network to justify a /22. I
>> >>> really wanted a /23 but a /22 was what I could get.
>> >>>
>> >>> I'm faced with a similar situation today. I need a /24 but I'll
>> >>> structure the network so that it justifies a /22. Just to be clear, I
>> >>> won't tell a single lie. I'll simply structure the network so that
>> >>> everything which could consume a public IP address does.
>> >>>
>> >>> I doubt my experience is unique. I expect that many if not most of the
>> >>> /22 end-user requests are similarly padded, not because the registrant
>> >>> actually wants that many addresses but because that's what they can
>> >>> get.
>> >>>
>> >>> Given the shortage of IPv4 addresses, why structure the policies so
>> >>> that we give anyone more than they actually want?
>> >>>
>> >> The minimum number of addresses that can be used may not in fact
>> reflect
>> >> the minimum that should be used.
>> >>
>> >> ? ?For the purposes of minimizing fragmention.
>> >>
>> >> ? ?Supporting basic network operation (it's nice when traceroute
>> >> ? ?and pmtud work) because your intermediate routers are privately
>> >> ? ?numbered.
>> >>
>> >> ? ?Limiting the consequences of imagination failure, which may
>> >> ? ?sound flippant but renumbering, requesting an additional block,
>> >> ? ?or and point one and two are good reasons to make a potential
>> >> ? ?multi-homer justify the assignment of a block of the appropriate
>> >> ? ?size for that activity.
>> >>
>> >>
>> >>
>> >>> Regards,
>> >>> Bill Herrin
>> >>>
>> >>>
>> >>>
>> >> _______________________________________________
>> >> 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.

>

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From kkargel at polartel.com  Tue Jul 28 12:21:38 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 11:21:38 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907280856tf36141dl8f0cb82fe647324d@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<3c3e3fca0907280856tf36141dl8f0cb82fe647324d@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DCF@mail>

> Hi Kevin,
> 
> I thought the problem was a large number of disaggregate announcements
> from an org's single network topology needlessly fill expensive TCAMs.
> I'm not aware that the size of the announcements has anything to do
> with it; just the count. Right?
> 

Correct, count is meaningful, size is not.  Having said that, a small size
allocation increases the likelihood that a near future additional allocation
will be needed, thereby increasing count.  It will be increasingly likely
that the additional allocations will not be aggregable (is that a word?).

> Anyway, we're talking about multihomers here, so I don't think we're
> talking about adding new route announcements at all, are we? We're
> talking about folks who are announcing a cut-out /24 from an ISP's
> larger block (NRPM 4.2.3.6) and allowing them to announce a direct
> ARIN assignment instead. Same address count. Same consumption in the
> routing table. But without all of the nasty problems associated with
> cutting a /24 out of an ISP's block.

I thought we were talking about new portable allocations directly from ARIN
unrelated to the ISP's current allocation.  I will go back and read more
closely.  If this new allocation is not contiguous with the ISP allocations
then it will generate a new table entry.

> 
> Some of the problems with cutting a /24 out of an ISP's block include:
> 
> * Causes major grief with reverse path filtering / spoofing
> protection. If the ISP implements this at all, multihomed cutouts have
> to be explicitly excluded. In effect, ties the ISP's hands with
> respect to his internal network management.
> 
> * There are some funky issues with BGP which make withdrawing a cutout
> route a lot slower than re-establishing an independent route.
> 
> * Grief with SWIP reporting errors that cause administrative hassles
> getting the addresses announced properly.
> 
> * RIR boundary filtering that causes multihoming to malfunction during
> major network partition events (when you most want multihoming to work
> right)
> 
> * Renumbering when you change vendors.
> 
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/69ca7dc1/attachment.bin>

From cgrundemann at gmail.com  Tue Jul 28 12:21:47 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jul 2009 10:21:47 -0600
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu> <4A6E00A6.90109@ipinc.net>
	<443de7ad0907271434r3e1acc71i392cd1a49f639a22@mail.gmail.com>
	<4A6DF3D0.506.101099CE@farmer.umn.edu>
	<443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>
Message-ID: <443de7ad0907280921t5c09be31g47e87a86b33a227@mail.gmail.com>

On Tue, Jul 28, 2009 at 09:26, Chris Grundemann<cgrundemann at gmail.com> wrote:
> On Mon, Jul 27, 2009 at 17:37, David Farmer<farmer at umn.edu> wrote:
>> On 27 Jul 2009 Chris Grundemann wrote:
>>
>>> On Mon, Jul 27, 2009 at 13:31, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>>> >
>>> > David Farmer wrote:
>>> >> 1. Should they be merged together and move forward as a single Draft Policy?
>>> >>
>>> >
>>> > yes.
>>>
>>> +1
>>>
>>> My recommendation is that proposal 94 is merged into proposal 93,
>>> leaving the fairly arbitrary date based method of reduction behind in
>>> favor of a remaining resources based implementation (and limit it to
>>> IPv4 explicitly); such as "when ARIN receives its last /8, an
>>> organization may choose to request up to a 6 month supply of IPv4
>>> resources" or some more finely graduated but similarly triggered
>>> reduction.
>>>
>>> $0.02,
>>> ~Chris
>>
>> I think I see what you are getting at;
>>
>> How about something like this;
>>
>> IANA pool down to X /8s, triggers 9 month allocation window
>> IANA pool down to Y /8s, triggers 6 month allocation window
>> IANA pool down to Z /8s, triggers 3 month allocation window
>> ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN
>> free pool per allocation.
>
> Yes, this is exactly what my intention was.
>
>> Maybe with X=25, Y=15, ?Z=10, but I need think about the numbers more.
>
> Some facts to help the discussion (correct me if I am wrong):
>
> There are currently 30 /8s Unallocated by IANA.
> So far 4 /8s have been allocated this year.
> In 2008 IANA allocated 9 /8s.
> In 2007 IANA allocated 13 /8s. [1]
>
> There have been an average of 207 /24s requested from ARIN per month
> this year. [2]
> The average for 2008 was 200 /24s per month.
> The average for 2007 was 197 /24s per month. [3]
>
> So if we make things simple for ourselves we could say that 10 /8s
> will last about a year and that ARIN hands out about 10 /16s in that
> year. ?These numbers are admittedly fuzzy and of course become even
> less absolute once we get closer to free pool exhaustion and start
> playing with the allocations but I think they work ok for my purposes
> here, at least for the moment.
>
>
> The original text set the policy to start limiting the allocation
> window a year from now, I think that is reasonable and if we want to
> stick close to that, I think X=20.
>
> Then, imo, we should stagger into the next two reductions,
> incrementally shortening the time that we keep each subsequent
> allocation window. ?So perhaps Y=12 (leaving us at a 9 month window
> for 8 /8s) and Z=6 (keeping the 6 month window for 6 /8s) and then
> trigger the maximum allocation at 1 /8 (having maintained a 3 month
> window for 5 /8s).

I forgot to account for the End Policy; when IANA reaches 5 /8s
unallocated, we will drop to zero.  Allowing for that, maybe a better
set is: X=20, Y=15 and Z=10.  Or perhaps we should take less steps and
go from a 12 month window to 6 and then to the 1/4 maximum.

~Chris

> There obviously needs to be some further discussion around these
> triggers but those tweaks could happen after the merged policy is
> presented in Dearborn, imho.
>
>
>> The one advantage of setting arbitrary dates for the allocation window
>> changes are everyone knows when they will happen.
>>
>> With something like this you won't have arbitrary dates anymore, but you
>> won't know exactly when the changes will hit either, and the threshold of
>> number of /8s left are probably somewhat arbitrary instead of the dates.
>
> I am sure some (perhaps many) will complain that dates are more
> predictable and that businesses can better plan for them, etc. But I
> think that the remaining available space is so much more relevant to a
> policy such as this that it outweighs that bit of uncertainty. ?I
> would also point out (again) that the prudent business plan here
> should be a migration strategy to a network which is IPv6 capable (I
> did not say exclusive), not solely an IPv4 address request tactic.
>
>> So which would people prefer?
>>
>> 1. Well known dates, or;
>> 2. Triggers based on the actual resources left
>>
>> I really need feed back on how people want to see this, and if you support
>> this kind of proposal or not.
>>
>> There was a bunch of discussion on the ARIN-Discuss list last week about
>> recovering legacy space, it is much easier to set policy on how we are going
>> to divvy up what is left of the IPv4 space than it is to get anyone to give any
>> back. ?So maybe we can put as much energy into creating policy about the
>> IPv4 space that is left than was put into the discussion about trying to
>> recover space last week. ?Personally I'm much more optimistic that we can
>> do something about Run-Out policies than I'm about the chances to get
>> people to give back space.
>>
>> Thanks
>>
>> ===============================================
>> David Farmer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Email:farmer at umn.edu
>> Office of Information Technology
>> Networking & Telecomunication Services
>> University of Minnesota ? ? ? ? ? ? ? ?Phone: 612-626-0815
>> 2218 University Ave SE ? ? ? ? ? ? ? ? Cell: 612-812-9952
>> Minneapolis, MN 55414-3029 ? ? ? ? ? ? FAX: 612-626-1818
>> ===============================================
>>

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From kkargel at polartel.com  Tue Jul 28 12:29:52 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 11:29:52 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>

Based on what everyone is saying about the /24 issue - and for the purpose
of argument accepting that /24 will cause no problems - then why not take it
a step further and remove any maximum length netmask restriction for a
multi-homed entity with a single allocation.

One entity with one allocation will generate one table entry regardless of
what size it is, so why limit them to a /24.  I am sure there are entities
out there who could operate just fine out of a /25 or even a /32, and so
long as they are not creating gratuitous route table entries then we could
be more efficient allowing them to only consume the space they need.




> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, July 28, 2009 10:30 AM
> To: Joel Jaeggli
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > William Herrin wrote:
> >> Given the shortage of IPv4 addresses, why structure the policies so
> >> that we give anyone more than they actually want?
> >
> > The minimum number of addresses that can be used may not in fact reflect
> > the minimum that should be used.
> >
> > ? ? ? ?For the purposes of minimizing fragmention.
> >
> > ? ? ? ?Supporting basic network operation (it's nice when traceroute
> > ? ? ? ?and pmtud work) because your intermediate routers are privately
> > ? ? ? ?numbered.
> >
> > ? ? ? ?Limiting the consequences of imagination failure, which may
> > ? ? ? ?sound flippant but renumbering, requesting an additional block,
> > ? ? ? ?or and point one and two are good reasons to make a potential
> > ? ? ? ?multi-homer justify the assignment of a block of the appropriate
> > ? ? ? ?size for that activity.
> 
> Hi Joel,
> 
> I could almost see that argument on the ISP side but it doesn't make
> sense to me on the end-user side, particularly when they may be
> trivially multihomed. I surely wouldn't want to presume that I know
> every registrant's address count needs better than he does though. f
> you don't mind, let's just focus on the downside risk.
> 
> So, the registrant asks for a /24 and a year later his replacement who
> is a better network engineer figures out he really needs a /22 after
> all. What's the impact? Other than insisting on giving him a /22 up
> front, is there another way to mitigate that impact?
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/e708251b/attachment.bin>

From spetty at iconnect-corp.com  Tue Jul 28 12:34:55 2009
From: spetty at iconnect-corp.com (Steven E. Petty)
Date: Tue, 28 Jul 2009 12:34:55 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
Message-ID: <402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>


  Obviously the primary reason for a limit is the accepted minimum routing entry size of a /24.  Of course, you knew that.  So why ask the question?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
Sent: Tuesday, July 28, 2009 12:30 PM
To: William Herrin; Joel Jaeggli
Cc: ARIN PPML
Subject: Re: [arin-ppml] Rationale for /22

Based on what everyone is saying about the /24 issue - and for the purpose of argument accepting that /24 will cause no problems - then why not take it a step further and remove any maximum length netmask restriction for a multi-homed entity with a single allocation.

One entity with one allocation will generate one table entry regardless of what size it is, so why limit them to a /24.  I am sure there are entities out there who could operate just fine out of a /25 or even a /32, and so long as they are not creating gratuitous route table entries then we could be more efficient allowing them to only consume the space they need.




> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of William Herrin
> Sent: Tuesday, July 28, 2009 10:30 AM
> To: Joel Jaeggli
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
>
> On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > William Herrin wrote:
> >> Given the shortage of IPv4 addresses, why structure the policies so
> >> that we give anyone more than they actually want?
> >
> > The minimum number of addresses that can be used may not in fact
> > reflect the minimum that should be used.
> >
> >        For the purposes of minimizing fragmention.
> >
> >        Supporting basic network operation (it's nice when traceroute
> >        and pmtud work) because your intermediate routers are privately
> >        numbered.
> >
> >        Limiting the consequences of imagination failure, which may
> >        sound flippant but renumbering, requesting an additional block,
> >        or and point one and two are good reasons to make a potential
> >        multi-homer justify the assignment of a block of the appropriate
> >        size for that activity.
>
> Hi Joel,
>
> I could almost see that argument on the ISP side but it doesn't make
> sense to me on the end-user side, particularly when they may be
> trivially multihomed. I surely wouldn't want to presume that I know
> every registrant's address count needs better than he does though. f
> you don't mind, let's just focus on the downside risk.
>
> So, the registrant asks for a /24 and a year later his replacement who
> is a better network engineer figures out he really needs a /22 after
> all. What's the impact? Other than insisting on giving him a /22 up
> front, is there another way to mitigate that impact?
>
> 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  Tue Jul 28 12:42:07 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jul 2009 10:42:07 -0600
Subject: [arin-ppml] Easy vs Hard (was Re: Policy Proposal: Last Minute
	Assistance for Small ISPs)
Message-ID: <443de7ad0907280942m3d198f8fj87f32658b36010a1@mail.gmail.com>

On Mon, Jul 27, 2009 at 12:23, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> David Farmer wrote:
>> How would you envision this working with other policy proposals? ?Such as
>> 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run Out
>> by Allocation Window.
>
> I think both of those proposals will suffer the same fate as
> 2007-05-02, "IPv4 Soft Landing"
>
> Unless my read of the ARIN participatory membership is incorrect,
> people are generally opposed to trying to keep chewing the
> gum once all the flavor is gone.
>
> There's not a lot of point to making the IPv4 requesting
> criteria so stringent that practically nobody can get an
> allocation. ?It reminds me of North Korea's 4 authorized "Christian"
> churches that are attended by nobody, and do nothing, but allow
> the regime to claim they are tolerant.
>
> Sure, if you make criteria for IPv4 so tough that nobody can
> meet it, you can claim that ARIN hasn't run out of IPv4 yet
> for the next 3-4 decades.
>
>> Would you do this instead of one or both of those
>>
>> or would you do this and one or both of those too?
>>
>
> I'm generally opposed to both of those proposals but my gut
> feel is they will be shot down anyway so I don't really feel
> "threatened" by them, nor do I really even bother to think
> about them. ?When I came up with
> this proposal I wasn't viewing it as an "opposition" proposal
> to those proposals.
>
> I can see, though, how someone might consider this to be diametrically
> opposed to those proposals. ?I'm suggesting we make it easier to get IPv4 at
> the last minute - those proposals are making it harder.

I disagree that proposals 93 and 94 would make it harder to get IPv4.

They would allow Orgs to get less IPv4 at once; which I guess could be
stated as "making it harder for an Org to get large amounts of IPv4"
or even "harder for an Org to get the desired amount of IPv4" but that
in turn will make it easier (read: possible) for other Orgs to get
some IPv4 (vs none).

Neither of those proposals make the requirements any more strict -
which is how I would define "making it harder."

$0.02
~Chris

>
> But this depends on how you view IPv4 runout. ?I view IPv4 runout
> as a fundamental fact, no amount of wriggling on the hook is
> going to get the worm off, it's gonna happen no matter how much
> IPv4 we dig out of the archives.
>
> Others who may view IPv4 runout as something that we actually have
> control over, and can manipulate, would probably feel that a
> proposal like mine undercuts the entire IPv4 addressing scheme.
>
> If people who are actively opposing those proposals want to use
> this proposal as a hill to rally behind, I don't care one way or
> the other. ?It wasn't intended as such, however.
>
> Where I'm coming from is simple - we all know that there's small
> fry out there, we all know that some of those small fry are gonna
> get stomped hard by IPv4 runout, and since the small fry definitely
> didn't cause IPv4 runout, I just felt it was kind of unfair to allow
> that to happen without throwing them a lifeline. ?After all it's
> not like it would really be a lot of skin off our collective nose
> to do this for them for a few years, and it would mean a great
> deal of difference to many of them.
>
> 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.
>





-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From scottleibrand at gmail.com  Tue Jul 28 12:37:59 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 28 Jul 2009 09:37:59 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
Message-ID: <4A6F2967.2060809@gmail.com>

Ironically enough, that is exactly what current policy in the RIPE 
region does, and on their policy list they're discussing changing the 
minimum size to /24, since very few organizations are willing to take 
anything smaller than that.

-Scott

Kevin Kargel wrote:
> Based on what everyone is saying about the /24 issue - and for the purpose
> of argument accepting that /24 will cause no problems - then why not take it
> a step further and remove any maximum length netmask restriction for a
> multi-homed entity with a single allocation.
>
> One entity with one allocation will generate one table entry regardless of
> what size it is, so why limit them to a /24.  I am sure there are entities
> out there who could operate just fine out of a /25 or even a /32, and so
> long as they are not creating gratuitous route table entries then we could
> be more efficient allowing them to only consume the space they need.
>
>
>
>
>   
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Tuesday, July 28, 2009 10:30 AM
>> To: Joel Jaeggli
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>> On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>     
>>> William Herrin wrote:
>>>       
>>>> Given the shortage of IPv4 addresses, why structure the policies so
>>>> that we give anyone more than they actually want?
>>>>         
>>> The minimum number of addresses that can be used may not in fact reflect
>>> the minimum that should be used.
>>>
>>>        For the purposes of minimizing fragmention.
>>>
>>>        Supporting basic network operation (it's nice when traceroute
>>>        and pmtud work) because your intermediate routers are privately
>>>        numbered.
>>>
>>>        Limiting the consequences of imagination failure, which may
>>>        sound flippant but renumbering, requesting an additional block,
>>>        or and point one and two are good reasons to make a potential
>>>        multi-homer justify the assignment of a block of the appropriate
>>>        size for that activity.
>>>       
>> Hi Joel,
>>
>> I could almost see that argument on the ISP side but it doesn't make
>> sense to me on the end-user side, particularly when they may be
>> trivially multihomed. I surely wouldn't want to presume that I know
>> every registrant's address count needs better than he does though. f
>> you don't mind, let's just focus on the downside risk.
>>
>> So, the registrant asks for a /24 and a year later his replacement who
>> is a better network engineer figures out he really needs a /22 after
>> all. What's the impact? Other than insisting on giving him a /22 up
>> front, is there another way to mitigate that impact?
>>
>> 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.
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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  Tue Jul 28 12:57:06 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 09:57:06 -0700
Subject: [arin-ppml] Easy vs Hard (was Re: Policy Proposal: Last Minute
 Assistance for Small ISPs)
In-Reply-To: <443de7ad0907280942m3d198f8fj87f32658b36010a1@mail.gmail.com>
References: <443de7ad0907280942m3d198f8fj87f32658b36010a1@mail.gmail.com>
Message-ID: <4A6F2DE2.8070002@ipinc.net>

Chris Grundemann wrote:
> On Mon, Jul 27, 2009 at 12:23, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> David Farmer wrote:
>>> How would you envision this working with other policy proposals?  Such as
>>> 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run Out
>>> by Allocation Window.
>> I think both of those proposals will suffer the same fate as
>> 2007-05-02, "IPv4 Soft Landing"
>>
>> Unless my read of the ARIN participatory membership is incorrect,
>> people are generally opposed to trying to keep chewing the
>> gum once all the flavor is gone.
>>
>> There's not a lot of point to making the IPv4 requesting
>> criteria so stringent that practically nobody can get an
>> allocation.  It reminds me of North Korea's 4 authorized "Christian"
>> churches that are attended by nobody, and do nothing, but allow
>> the regime to claim they are tolerant.
>>
>> Sure, if you make criteria for IPv4 so tough that nobody can
>> meet it, you can claim that ARIN hasn't run out of IPv4 yet
>> for the next 3-4 decades.
>>
>>> Would you do this instead of one or both of those
>>>
>>> or would you do this and one or both of those too?
>>>
>> I'm generally opposed to both of those proposals but my gut
>> feel is they will be shot down anyway so I don't really feel
>> "threatened" by them, nor do I really even bother to think
>> about them.  When I came up with
>> this proposal I wasn't viewing it as an "opposition" proposal
>> to those proposals.
>>
>> I can see, though, how someone might consider this to be diametrically
>> opposed to those proposals.  I'm suggesting we make it easier to get IPv4 at
>> the last minute - those proposals are making it harder.
> 
> I disagree that proposals 93 and 94 would make it harder to get IPv4.
> 
> They would allow Orgs to get less IPv4 at once; which I guess could be
> stated as "making it harder for an Org to get large amounts of IPv4"
> or even "harder for an Org to get the desired amount of IPv4" but that
> in turn will make it easier (read: possible) for other Orgs to get
> some IPv4 (vs none).
> 
> Neither of those proposals make the requirements any more strict -
> which is how I would define "making it harder."
> 

I wasn't speaking about "more difficult" on an individual org level, but
rather a community level.  It would have been more accurate to say:

"I'm suggesting we make increase the rate at which IPv4 is allocated at 
the last minute - those proposals are suggesting we decrease the rate at 
which IPv4 is allocated at the last minute."

So as I said I do see how someone could view the 2 proposals as in
opposition to each other.

Ted


From tedm at ipinc.net  Tue Jul 28 13:03:57 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 10:03:57 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
Message-ID: <4A6F2F7D.7040601@ipinc.net>

Kevin Kargel wrote:
> Based on what everyone is saying about the /24 issue - and for the purpose
> of argument accepting that /24 will cause no problems - then why not take it
> a step further and remove any maximum length netmask restriction for a
> multi-homed entity with a single allocation.
> 
> One entity with one allocation will generate one table entry regardless of
> what size it is, so why limit them to a /24.  I am sure there are entities
> out there who could operate just fine out of a /25 or even a /32, and so
> long as they are not creating gratuitous route table entries then we could
> be more efficient allowing them to only consume the space they need.
> 

If you set the minimum size of a table entry to /25 instead of /24 then
you have now doubled the possible table entries.  It doesn't matter if 
the entries are gratuitous or not, the way subnet mathematics works, for
every drop in the bit boundary, from /25 to /26 to /27 and so on, you
double, quadruple, etc. the total possible route entries.

With the increase in router ram and router CPU speed over the years, 
some decrease in the minimum is warranted.  If we didn't have IPv6 
coming up - which will also double the number of advertisements once
everyone runs dual-stack - we could support an even further decrease
in the minimum.  But we can't yet support multiplying the number of
potential routing slots by 200 on the Internet.

Ted


From kkargel at polartel.com  Tue Jul 28 13:02:57 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 12:02:57 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com><3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>

> 
>   Obviously the primary reason for a limit is the accepted minimum routing
> entry size of a /24.  Of course, you knew that.  So why ask the question?

Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
it won't cause problems then why not extend the mask size?  Or are you
saying that long mask route entries do in fact cause problems?

> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Kargel
> Sent: Tuesday, July 28, 2009 12:30 PM
> To: William Herrin; Joel Jaeggli
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Based on what everyone is saying about the /24 issue - and for the purpose
> of argument accepting that /24 will cause no problems - then why not take
> it a step further and remove any maximum length netmask restriction for a
> multi-homed entity with a single allocation.
> 
> One entity with one allocation will generate one table entry regardless of
> what size it is, so why limit them to a /24.  I am sure there are entities
> out there who could operate just fine out of a /25 or even a /32, and so
> long as they are not creating gratuitous route table entries then we could
> be more efficient allowing them to only consume the space they need.
> 
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of William Herrin
> > Sent: Tuesday, July 28, 2009 10:30 AM
> > To: Joel Jaeggli
> > Cc: ARIN PPML
> > Subject: Re: [arin-ppml] Rationale for /22
> >
> > On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > > William Herrin wrote:
> > >> Given the shortage of IPv4 addresses, why structure the policies so
> > >> that we give anyone more than they actually want?
> > >
> > > The minimum number of addresses that can be used may not in fact
> > > reflect the minimum that should be used.
> > >
> > >        For the purposes of minimizing fragmention.
> > >
> > >        Supporting basic network operation (it's nice when traceroute
> > >        and pmtud work) because your intermediate routers are privately
> > >        numbered.
> > >
> > >        Limiting the consequences of imagination failure, which may
> > >        sound flippant but renumbering, requesting an additional block,
> > >        or and point one and two are good reasons to make a potential
> > >        multi-homer justify the assignment of a block of the
> appropriate
> > >        size for that activity.
> >
> > Hi Joel,
> >
> > I could almost see that argument on the ISP side but it doesn't make
> > sense to me on the end-user side, particularly when they may be
> > trivially multihomed. I surely wouldn't want to presume that I know
> > every registrant's address count needs better than he does though. f
> > you don't mind, let's just focus on the downside risk.
> >
> > So, the registrant asks for a /24 and a year later his replacement who
> > is a better network engineer figures out he really needs a /22 after
> > all. What's the impact? Other than insisting on giving him a /22 up
> > front, is there another way to mitigate that impact?
> >
> > 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.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/451875f8/attachment.bin>

From dlw+arin at tellme.com  Tue Jul 28 13:10:26 2009
From: dlw+arin at tellme.com (David Williamson)
Date: Tue, 28 Jul 2009 10:10:26 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
References: <3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
Message-ID: <20090728171026.GU4935@shell02.cell.sv2.tellme.com>

Why not?  I've thought of writing a proposal that does exactly that.
The routability of the block isn't nearly as interesting as good
stewardship of the available space.  If all you need is a /26, why get
a /24 (or, under current rules, a /22)?  Sure, it may not be trivially
routable today, but that's a limitation of the routing system, not an
excuse to burn space.

At some point, the routing system will need to have a way to identify
the value of a route.  Suppore, hypothetically, windowsupdate.com lived
behind a VIP that is advertised as a /28.  Would you route it?  Of
course!  If you didn't, a competitor would, and every one of your
customers with a Windows box (i.e., most of them) would leave.  Would
you route the /28 for joesautobody.com?  Probably not.  How do you identify
the routes you find valuable and are willing to burn a routing slot for?
Well, that's the trick...no easy answers to that one.

The current /24 "limit" is an artifact of the current situation.  The
limit has been different in the past.  As recently as 5 years ago, it
was /22 for some major providers.  It'll slide to /25 at some point.
Let's not enshrine that in policy, except perhaps as a stepping stone
to the no-limit world.

-David


On Tue, Jul 28, 2009 at 12:34:55PM -0400, Steven E. Petty wrote:
> 
>   Obviously the primary reason for a limit is the accepted minimum routing entry size of a /24.  Of course, you knew that.  So why ask the question?
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Tuesday, July 28, 2009 12:30 PM
> To: William Herrin; Joel Jaeggli
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Based on what everyone is saying about the /24 issue - and for the purpose of argument accepting that /24 will cause no problems - then why not take it a step further and remove any maximum length netmask restriction for a multi-homed entity with a single allocation.
> 
> One entity with one allocation will generate one table entry regardless of what size it is, so why limit them to a /24.  I am sure there are entities out there who could operate just fine out of a /25 or even a /32, and so long as they are not creating gratuitous route table entries then we could be more efficient allowing them to only consume the space they need.
> 
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of William Herrin
> > Sent: Tuesday, July 28, 2009 10:30 AM
> > To: Joel Jaeggli
> > Cc: ARIN PPML
> > Subject: Re: [arin-ppml] Rationale for /22
> >
> > On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > > William Herrin wrote:
> > >> Given the shortage of IPv4 addresses, why structure the policies so
> > >> that we give anyone more than they actually want?
> > >
> > > The minimum number of addresses that can be used may not in fact
> > > reflect the minimum that should be used.
> > >
> > >        For the purposes of minimizing fragmention.
> > >
> > >        Supporting basic network operation (it's nice when traceroute
> > >        and pmtud work) because your intermediate routers are privately
> > >        numbered.
> > >
> > >        Limiting the consequences of imagination failure, which may
> > >        sound flippant but renumbering, requesting an additional block,
> > >        or and point one and two are good reasons to make a potential
> > >        multi-homer justify the assignment of a block of the appropriate
> > >        size for that activity.
> >
> > Hi Joel,
> >
> > I could almost see that argument on the ISP side but it doesn't make
> > sense to me on the end-user side, particularly when they may be
> > trivially multihomed. I surely wouldn't want to presume that I know
> > every registrant's address count needs better than he does though. f
> > you don't mind, let's just focus on the downside risk.
> >
> > So, the registrant asks for a /24 and a year later his replacement who
> > is a better network engineer figures out he really needs a /22 after
> > all. What's the impact? Other than insisting on giving him a /22 up
> > front, is there another way to mitigate that impact?
> >
> > 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.
> _______________________________________________
> 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 dlw+arin at tellme.com  Tue Jul 28 13:17:04 2009
From: dlw+arin at tellme.com (David Williamson)
Date: Tue, 28 Jul 2009 10:17:04 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F2F7D.7040601@ipinc.net>
References: <3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<4A6F2F7D.7040601@ipinc.net>
Message-ID: <20090728171703.GW4935@shell02.cell.sv2.tellme.com>

On Tue, Jul 28, 2009 at 10:03:57AM -0700, Ted Mittelstaedt wrote:
> If you set the minimum size of a table entry to /25 instead of /24 then
> you have now doubled the possible table entries.  It doesn't matter if 
> the entries are gratuitous or not, the way subnet mathematics works, for
> every drop in the bit boundary, from /25 to /26 to /27 and so on, you
> double, quadruple, etc. the total possible route entries.
> 
> With the increase in router ram and router CPU speed over the years, 
> some decrease in the minimum is warranted.  If we didn't have IPv6 
> coming up - which will also double the number of advertisements once
> everyone runs dual-stack - we could support an even further decrease
> in the minimum.  But we can't yet support multiplying the number of
> potential routing slots by 200 on the Internet.

I find your math to be odd.  Yes, there are twice as many /25s possible
as there are /24s, but moving the filter by one bit doesn't immediately
blow up the routing table - very few networks are fully deaggregated.
(And those that are need to be fixed, in my opinion.)  I suspect that
accepting /25s will increase the rate of growth by a bit, but not
radically so.

Also, the ratio of v4 announcements to v6 at steady state better not be
1:1.  We're attempting to be much smarter at handing out v6 space, so
there should be many fewer routes at steady state in v6.  Of course,
they'll consume 4x the memory, so were still a bit screwed, but not as
badly as your math implies.

-David


From kkargel at polartel.com  Tue Jul 28 13:27:11 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 12:27:11 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F2F7D.7040601@ipinc.net>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<4A6F2F7D.7040601@ipinc.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD7@mail>

Ted,
> 
> If you set the minimum size of a table entry to /25 instead of /24 then
> you have now doubled the possible table entries.  It doesn't matter if
> the entries are gratuitous or not, the way subnet mathematics works, for
> every drop in the bit boundary, from /25 to /26 to /27 and so on, you
> double, quadruple, etc. the total possible route entries.
> 
> With the increase in router ram and router CPU speed over the years,
> some decrease in the minimum is warranted.  If we didn't have IPv6
> coming up - which will also double the number of advertisements once
> everyone runs dual-stack - we could support an even further decrease
> in the minimum.  But we can't yet support multiplying the number of
> potential routing slots by 200 on the Internet.
> 
> Ted

So are you saying then that we need to limit the number of organizations
that have IP allocations to manage the number of slots?  
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/d61b49b5/attachment.bin>

From cgrundemann at gmail.com  Tue Jul 28 13:32:43 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Jul 2009 11:32:43 -0600
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
Message-ID: <443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>

On Tue, Jul 28, 2009 at 11:02, Kevin Kargel<kkargel at polartel.com> wrote:
>>
>> ? Obviously the primary reason for a limit is the accepted minimum routing
>> entry size of a /24. ?Of course, you knew that. ?So why ask the question?
>
> Perhaps it is time to examine the 'accepted minimum routing entry size'. ?If
> it won't cause problems then why not extend the mask size? ?Or are you
> saying that long mask route entries do in fact cause problems?

I don't think that anyone said lowering the minimum routing entry size
would not cause problems.  I am fairly certain that everyone agrees
that <rapid> route table expansion is a potential problem (primarily
caused by long route entries due to de-aggregation) and that we need
to continue to help ensure that the route table does not grow
explosively.

The distinction that I (and I believe others) make is between the
source of a given Org's space and the addition of entries in the
table.

AFAIK, there are no ISPs allowing customers to multihome with less
than a /24 currently but many who are allowing those /24s.  So if that
Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
entry in the table.  And when that Org needs another /24 (and the ISP
did not reserve the adjacent one and the customer does not want to
renumber) and the ISP hands it another one, or ARIN hands it another
one, there are the same two entries.  There are two main differences
here though:
1) If ARIN policy requires that any Org with a /24 that wants more
space be required to return the original /24, then we end up with one
/23 instead of two /24s in the table.  This is more likely to happen
than most ISPs requiring renumbering because of all those pesky sales
teams and account managers...
2) If ARIN is giving space to a greater portion of all multihomers,
then ISPs have less excuses not to better aggregate their own space.
Load balancing should never require de-aggregation down to /24s.

Unless you stop allowing Orgs to multihome with less than a /22, there
will be longer entries in the table.  Perhaps we could actually slow
routing table growth by allowing them to get there space from ARIN
(since they will be getting and announcing it anyway)?  Or do you
think that getting space from ARIN will be so much easier than getting
it from an ISP that Orgs will flock to /24s and cause more growth in
the table than we currently see?

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

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From kkargel at polartel.com  Tue Jul 28 13:46:15 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 12:46:15 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>

> AFAIK, there are no ISPs allowing customers to multihome with less
> than a /24 currently but many who are allowing those /24s.  So if that
> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
> entry in the table.  

This is incorrect.  If the Org gets a /24 from it's upstream ISP there is
the same entry in the routing table.  If the Org gets a discontiguous /24
from ARIN there is an additional entry in the routing table.  

What it boils down to is whether or not the Org's ISP can aggregate the
netblock.



And when that Org needs another /24 (and the ISP
> did not reserve the adjacent one and the customer does not want to
> renumber) and the ISP hands it another one, or ARIN hands it another
> one, there are the same two entries.  There are two main differences
> here though:
> 1) If ARIN policy requires that any Org with a /24 that wants more
> space be required to return the original /24, then we end up with one
> /23 instead of two /24s in the table.  This is more likely to happen
> than most ISPs requiring renumbering because of all those pesky sales
> teams and account managers...
> 2) If ARIN is giving space to a greater portion of all multihomers,
> then ISPs have less excuses not to better aggregate their own space.
> Load balancing should never require de-aggregation down to /24s.

But if ARIN is handing out the /24's instead of the ISP isn't the likelihood
far greater that the /24's will not be agregable?  I doubt that ARIN will be
able to only hand out /24's that would be.

> 
> Unless you stop allowing Orgs to multihome with less than a /22, there
> will be longer entries in the table.  Perhaps we could actually slow
> routing table growth by allowing them to get there space from ARIN
> (since they will be getting and announcing it anyway)?  Or do you
> think that getting space from ARIN will be so much easier than getting
> it from an ISP that Orgs will flock to /24s and cause more growth in
> the table than we currently see?

It is not an issue of ease, the issue is portability.  Orgs want portable
space so that they can avoid renumbering and be provider independant.

I have no problem with extending the minimum mask length so long as it is
tied hard to a requirement that anyone with a long mask have only one
allocation, and to get another allocation the long mask netblock must either
be aggregated in to the new allocation or returned.


> 
> ~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.
> >
> 
> --
> Chris Grundemann
> weblog.chrisgrundemann.com
> www.twitter.com/chrisgrundemann
> www.coisoc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/fac6a272/attachment.bin>

From farmer at umn.edu  Tue Jul 28 13:46:45 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 28 Jul 2009 12:46:45 -0500
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <4A6DF093.7040203@ipinc.net>
References: <4A6DBB23.5040605@arin.net>,
	<4A6D9721.10299.EA687FC@farmer.umn.edu>,
	<4A6DF093.7040203@ipinc.net>
Message-ID: <4A6EF335.26227.13F6429F@farmer.umn.edu>

On 27 Jul 2009 Ted Mittelstaedt wrote:

> David Farmer wrote:
>
...

> I was intending the last /8 of IANA-assigned.

That was my impression, but I wasn't 100% sure.

> > Maybe a better way is to provide specific CIDR-based threshold triggers 
> > rather than percentages anyway.  Maybe say the last /11 instead of 90% 
> > (87.5% of a /8), /12 instead of 95% (93.75% of a /8), and /13 instead of 97% 
> > (96.875% of a /8). This way you probablly don't need to explicitly say start 
> > with the last /8.
> > 
> 
> Yes, this probably is a much better way to do it.  Question for you, 
> what do you think of the curve?  Do you think the percentages, or
> CIDR-equivalents of the last /8 are good?

I think they are OK, there is always a little arbitrariness to these 
things.

....

> > How would you envision this working with other policy proposals?  Such as 
> > 93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run 
> > Out by Allocation Window. 
> 
> I think both of those proposals will suffer the same fate as
> 2007-05-02, "IPv4 Soft Landing"
> 
> Unless my read of the ARIN participatory membership is incorrect,
> people are generally opposed to trying to keep chewing the
> gum once all the flavor is gone.

Actually I've been trying very hard not to limit or preserve IPv4 
at all.  I'm mostly tring to make it so most groups run out about 
the same time, within 3 months or so and try to make sure that 
the last bits of address space get spread out among multiple 
groups.  

I agree with not wanting to do anything to really preserve IPv4, 
but some really nasty things can happen in the Internet market 
place if we don't think about how we Run-Out of IPv4. 

I don't want to or even think we can prevent Run-Out, but I do 
want some order to the Run-Out.

Since you brought up Soft-Landing, I'll use an airplane 
analogy, we are going to crash, not a hard landing, a real 
honest to goodness crash.  But, do we want to auger in, or try 
for a belly landing on the water.  Will we be United 93 on 9/11 
in Pennsylvania  or USAir 1549 last January on the Hudson 
River in New York?

So we are going to crash I just want it to be one that most of us 
will walk a way from.

> There's not a lot of point to making the IPv4 requesting
> criteria so stringent that practically nobody can get an
> allocation.  It reminds me of North Korea's 4 authorized "Christian"
> churches that are attended by nobody, and do nothing, but allow
> the regime to claim they are tolerant.
> 
> Sure, if you make criteria for IPv4 so tough that nobody can
> meet it, you can claim that ARIN hasn't run out of IPv4 yet
> for the next 3-4 decades.

I agree, I just want to bring a little order to the event.

>  > Would you do this instead of one or both of those
> > or would you do this and one or both of those too?
> 
> I'm generally opposed to both of those proposals but my gut
> feel is they will be shot down anyway so I don't really feel
> "threatened" by them, nor do I really even bother to think
> about them.  When I came up with
> this proposal I wasn't viewing it as an "opposition" proposal
> to those proposals.
> 
> I can see, though, how someone might consider this to be diametrically
> opposed to those proposals.  I'm suggesting we make it easier to get 
> IPv4 at the last minute - those proposals are making it harder.

I'm not sure it is incompatable with the other two proposals or 
even my goals for them.  I was just try to get your view.

> But this depends on how you view IPv4 runout.  I view IPv4 runout
> as a fundamental fact, no amount of wriggling on the hook is
> going to get the worm off, it's gonna happen no matter how much
> IPv4 we dig out of the archives.
> 
> Others who may view IPv4 runout as something that we actually have
> control over, and can manipulate, would probably feel that a
> proposal like mine undercuts the entire IPv4 addressing scheme.
> 
> If people who are actively opposing those proposals want to use
> this proposal as a hill to rally behind, I don't care one way or
> the other.  It wasn't intended as such, however.
> 
> Where I'm coming from is simple - we all know that there's small
> fry out there, we all know that some of those small fry are gonna
> get stomped hard by IPv4 runout, and since the small fry definitely
> didn't cause IPv4 runout, I just felt it was kind of unfair to allow
> that to happen without throwing them a lifeline.  After all it's
> not like it would really be a lot of skin off our collective nose
> to do this for them for a few years, and it would mean a great
> deal of difference to many of them.

I think your general idea is a good one, it just need work on the 
details.  It is dealing with the one of the parameters I didn't 
touch, minimum allocation size.  But in my "Predictable IPv4 
Run Out by Allocation Window" proposal, I did allow for the 
idea we might change the minimum allocation size.  And I think 
it might be a good idea, but probablly not until the last /8 is 
received.
 
> Ted



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



From scottleibrand at gmail.com  Tue Jul 28 13:50:25 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 28 Jul 2009 10:50:25 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com>	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
Message-ID: <4A6F3A61.1000201@gmail.com>

Kevin Kargel wrote:
>> AFAIK, there are no ISPs allowing customers to multihome with less
>> than a /24 currently but many who are allowing those /24s.  So if that
>> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
>> entry in the table.  
>>     
>
> This is incorrect.  If the Org gets a /24 from it's upstream ISP there is
> the same entry in the routing table.  If the Org gets a discontiguous /24
> from ARIN there is an additional entry in the routing table.  
>
> What it boils down to is whether or not the Org's ISP can aggregate the
> netblock.
>   

No, we're talking about multihomed organizations here.  If my 
singly-homed customer gets a /24 from me (out of one of my /16s), then 
that doesn't add to the table (the only announcement is my /16).  If, 
however, a multihomed customer gets a /24 from me, they'll announce the 
/24 as well (both to me and to their other upstream), thereby adding an 
additional route to the global table (for anyone who doesn't filter 
/24s, which very few networks do today).

If the multihomed downstream customer gets their /24 from ARIN instead 
of from me (their upstream), then it still adds one route to the table.  
The only difference is that it can't be filtered without affecting 
reachability (for example, by someone with hardware that can only do 
256k routes).

-Scott


From farmer at umn.edu  Tue Jul 28 14:15:32 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 28 Jul 2009 13:15:32 -0500
Subject: [arin-ppml] Easy vs Hard (was Re: Policy Proposal: Last Minute
	Assistance for Small ISPs)
In-Reply-To: <4A6F2DE2.8070002@ipinc.net>
References: <443de7ad0907280942m3d198f8fj87f32658b36010a1@mail.gmail.com>,
	<4A6F2DE2.8070002@ipinc.net>
Message-ID: <4A6EF9F4.4390.14109E1F@farmer.umn.edu>

On 28 Jul 2009 Ted Mittelstaedt wrote:

> Chris Grundemann wrote:

....

> > I disagree that proposals 93 and 94 would make it harder to get IPv4.
> > 
> > They would allow Orgs to get less IPv4 at once; which I guess could be
> > stated as "making it harder for an Org to get large amounts of IPv4"
> > or even "harder for an Org to get the desired amount of IPv4" but that
> > in turn will make it easier (read: possible) for other Orgs to get
> > some IPv4 (vs none).
> > 
> > Neither of those proposals make the requirements any more strict -
> > which is how I would define "making it harder."
> > 
> 
> I wasn't speaking about "more difficult" on an individual org level, but
> rather a community level.  It would have been more accurate to say:
> 
> "I'm suggesting we make increase the rate at which IPv4 is allocated at 
> the last minute - those proposals are suggesting we decrease the rate at 
> which IPv4 is allocated at the last minute."

I'm really only intending to ensure that we don't increase the rate by give it all 
to one or a small number of groups in big chunks.   I want to make sure it is 
spread around, giving it out in even smaller chunks to more groups is 
completely compatible with my objectives.  I just want to make sure that it 
goes to as many groups as possible and that no one ends up with a 
competitive advantage for more than a couple months because of IPv4 Run-
Out.  Reducing the minimum allocation actually help with the last part too, 
because a /20 may be a year or two of allocations for some of the small 
guys.

I believe that reducing the allocation window and making sure that no one 
gets more than 25% of what ever ARIN has in a single allocation prevent 
some really nasty possible effects of Run-Out.  I also completely support 
reducing the minimum allocation size at the end too.

As I say at the end of the Rationale for "93. Predicable IPv4 Run Out by 
Prefix Size ";

"Finally, combining the 3 month period with the one quarter
(1/4) ratio provides roughly an annualized equivalent of the
whole ARIN free pool being made available to a single
organization.  While it is not possible for a single organization
to receive the whole ARIN free pool within one year under this
policy, it is a virtual certainty that multiple organization will be
requesting resources, and that the ARIN free pool will not likely
last a full year following the exhaustion of the IANA free pool
anyway.  Therefore, the ratio one quarter (1/4) seems to strike
a balance between making resources available with as little
restriction as possible and ensuring an equitable distribution of
those resources during and following the run-out phase."

> So as I said I do see how someone could view the 2 proposals as in
> opposition to each other.

 
> Ted



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



From tedm at ipinc.net  Tue Jul 28 14:25:19 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 11:25:19 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD7@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<4A6F2F7D.7040601@ipinc.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD7@mail>
Message-ID: <4A6F428F.8010909@ipinc.net>

Kevin Kargel wrote:
> Ted,
>> If you set the minimum size of a table entry to /25 instead of /24 then
>> you have now doubled the possible table entries.  It doesn't matter if
>> the entries are gratuitous or not, the way subnet mathematics works, for
>> every drop in the bit boundary, from /25 to /26 to /27 and so on, you
>> double, quadruple, etc. the total possible route entries.
>>
>> With the increase in router ram and router CPU speed over the years,
>> some decrease in the minimum is warranted.  If we didn't have IPv6
>> coming up - which will also double the number of advertisements once
>> everyone runs dual-stack - we could support an even further decrease
>> in the minimum.  But we can't yet support multiplying the number of
>> potential routing slots by 200 on the Internet.
>>
>> Ted
> 
> So are you saying then that we need to limit the number of organizations
> that have IP allocations to manage the number of slots?  
>  

This is a fallacious argument.  You are implying that limiting the 
number of ARIN-supplied IP allocations will limit the number of routing
slots.  In actual fact, an org can use up a routing slot by advertising
LIR-provided IP assignments.

I don't deny we should limit the number of slots but this is only
loosely related to the number of orgs that have IP allocations.

RIR policy has been to discourage growth of routing slots, but the
RIR cannot prevent this from happening.  Even if the RIR stops handing
out AS numbers, an org with an existing subnet can break it into
multiple advertisements if they choose which also increases slots.

Ted




From tedm at ipinc.net  Tue Jul 28 14:31:28 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 11:31:28 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com>	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
Message-ID: <4A6F4400.7060408@ipinc.net>

Chris Grundemann wrote:
> On Tue, Jul 28, 2009 at 11:02, Kevin Kargel<kkargel at polartel.com> wrote:
>>>   Obviously the primary reason for a limit is the accepted minimum routing
>>> entry size of a /24.  Of course, you knew that.  So why ask the question?
>> Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
>> it won't cause problems then why not extend the mask size?  Or are you
>> saying that long mask route entries do in fact cause problems?
> 
> I don't think that anyone said lowering the minimum routing entry size
> would not cause problems.  I am fairly certain that everyone agrees
> that <rapid> route table expansion is a potential problem (primarily
> caused by long route entries due to de-aggregation) and that we need
> to continue to help ensure that the route table does not grow
> explosively.
> 
> The distinction that I (and I believe others) make is between the
> source of a given Org's space and the addition of entries in the
> table.
> 
> AFAIK, there are no ISPs allowing customers to multihome with less
> than a /24 currently but many who are allowing those /24s.  So if that
> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
> entry in the table.  And when that Org needs another /24 (and the ISP
> did not reserve the adjacent one and the customer does not want to
> renumber) and the ISP hands it another one, or ARIN hands it another
> one, there are the same two entries.  There are two main differences
> here though:
> 1) If ARIN policy requires that any Org with a /24 that wants more
> space be required to return the original /24, then we end up with one
> /23 instead of two /24s in the table.  This is more likely to happen
> than most ISPs requiring renumbering because of all those pesky sales
> teams and account managers...
> 2) If ARIN is giving space to a greater portion of all multihomers,
> then ISPs have less excuses not to better aggregate their own space.
> Load balancing should never require de-aggregation down to /24s.
> 
> Unless you stop allowing Orgs to multihome with less than a /22, there
> will be longer entries in the table.  Perhaps we could actually slow
> routing table growth by allowing them to get there space from ARIN
> (since they will be getting and announcing it anyway)   Or do you
> think that getting space from ARIN will be so much easier than getting
> it from an ISP that Orgs will flock to /24s and cause more growth in
> the table than we currently see?
> 

If they get their /24 from an ISP and advertise it, that likley will be 
part of a supernet that that ISP is advertising so if I want to filter
to the /23 level I won't be blocking off reachability for myself - since
presumably the LIR will know how to reach it's own customers.

But if they go directly to ARIN and get their /24 then I'm going to have
to filter at /24 boundary.

Ted


From jlewis at lewis.org  Tue Jul 28 14:09:30 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 28 Jul 2009 14:09:30 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F3A61.1000201@gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<4A6F3A61.1000201@gmail.com>
Message-ID: <Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>

On Tue, 28 Jul 2009, Scott Leibrand wrote:

> No, we're talking about multihomed organizations here.  If my singly-homed 
> customer gets a /24 from me (out of one of my /16s), then that doesn't add to 
> the table (the only announcement is my /16).  If, however, a multihomed 
> customer gets a /24 from me, they'll announce the /24 as well (both to me and 
> to their other upstream), thereby adding an additional route to the global 
> table (for anyone who doesn't filter /24s, which very few networks do today).
>
> If the multihomed downstream customer gets their /24 from ARIN instead of 
> from me (their upstream), then it still adds one route to the table.  The 
> only difference is that it can't be filtered without affecting reachability 
> (for example, by someone with hardware that can only do 256k routes).

The distinction some people may not be getting is that if I know ARIN 
allocates from a /8 nothing longer than /20s, then if I'm running out of 
routing slots, I can use a prefix-list to ignore anything /21 (or maybe 
/22) or longer from that /8.  If ARIN allocates /24s from a /8 or probably 
longer net, then I need to accept those /24s.  That's the theory anyway.

Having looked into this some time ago while using Sup2's for BGP, I know 
the unfortunate reality is, even in /8s where there is a RIR published 
minimum allocation size, you'll find clue-deprived networks deaggregating 
their allocations and not announcing the aggregates.  If you filter on RIR 
allocation minimums (even with a bit or two of padding) and don't point 
default at a network that doesn't filter similarly, you're going to have 
reachability issues.

Doesn't this nullify the first point?  i.e. ARIN shouldn't allocate /24s, 
because we want people to be able to filter on RIR allocation minimums 
without losing reachability.  We already know that doesn't work without 
default routing.

What other real world reason is there for not lowering the bar to /24?

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


From tedm at ipinc.net  Tue Jul 28 14:51:34 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 11:51:34 -0700
Subject: [arin-ppml] Easy vs Hard (was Re: Policy Proposal: Last Minute
 Assistance for Small ISPs)
In-Reply-To: <4A6EF9F4.4390.14109E1F@farmer.umn.edu>
References: <443de7ad0907280942m3d198f8fj87f32658b36010a1@mail.gmail.com>,
	<4A6F2DE2.8070002@ipinc.net>
	<4A6EF9F4.4390.14109E1F@farmer.umn.edu>
Message-ID: <4A6F48B6.7040506@ipinc.net>

David Farmer wrote:
> On 28 Jul 2009 Ted Mittelstaedt wrote:
> 
>> Chris Grundemann wrote:
> 
> ....
> 
>>> I disagree that proposals 93 and 94 would make it harder to get IPv4.
>>>
>>> They would allow Orgs to get less IPv4 at once; which I guess could be
>>> stated as "making it harder for an Org to get large amounts of IPv4"
>>> or even "harder for an Org to get the desired amount of IPv4" but that
>>> in turn will make it easier (read: possible) for other Orgs to get
>>> some IPv4 (vs none).
>>>
>>> Neither of those proposals make the requirements any more strict -
>>> which is how I would define "making it harder."
>>>
>> I wasn't speaking about "more difficult" on an individual org level, but
>> rather a community level.  It would have been more accurate to say:
>>
>> "I'm suggesting we make increase the rate at which IPv4 is allocated at 
>> the last minute - those proposals are suggesting we decrease the rate at 
>> which IPv4 is allocated at the last minute."
> 
> I'm really only intending to ensure that we don't increase the rate by give it all 
> to one or a small number of groups in big chunks.   I want to make sure it is 
> spread around, giving it out in even smaller chunks to more groups is 
> completely compatible with my objectives.  I just want to make sure that it 
> goes to as many groups as possible and that no one ends up with a 
> competitive advantage for more than a couple months because of IPv4 Run-
> Out.

If there was a way we could make it all run out at the same time for
everyone that would definitely be the fairest situation possible.

Unfortunately, that's not how it's going to happen.  All you really
can do here is juggle things around at the RIR so that when the day
comes that they run out, they run out evenly for ALL sizes of requests -
not that they run out of, say /12-sized blocks but still have plenty
of /21 sized blocks left.  In short, you can make it fair for all of
the requests in the pipeline at the RIR to all fail at the same time.

But in the world it definitely won't be fair.  The orgs that come out
ahead are the orgs who have inefficient utilization of assigned blocks
and are able to retrieve those from customers.  For example someone
alleged on the list a few months ago that one of the cable ISP's was
handing out /29's via PPP to CPE NAT/routers - all perfectly legitimate
under the rules - but with a few tweaks in their router and now all 
their customers are getting a /32 the next time their
CPE disconnects and reconnects and the cable ISP has instantly
generated many 5 times more IPv4 than they had.

Assuming that every ISP out there has been hedging somewhat along these
lines, the advantage will go to the ISPs who have large amounts of IPv4
already allocated to themselves.

Ted


From kkargel at polartel.com  Tue Jul 28 14:53:29 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 28 Jul 2009 13:53:29 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com><3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail><402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail><443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail><4A6F3A61.1000201@gmail.com>
	<Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DDF@mail>

> 
> Doesn't this nullify the first point?  i.e. ARIN shouldn't allocate /24s,
> because we want people to be able to filter on RIR allocation minimums
> without losing reachability.  We already know that doesn't work without
> default routing.
> 
> What other real world reason is there for not lowering the bar to /24?
> 
> ----------------------------------------------------------------------
>   Jon Lewis                   |  I route
>   Senior Network Engineer     |  therefore you are
>   Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________

Of course all this is almost moot as ARIN isn't supposed to write routing
policy.  ARIN can write allocation policy and the routing world can do what
they will with it.  

Just because ARIN may allocate a /24 doesn't mean the world has to route it.
Even were a /24 not globally routable there may be perfectly valuable
reasons why an Org may want a globally unique albeit globally unrouteable
netblock.  PeerOrg to PeerOrg routing comes to mind as one scenario.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/dae413b9/attachment.bin>

From tedm at ipinc.net  Tue Jul 28 15:10:37 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Jul 2009 12:10:37 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>	<4A6EBA3D.8020800@bogus.com>	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>	<4A6F0C18.1000107@bogus.com>	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>	<4A6F3A61.1000201@gmail.com>
	<Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>
Message-ID: <4A6F4D2D.80902@ipinc.net>

Jon Lewis wrote:
> On Tue, 28 Jul 2009, Scott Leibrand wrote:
> 
>> No, we're talking about multihomed organizations here.  If my 
>> singly-homed customer gets a /24 from me (out of one of my /16s), then 
>> that doesn't add to the table (the only announcement is my /16).  If, 
>> however, a multihomed customer gets a /24 from me, they'll announce 
>> the /24 as well (both to me and to their other upstream), thereby 
>> adding an additional route to the global table (for anyone who doesn't 
>> filter /24s, which very few networks do today).
>>
>> If the multihomed downstream customer gets their /24 from ARIN instead 
>> of from me (their upstream), then it still adds one route to the 
>> table.  The only difference is that it can't be filtered without 
>> affecting reachability (for example, by someone with hardware that can 
>> only do 256k routes).
> 
> The distinction some people may not be getting is that if I know ARIN 
> allocates from a /8 nothing longer than /20s, then if I'm running out of 
> routing slots, I can use a prefix-list to ignore anything /21 (or maybe 
> /22) or longer from that /8.  If ARIN allocates /24s from a /8 or 
> probably longer net, then I need to accept those /24s.  That's the 
> theory anyway.
> 
> Having looked into this some time ago while using Sup2's for BGP, I know 
> the unfortunate reality is, even in /8s where there is a RIR published 
> minimum allocation size, you'll find clue-deprived networks 
> deaggregating their allocations and not announcing the aggregates.  If 
> you filter on RIR allocation minimums (even with a bit or two of 
> padding) and don't point default at a network that doesn't filter 
> similarly, you're going to have reachability issues.
> 
> Doesn't this nullify the first point?  i.e. ARIN shouldn't allocate 
> /24s, because we want people to be able to filter on RIR allocation 
> minimums without losing reachability.  We already know that doesn't work 
> without default routing.
> 
> What other real world reason is there for not lowering the bar to /24?
> 

The same reason that the highways are posted 55Mph but the cops only
pull you over if your doing 65 or above.

NRPM currently lists /23 as the minimum under section 4.2.2.2  (ie:
multihomed orgs have to demonstrate efficient utilization of an
upstream /23 and how are you going to do that if your multihomed
and you don't advertise a /23?) and they even stretch it to /24
with the wishy-washy "demonstrate the efficient utilization of a minimum 
contiguous or noncontiguous /23 (two /24s) from an upstream."  The
implication is a small ISP can have 2 discontiguous /24's in
production use - but ARIN doesn't itself assign /24's for this
so they are basically in the position the highway cop is.  In
other words the speed limit says /20 (section 4.3.2.1) but they will 
ignore the fact your running at /24 speed.

Then there's more of this in section 4.4 where they assign /24's with
the statement "including public exchange points, core DNS service 
providers" well how are you gonna have a "core DNS service provider"
on a /24 that's not fully reachable?

In other words the implication in the NRPM is that only "special"
people like critical infrastructure providers, or people who are
in the process of obtaining their "reserved" /22's are expected to
be running below /20 in size.  The rest of the normal Internet isn't
supposed to be using anything smaller than a /20

So, ISP's who filter set their boundary at /24 because it's a few
bits off /20, to allow themselves a bit of wiggle room

If you change it so that the bar is lowered to /24 then ISPs that
filter will have to reduce down to /26 to be absolutely sure that
they catch those clueless out there who get their /24 and subnet it
into /25's or /26's and advertise those.

Ted


From jlewis at lewis.org  Tue Jul 28 15:20:25 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 28 Jul 2009 15:20:25 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6F4D2D.80902@ipinc.net>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<4A6F3A61.1000201@gmail.com>
	<Pine.LNX.4.61.0907281353520.4187@soloth.lewis.org>
	<4A6F4D2D.80902@ipinc.net>
Message-ID: <Pine.LNX.4.61.0907281514420.4187@soloth.lewis.org>

On Tue, 28 Jul 2009, Ted Mittelstaedt wrote:

> So, ISP's who filter set their boundary at /24 because it's a few
> bits off /20, to allow themselves a bit of wiggle room
>
> If you change it so that the bar is lowered to /24 then ISPs that
> filter will have to reduce down to /26 to be absolutely sure that
> they catch those clueless out there who get their /24 and subnet it
> into /25's or /26's and advertise those.

So many networks already filter with /24 being the cutoff that I think 
it'd be really hard for anyone to get full reachability announcing longer 
networks...even if ARIN were to make /24 the minimum regular allocation.

I don't buy the argument that ARIN handing out /24s will force me to 
accept /25's from the internet.  People get away with their TE or CF 
(Clue Free) deaggregation today because /24 somehow became accepted as the 
longest prefix acceptable to those who filter at all on prefix length. 
Those filters aren't going to change overnight...if at all, especially to 
allow longer than RIR minimums.

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


From farmer at umn.edu  Tue Jul 28 15:50:31 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 28 Jul 2009 14:50:31 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <443de7ad0907280921t5c09be31g47e87a86b33a227@mail.gmail.com>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>,
	<443de7ad0907280826p57dab71amc8252d50ff39058c@mail.gmail.com>,
	<443de7ad0907280921t5c09be31g47e87a86b33a227@mail.gmail.com>
Message-ID: <4A6F1037.28208.146790F8@farmer.umn.edu>

On 28 Jul 2009 Chris Grundemann wrote:

> On Tue, Jul 28, 2009 at 09:26, Chris Grundemann<cgrundemann at gmail.com> wrote:
> > On Mon, Jul 27, 2009 at 17:37, David Farmer<farmer at umn.edu> wrote:
....
> >> How about something like this;
> >>
> >> IANA pool down to X /8s, triggers 9 month allocation window
> >> IANA pool down to Y /8s, triggers 6 month allocation window
> >> IANA pool down to Z /8s, triggers 3 month allocation window
> >> ARIN gets last /8, triggers maximum allocation of up to one quarter of ARIN
> >> free pool per allocation.
> >
> > Yes, this is exactly what my intention was.
> >
> >> Maybe with X=25, Y=15, ?Z=10, but I need think about the numbers more.
> >
> > Some facts to help the discussion (correct me if I am wrong):
> >
> > There are currently 30 /8s Unallocated by IANA.
> > So far 4 /8s have been allocated this year.
> > In 2008 IANA allocated 9 /8s.
> > In 2007 IANA allocated 13 /8s. [1]
> >
> > There have been an average of 207 /24s requested from ARIN per month
> > this year. [2]
> > The average for 2008 was 200 /24s per month.
> > The average for 2007 was 197 /24s per month. [3]
> >
> > So if we make things simple for ourselves we could say that 10 /8s
> > will last about a year and that ARIN hands out about 10 /16s in that
> > year. ?These numbers are admittedly fuzzy and of course become even
> > less absolute once we get closer to free pool exhaustion and start
> > playing with the allocations but I think they work ok for my purposes
> > here, at least for the moment.
> >
> >
> > The original text set the policy to start limiting the allocation
> > window a year from now, I think that is reasonable and if we want to
> > stick close to that, I think X=20.
> >
> > Then, imo, we should stagger into the next two reductions,
> > incrementally shortening the time that we keep each subsequent
> > allocation window. ?So perhaps Y=12 (leaving us at a 9 month window
> > for 8 /8s) and Z=6 (keeping the 6 month window for 6 /8s) and then
> > trigger the maximum allocation at 1 /8 (having maintained a 3 month
> > window for 5 /8s).
> 
> I forgot to account for the End Policy; when IANA reaches 5 /8s
> unallocated, we will drop to zero.  Allowing for that, maybe a better
> set is: X=20, Y=15 and Z=10.  Or perhaps we should take less steps and
> go from a 12 month window to 6 and then to the 1/4 maximum.
 
How about we skip the 9 month window.  Go to 6 month 
window at 20 /8s and 3 month window at 10 /8s.  I think we 
need to get down to a 3 month window several months, at least 
3 or 4 months, before we get down to the last /8.  As you noted 
the End policy will basically take us from 6 or 7 /8s to 0.
.....

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



From owen at delong.com  Tue Jul 28 17:39:15 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Jul 2009 14:39:15 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
Message-ID: <CA708F0B-FE16-463C-BA7A-BDFFF3CC91BD@delong.com>


On Jul 28, 2009, at 10:46 AM, Kevin Kargel wrote:

>> AFAIK, there are no ISPs allowing customers to multihome with less
>> than a /24 currently but many who are allowing those /24s.  So if  
>> that
>> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
>> entry in the table.
>
> This is incorrect.  If the Org gets a /24 from it's upstream ISP  
> there is
> the same entry in the routing table.  If the Org gets a  
> discontiguous /24
> from ARIN there is an additional entry in the routing table.
>
> What it boils down to is whether or not the Org's ISP can aggregate  
> the
> netblock.
>
If an ORG multihomes with a /24 from their ISP, then, that /24 will  
appear
in the routing table either from the second transit provider, or, from
both transit providers, depending on configuration.

If an ORG multihomes with a /24 from ARIN, then, the /24 from ARIN will
appear in the routing table from both transit providers.

Otherwise, there is no difference to the routing table for a  
multihomed /24.
>
>
> But if ARIN is handing out the /24's instead of the ISP isn't the  
> likelihood
> far greater that the /24's will not be agregable?  I doubt that ARIN  
> will be
> able to only hand out /24's that would be.
>
The likelihood of the next /24 being aggregable is low regardless.

>
> I have no problem with extending the minimum mask length so long as  
> it is
> tied hard to a requirement that anyone with a long mask have only one
> allocation, and to get another allocation the long mask netblock  
> must either
> be aggregated in to the new allocation or returned.
>
So how about a policy like:


1.	Amend current policy to extend mutihoming to /24 instead of /22 for  
end users.

2.	Add the following phrase to policy:

	If an organization requesting additional space already possesses one  
or more
	ARIN assignments less than /22, ARIN will, if possible make available  
to the
	organization sufficient space to aggregate existing smaller blocks  
into the new
	space in addition to the justified additional space and shall allow a  
period
	of no less than 18 nor more than 36 months before reclaiming the  
previously
	assigned smaller blocks. If ARIN does not have a sufficiently large  
block, ARIN
	shall issue space in such a way as to alllow maximal aggregation  
possible
	and the return of as many addresses as possible after renumbering.

Owen

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

From michael.dillon at bt.com  Tue Jul 28 17:58:33 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Jul 2009 22:58:33 +0100
Subject: [arin-ppml] Policy Proposal: Last Minute Assistance for Small
	ISPs
In-Reply-To: <4A6F1867.1050501@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C497458025C54C0@E03MVZ2-UKDY.domain1.systemhost.net>

> It is pretty clear from posts on this list and elsewhere that 
> it is going to take a few years after ARIN assigns the last 
> IPv4 address for all major carriers to have native IPv6 
> offerings.  IPv4 is going to have to get scarce and expensive 
> before IPv6 becomes an issue for a lot of people.

Given that most major carriers already have IPv6 running in their
labs and have limited deployments with selected customers, I don't
see why you are so pessimistic. Like it or not, the large ISPs
see IPv6 deployment and IPv4 runout as being intertwined events
and that is why there will not be significant mass deployment
of IPv6 until at least the IANA runout event.

> I agree that if an ISP right now is not pressuring their 
> upstream for native IPv6 and that if their upstream isn't 
> natively running IPv6 that both of them are probably in the 
> "poorly run businesses with lazy managers" category.

There definitely should be some dialog between smaller ISPs
and their upstreams, not just nagging the poor sales rep who
can only sell what is in the official catalog. IPv6 deployment
is a once in a lifetime network transition that demands special
treatment, and that includes carriers providing a special IPv6
contact point for their customers which are also working on IPv6.

> I think that the ARIN community would like to see both PaBell 
> and Podunk to go to IPv6.

I think that the ARIN community doesn't care one way or the other.
Maybe Podunk is a market that can live with IPv4 long after IPv6
is the standard Internet protocol. We are not all-knowing and cannot
make that determination. Maybe Joe Hotshot college grad will launch
a new ISP in Michigan and wipe out the market share of both Podunk
ISP and PaBell.

> if Podunk seriously challenges PaBell by taking many 
> customers away from them, PaBell will merely react by raising 
> prices on the IPv4 they have assigned to Podunk, pushing them 
> out of business.

And opening a gap in the market for Joe Hotshot. Not to mention
antitrust lawsuits.

> Now, you can argue that PaBell could also do this by jacking 
> up connectivity rates.  But, they can't do this without 
> running afoul of restraint of trade unless they also jack up 
> connectivity rates for all their other customers at the same 
> time - which defeats the purpose since that won't cause 
> customers to migrate back to PaBell from Podunk.  That is why 
> PaBell would most likely choose to attack Podunk through fees 
> on IPv4.

A fee on IPv4 usage is a component of the connectivity rate and 
I doubt that anyone can avoid a restraint of trade lawsuit this way.

--Michael Dillon



From bill at herrin.us  Tue Jul 28 20:15:38 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jul 2009 20:15:38 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
Message-ID: <3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>

On Tue, Jul 28, 2009 at 1:46 PM, Kevin Kargel<kkargel at polartel.com> wrote:
>> AFAIK, there are no ISPs allowing customers to multihome with less
>> than a /24 currently but many who are allowing those /24s. ?So if that
>> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
>> entry in the table.
>
> This is incorrect. ?If the Org gets a /24 from it's upstream ISP there is
> the same entry in the routing table. ?If the Org gets a discontiguous /24
> from ARIN there is an additional entry in the routing table.

Kevin,

For the multihomed case we're discussing, this statement is in error.
In order to aggregate small routes into a larger route, two things
must be true:

1. The covered address space must be contiguous in a netmasky way
2. The network topologies for the two routes must be the same. That
is, the entrances from "the Internet" must be the same for both
routes.

In the multivendor multihomed case, each of the customers ISPs
connects to the rest of the Internet differently. The network topology
for the multihomed customer generally differs from the network
topology of any of the ISPs serving the customer. As a result, his
route is not aggregable.

In the single homed or single-vendor multihomed case, the customer
shares a network topology with the ISP. As a result, his route can be
shared with the ISP's route as long as the addresses are contiguous.



On Tue, Jul 28, 2009 at 11:52 AM, David Williamson<dlw+arin at tellme.com> wrote:
> While I think mast of us are concerned about routing table growth, it's
> a problem that is unrelated to good stewardship of the address space.

Hold your horses there David. As I believe Tony Li over on the IRTG
RRG said, addressing is routing is addressing.  The two are
inseparable. If they weren't then maximum conservation of IPv4
addresses would obviously come from having the IANA assign every /32.

> That's why routability of any given block is explicitly note to not be
> guaranteed by the NRPM.

Quantum physicists don't guarantee that oxygen molecules won't
randomly leave your vicinity until you suffocate. Would you suggest
that ARIN's non-guarantee has more substance to it than the
physicists'?

Let's be practical here: guarantee or no, we intend that addresses
assigned by ARIN be routable on the Internet. And we endeavor to meet
the routing system's needs so that they will be.


On Tue, Jul 28, 2009 at 2:09 PM, Jon Lewis<jlewis at lewis.org> wrote:
> The distinction some people may not be getting is that if I know ARIN
> allocates from a /8 nothing longer than /20s, then if I'm running out of
> routing slots, I can use a prefix-list to ignore anything /21 (or maybe /22)
> or longer from that /8.  If ARIN allocates /24s from a /8 or probably longer
> net, then I need to accept those /24s.  That's the theory anyway.

Hi Jon,

That theory was destroyed by NRPM 4.2.3.6. If you filter on RIR
minimums you will damage your connectivity to small multihomed sites.

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 jlewis at lewis.org  Tue Jul 28 20:39:35 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 28 Jul 2009 20:39:35 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>

On Tue, 28 Jul 2009, William Herrin wrote:

> On Tue, Jul 28, 2009 at 2:09 PM, Jon Lewis<jlewis at lewis.org> wrote:
>> The distinction some people may not be getting is that if I know ARIN
>> allocates from a /8 nothing longer than /20s, then if I'm running out of
>> routing slots, I can use a prefix-list to ignore anything /21 (or maybe /22)
>> or longer from that /8.  If ARIN allocates /24s from a /8 or probably longer
>> net, then I need to accept those /24s.  That's the theory anyway.
>
> Hi Jon,
>
> That theory was destroyed by NRPM 4.2.3.6.

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

How so?  Suppose you're multihomed to Sprint and XO and are using a /24 
from XO space.  Lets say I'm on two other networks and I filter on RIR 
minimums.  I normally get to you via an XO aggregate route (say a /17 that 
covers your /24).

Your XO circuit goes down.  I still send traffic destined for your /24 via 
the path I see for the /17.  A few things can happen.  The traffic makes 
it as far as XO, at which point they hopefully are accepting your /24 via 
your advertisement to Sprint, and the traffic gets to you (it's a longer 
path than usual...but at least it made it).  I send traffic for your /24 
via the path I see for the /17, and before it gets as far as XO, a router 
in another AS along the way has "full routes" and has a path for your /24 
via Sprint and the traffic gets to you about as efficiently as normal.

What broke?

The breakage happens when people deaggregate PI space (no covering 
aggregate announced by an upstream) and don't announce the aggregate.  I 
have to assume these are cases of stupidity/negligence...but there are 
many examples of it.

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


From bill at herrin.us  Tue Jul 28 21:22:35 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Jul 2009 21:22:35 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>
Message-ID: <3c3e3fca0907281822s383d0991i2a32c9d6505b9f8e@mail.gmail.com>

On Tue, Jul 28, 2009 at 8:39 PM, Jon Lewis<jlewis at lewis.org> wrote:
> On Tue, 28 Jul 2009, William Herrin wrote:
>> That theory was destroyed by NRPM 4.2.3.6.
>
> https://www.arin.net/policy/nrpm.html#four236
>
> How so? ?Suppose you're multihomed to Sprint and XO and are using a /24 from
> XO space. ?Lets say I'm on two other networks and I filter on RIR minimums.
> ?I normally get to you via an XO aggregate route (say a /17 that covers your
> /24).
>
> Your XO circuit goes down. ?I still send traffic destined for your /24 via
> the path I see for the /17. ?A few things can happen. ?The traffic makes it
> as far as XO, at which point they hopefully are accepting your /24 via your
> advertisement to Sprint, and the traffic gets to you (it's a longer path
> than usual...but at least it made it). ?I send traffic for your /24 via the
> path I see for the /17, and before it gets as far as XO, a router in another
> AS along the way has "full routes" and has a path for your /24 via Sprint
> and the traffic gets to you about as efficiently as normal.
>
> What broke?

Jon,

In that scenario, nothing but some inefficient routing. Now let's
suppose you're connected to Sprint and Sprint and XO have a peering
spat. You should still be able to get to me since we're both connected
to Sprint but you can't because you filter my /24 route and XO's
covering route has vanished from your view.

Sprint and Cogent had that problem last year. It lasted a good part of a week.


Yes, as an origin AS you can generally filter whatever you want and
spit a default route at one of your ISPs. You can do that regardless
of the RIR minimums. At the DNC I kept a 6500/Sup2 alive an extra
couple of years by filtering APNIC /8's and tying them to the best
path for Japan's routes. Cut almost 60k prefixes from my TCAM.

As a transit AS you really can't get away with that. If you don't
carry all the routes down to /24, your customers will see routing
anomalies.

By the way, do you know of anyone who is actually filtering on RIR
minimums instead of on /24? That would come in handy in one of my
negotiations with a vendor right now.

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 jlewis at lewis.org  Wed Jul 29 00:48:13 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 29 Jul 2009 00:48:13 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907281822s383d0991i2a32c9d6505b9f8e@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com> 
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail> 
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com> 
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail> 
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com> 
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail> 
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com> 
	<Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>
	<3c3e3fca0907281822s383d0991i2a32c9d6505b9f8e@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907290035190.4187@soloth.lewis.org>

On Tue, 28 Jul 2009, William Herrin wrote:

> In that scenario, nothing but some inefficient routing. Now let's
> suppose you're connected to Sprint and Sprint and XO have a peering
> spat. You should still be able to get to me since we're both connected
> to Sprint but you can't because you filter my /24 route and XO's
> covering route has vanished from your view.
>
> Sprint and Cogent had that problem last year. It lasted a good part of a week.

This was originally going to be my reply to Owen, but then I noticed his 
reply was not to the list.

Ok, there are a few assumptions in the scenario I suggested.

1) "Tier 1's" "don't filter"...i.e. not for route table reduction.

2) Any network that does filter for the purpose of route reduction carries 
a default route pointing towards a network that doesn't doesn't filter or 
that points default at one that doesn't.  This could go on for several 
AS's.

3) For the sake of this argument, peering battles are ignored.  Yes, they 
happen from time to time, and they're one of the reasons networks 
multihome, but they're hardly the normal state.

Sure, multiple failures (or one failure and a peering game of chicken) can 
happen that would break end to end connectivity, but that's already a 
possibility without filtering.  You can only do so much to guarantee the 
network / internet generally works.

> As a transit AS you really can't get away with that. If you don't
> carry all the routes down to /24, your customers will see routing
> anomalies.

I got away with it.  I suspect lots of other transit AS's have.

> By the way, do you know of anyone who is actually filtering on RIR
> minimums instead of on /24? That would come in handy in one of my
> negotiations with a vendor right now.

No.  I wrote some emails and a blog entry about this in late 2007 / early 
2008.

http://jonsblog.lewis.org/2008/01/19#bgp

We ran with a filter based on parts of this for a short time before 
upgrading.  Based on the number of emails I got about it, I suspect others 
used it, but I don't know who or if they still are.

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


From jcurran at arin.net  Wed Jul 29 01:10:15 2009
From: jcurran at arin.net (John Curran)
Date: Wed, 29 Jul 2009 01:10:15 -0400
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <4A6F1BC3.6000305@bogus.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com> <4A6F1BC3.6000305@bogus.com>
Message-ID: <691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>

> On Jul 28, 2009, at 11:39 AM, Joel Jaeggli wrote:
>
> ...It seems likely that at some point networks will likely routinely  
> accept
> longer prefixes than /24.

Taking the long view: once ISP's are unable to obtain any additional  
IPv4
allocations from the RIRs (due to free pool depletion), there will be a
significant focus on recovery of space from less than efficient internal
(and possibly client) assignments.  I'd expect such space to be  
reassigned
to new clients very small assignments (e.g. /30), with nominal effect on
the routing table since the covering routes are already present.

The real question is what happens at that point when a new customer  
shows
up and says that his friend's letting him to use a piece (e.g. /30) of  
the
friend's 'class C' network... i.e. if new native IPv4 service requires a
BYOA (Bring Your Own Address) approach due to lack of available  
addresses,
will ISP's turn down new business that doesn't come with own IPv4  
block of
least /24 in size?

/John


From bill at herrin.us  Wed Jul 29 03:14:25 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 03:14:25 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907290035190.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>
	<3c3e3fca0907281822s383d0991i2a32c9d6505b9f8e@mail.gmail.com>
	<Pine.LNX.4.61.0907290035190.4187@soloth.lewis.org>
Message-ID: <3c3e3fca0907290014j45229b52r1379c4f6de0b81a5@mail.gmail.com>

On Wed, Jul 29, 2009 at 12:48 AM, Jon Lewis<jlewis at lewis.org> wrote:
> On Tue, 28 Jul 2009, William Herrin wrote:
> Ok, there are a few assumptions in the scenario I suggested.
>
> 1) "Tier 1's" "don't filter"...i.e. not for route table reduction.
>
> 2) Any network that does filter for the purpose of route reduction carries a
> default route pointing towards a network that doesn't doesn't filter or that
> points default at one that doesn't. ?This could go on for several AS's.
>
>> As a transit AS you really can't get away with that. If you don't
>> carry all the routes down to /24, your customers will see routing
>> anomalies.
>
> I got away with it. ?I suspect lots of other transit AS's have.

Hi Jon,

Okay. You've described a circumstance based on today's approach of
assigning multihomed blocks smaller than /22 from ISP's space where
99% of the backbone routers carry the small multihomer's /24 and the
other 1% do something that is probably but not definitely reasonable
enough to maintain full connectivity. So drawing this back to the
topic of the discussion: address assignment for small multihomed
organizations.

Are you just offering an interesting corner case in today's routing
system? Or do you propose that this... morass... is actually a
*healthy* result of the status quo?

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 joelja at bogus.com  Wed Jul 29 03:30:33 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jul 2009 09:30:33 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com><3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
Message-ID: <4A6FFA99.7060405@bogus.com>



Kevin Kargel wrote:
>>   Obviously the primary reason for a limit is the accepted minimum routing
>> entry size of a /24.  Of course, you knew that.  So why ask the question?
> 
> Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
> it won't cause problems then why not extend the mask size?  Or are you
> saying that long mask route entries do in fact cause problems?

I'm happy to compress longer entreis out of my fib. If there's a route
for a covering prefix that's shorter, as there generally is for
multihomer using there upstream's address space then, no problem some
level of connectivity is preserved, possibly not as much as the
multihomer desires but enough for my purposes.

>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Kevin Kargel
>> Sent: Tuesday, July 28, 2009 12:30 PM
>> To: William Herrin; Joel Jaeggli
>> Cc: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>> Based on what everyone is saying about the /24 issue - and for the purpose
>> of argument accepting that /24 will cause no problems - then why not take
>> it a step further and remove any maximum length netmask restriction for a
>> multi-homed entity with a single allocation.
>>
>> One entity with one allocation will generate one table entry regardless of
>> what size it is, so why limit them to a /24.  I am sure there are entities
>> out there who could operate just fine out of a /25 or even a /32, and so
>> long as they are not creating gratuitous route table entries then we could
>> be more efficient allowing them to only consume the space they need.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>> On Behalf Of William Herrin
>>> Sent: Tuesday, July 28, 2009 10:30 AM
>>> To: Joel Jaeggli
>>> Cc: ARIN PPML
>>> Subject: Re: [arin-ppml] Rationale for /22
>>>
>>> On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>>> William Herrin wrote:
>>>>> Given the shortage of IPv4 addresses, why structure the policies so
>>>>> that we give anyone more than they actually want?
>>>> The minimum number of addresses that can be used may not in fact
>>>> reflect the minimum that should be used.
>>>>
>>>>        For the purposes of minimizing fragmention.
>>>>
>>>>        Supporting basic network operation (it's nice when traceroute
>>>>        and pmtud work) because your intermediate routers are privately
>>>>        numbered.
>>>>
>>>>        Limiting the consequences of imagination failure, which may
>>>>        sound flippant but renumbering, requesting an additional block,
>>>>        or and point one and two are good reasons to make a potential
>>>>        multi-homer justify the assignment of a block of the
>> appropriate
>>>>        size for that activity.
>>> Hi Joel,
>>>
>>> I could almost see that argument on the ISP side but it doesn't make
>>> sense to me on the end-user side, particularly when they may be
>>> trivially multihomed. I surely wouldn't want to presume that I know
>>> every registrant's address count needs better than he does though. f
>>> you don't mind, let's just focus on the downside risk.
>>>
>>> So, the registrant asks for a /24 and a year later his replacement who
>>> is a better network engineer figures out he really needs a /22 after
>>> all. What's the impact? Other than insisting on giving him a /22 up
>>> front, is there another way to mitigate that impact?
>>>
>>> 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.
>> _______________________________________________
>> 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 bmanning at vacation.karoshi.com  Wed Jul 29 03:35:55 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 29 Jul 2009 07:35:55 +0000
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A6FFA99.7060405@bogus.com>
References: <402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<4A6FFA99.7060405@bogus.com>
Message-ID: <20090729073555.GA21203@vacation.karoshi.com.>

On Wed, Jul 29, 2009 at 09:30:33AM +0200, Joel Jaeggli wrote:
> 
> 
> Kevin Kargel wrote:
> >>   Obviously the primary reason for a limit is the accepted minimum routing
> >> entry size of a /24.  Of course, you knew that.  So why ask the question?
> > 
> > Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
> > it won't cause problems then why not extend the mask size?  Or are you
> > saying that long mask route entries do in fact cause problems?
> 
> I'm happy to compress longer entreis out of my fib. If there's a route
> for a covering prefix that's shorter, as there generally is for
> multihomer using there upstream's address space then, no problem some
> level of connectivity is preserved, possibly not as much as the
> multihomer desires but enough for my purposes.


	so, you would be happy with Peter Lothbergs old sprint announcement
	of 128.0.0.0/3  ??

--bill


From joelja at bogus.com  Wed Jul 29 04:03:31 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 29 Jul 2009 10:03:31 +0200
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090729073555.GA21203@vacation.karoshi.com.>
References: <402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<4A6FFA99.7060405@bogus.com>
	<20090729073555.GA21203@vacation.karoshi.com.>
Message-ID: <4A700253.6000404@bogus.com>



bmanning at vacation.karoshi.com wrote:
> On Wed, Jul 29, 2009 at 09:30:33AM +0200, Joel Jaeggli wrote:
>>
>> Kevin Kargel wrote:
>>>>   Obviously the primary reason for a limit is the accepted minimum routing
>>>> entry size of a /24.  Of course, you knew that.  So why ask the question?
>>> Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
>>> it won't cause problems then why not extend the mask size?  Or are you
>>> saying that long mask route entries do in fact cause problems?
>> I'm happy to compress longer entreis out of my fib. If there's a route
>> for a covering prefix that's shorter, as there generally is for
>> multihomer using there upstream's address space then, no problem some
>> level of connectivity is preserved, possibly not as much as the
>> multihomer desires but enough for my purposes.
> 
> 
> 	so, you would be happy with Peter Lothbergs old sprint announcement
> 	of 128.0.0.0/3  ??

If I wanted default, I would clearly need no more specifics.

> --bill
> 


From farmer at umn.edu  Wed Jul 29 08:24:01 2009
From: farmer at umn.edu (David Farmer)
Date: 29 Jul 2009 07:24:01 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6F1037.28208.146790F8@farmer.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>,
	<4A6F1037.28208.146790F8@farmer.umn.edu>
Message-ID: <Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>

On Jul 28 2009, David Farmer wrote:

>On 28 Jul 2009 Chris Grundemann wrote:
>
>> I forgot to account for the End Policy; when IANA reaches 5 /8s
>> unallocated, we will drop to zero.  Allowing for that, maybe a better
>> set is: X=20, Y=15 and Z=10.  Or perhaps we should take less steps and
>> go from a 12 month window to 6 and then to the 1/4 maximum.
> 
>How about we skip the 9 month window.  Go to 6 month 
>window at 20 /8s and 3 month window at 10 /8s.  I think we 
>need to get down to a 3 month window several months, at least 
>3 or 4 months, before we get down to the last /8.  As you noted 
>the End policy will basically take us from 6 or 7 /8s to 0.

I've just about got the new text ready.

But, I have another question;

Should Transfers to Specified Recipients keep a 12 month window or be 
reduced down to 6 month and then 3 months like allocations from ARIN. I 
think they should keep the 12 month window, but I want to know what others 
think.

David Farmer


From marla.azinger at frontiercorp.com  Wed Jul 29 10:16:35 2009
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Wed, 29 Jul 2009 10:16:35 -0400
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com> <4A6F1BC3.6000305@bogus.com>
	<691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048509A929E@ROCH-EXCH1.corp.pvt>

Nice question John. LOL  Let me pull out my crystal ball...

Sure its on my mind, but I cant say what we will do until I see for myself how things truely end up.  Sure if its worst case scenerio and v6 isnt pulling the weight needed and my routers wont fall over from a significant quantity of more specific subnets and all the other aspects line up as needed...yeah possibly we would do it.  I think in the moment a decision can be made fairly easily.  You can or cant or will or wont do it. However, I have no plans on really having to face that scenerio and I hope vendors and other network providers have the same goal.

I know this is a very simplified answer, but to me its a crystal ball question at this point in time.

Cheers
Marla 
Frontier communications

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Tuesday, July 28, 2009 10:10 PM
To: arin ppml
Subject: [arin-ppml] On the topic of longer prefixes...

> On Jul 28, 2009, at 11:39 AM, Joel Jaeggli wrote:
>
> ...It seems likely that at some point networks will likely routinely 
> accept longer prefixes than /24.

Taking the long view: once ISP's are unable to obtain any additional
IPv4
allocations from the RIRs (due to free pool depletion), there will be a significant focus on recovery of space from less than efficient internal (and possibly client) assignments.  I'd expect such space to be reassigned to new clients very small assignments (e.g. /30), with nominal effect on the routing table since the covering routes are already present.

The real question is what happens at that point when a new customer shows up and says that his friend's letting him to use a piece (e.g. /30) of the friend's 'class C' network... i.e. if new native IPv4 service requires a BYOA (Bring Your Own Address) approach due to lack of available addresses, will ISP's turn down new business that doesn't come with own IPv4 block of least /24 in size?

/John
_______________________________________________
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  Wed Jul 29 11:02:15 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Jul 2009 09:02:15 -0600
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com> <4A6F1BC3.6000305@bogus.com>
	<691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
Message-ID: <443de7ad0907290802na1881b5nb18817fa6066c4d2@mail.gmail.com>

On Tue, Jul 28, 2009 at 23:10, John Curran<jcurran at arin.net> wrote:
>> On Jul 28, 2009, at 11:39 AM, Joel Jaeggli wrote:
>>
>> ...It seems likely that at some point networks will likely routinely
>> accept
>> longer prefixes than /24.
>
> Taking the long view: once ISP's are unable to obtain any additional IPv4
> allocations from the RIRs (due to free pool depletion), there will be a
> significant focus on recovery of space from less than efficient internal
> (and possibly client) assignments. ?I'd expect such space to be reassigned
> to new clients very small assignments (e.g. /30), with nominal effect on
> the routing table since the covering routes are already present.
>
> The real question is what happens at that point when a new customer shows
> up and says that his friend's letting him to use a piece (e.g. /30) of the
> friend's 'class C' network... i.e. if new native IPv4 service requires a
> BYOA (Bring Your Own Address) approach due to lack of available addresses,
> will ISP's turn down new business that doesn't come with own IPv4 block of
> least /24 in size?

I think that it is more likely that folks will buy access where they
can get addresses rather than crafting BYOA deals.

In your example of Customer A, ISP X and friend #1; I think the most
probable outcome is that Customer A purchases a simple transit circuit
from ISP X, connecting him to friend #1's network.  Friend #1
continues to announce the /24, buys a bit more bandwidth from his
provider and everyone is happy.

I think that *if* ISPs run out of IPv4 addresses we will see quite a
few of these "ISPs of opportunity" spring up to serve the demand (at
least in the area which that ISP serves).

Folks who want to multihome will have a bit more of a challenge but I
think there are some creative solutions that can be applied with a
couple /30s (or /31s even) from distinct providers with no need to
announce them beyond said provider.  Dynamic DNS and a couple BGP
default routes spring to mind; certainly not perfect, but probably
more workable than trying to get everyone to buy into longer prefixes
on your timetable...

How is that for skrying?

~Chris

>
> /John
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From owen at delong.com  Wed Jul 29 11:20:18 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jul 2009 08:20:18 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907290035190.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<Pine.LNX.4.61.0907282019550.4187@soloth.lewis.org>
	<3c3e3fca0907281822s383d0991i2a32c9d6505b9f8e@mail.gmail.com>
	<Pine.LNX.4.61.0907290035190.4187@soloth.lewis.org>
Message-ID: <DF3ACB08-77CB-4282-AA1B-306C0D1A04D8@delong.com>


On Jul 28, 2009, at 9:48 PM, Jon Lewis wrote:

> On Tue, 28 Jul 2009, William Herrin wrote:
>
>> In that scenario, nothing but some inefficient routing. Now let's
>> suppose you're connected to Sprint and Sprint and XO have a peering
>> spat. You should still be able to get to me since we're both  
>> connected
>> to Sprint but you can't because you filter my /24 route and XO's
>> covering route has vanished from your view.
>>
>> Sprint and Cogent had that problem last year. It lasted a good part  
>> of a week.
>
> This was originally going to be my reply to Owen, but then I noticed  
> his reply was not to the list.
>
You're welcome to include what I sent you to the list.  I sent it to  
you because I did not
expect it to be of general interest to the list, not because I cared  
about it being private.

> Ok, there are a few assumptions in the scenario I suggested.
>
> 1) "Tier 1's" "don't filter"...i.e. not for route table reduction.
>
While this is true of ~90% of them today, I think as the routing table  
expands in the IPv4
end-game, it will rapidly become progressively less true.

> 2) Any network that does filter for the purpose of route reduction  
> carries a default route pointing towards a network that doesn't  
> doesn't filter or that points default at one that doesn't.  This  
> could go on for several AS's.
>
Relying on this fact assumes an ability to detect changes in behavior  
potentially several
AS's away and respond to them in a timely fashion or risk rather  
difficult to debug problems
down the road.

> 3) For the sake of this argument, peering battles are ignored.  Yes,  
> they happen from time to time, and they're one of the reasons  
> networks multihome, but they're hardly the normal state.
>
True, but, when they do occur, your recommended behavior will  
exacerbate the consequences
to end users.

Owen

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

From kkargel at polartel.com  Wed Jul 29 11:22:46 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Jul 2009 10:22:46 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><4A6EBA3D.8020800@bogus.com><3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com><4A6F0C18.1000107@bogus.com><3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail><402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail><443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, July 28, 2009 7:16 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Tue, Jul 28, 2009 at 1:46 PM, Kevin Kargel<kkargel at polartel.com> wrote:
> >> AFAIK, there are no ISPs allowing customers to multihome with less
> >> than a /24 currently but many who are allowing those /24s. ?So if that
> >> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
> >> entry in the table.
> >
> > This is incorrect. ?If the Org gets a /24 from it's upstream ISP there
> is
> > the same entry in the routing table. ?If the Org gets a discontiguous
> /24
> > from ARIN there is an additional entry in the routing table.
> 
> Kevin,
> 
> For the multihomed case we're discussing, this statement is in error.
> In order to aggregate small routes into a larger route, two things
> must be true:
> 
> 1. The covered address space must be contiguous in a netmasky way
> 2. The network topologies for the two routes must be the same. That
> is, the entrances from "the Internet" must be the same for both
> routes.
> 
> In the multivendor multihomed case, each of the customers ISPs
> connects to the rest of the Internet differently. The network topology
> for the multihomed customer generally differs from the network
> topology of any of the ISPs serving the customer. As a result, his
> route is not aggregable.
> 

I don't remember a topology discriminator in the BGP algorithm.  I have dual
homed customers who use IP's from me.  When I advertise those out my BGP
portal they are aggregated.  

For example if I advertise 66.231.96.0/19 in my BGP and I have allocated
66.231.103.0/23 to one of my customers his network will be aggregated to be
within my BGP advertisements without adding a specific route.

Of course there is no way the ISP on the other side of the customer can
aggregate, hence my statement that it would inject one additional route to
the routing table upstream from my customers peers.

For my customers that have their own portable IP's, those are not agregable
by my BGP nor by the BGP on the far side of the customer.  Those IP's inject
two new routes in the tables outside of the customers peers.

For example, if my BGP has a network statement for 66.231.96.0/19 and my
customer has an IP of 66.231.128.1/24 , even though it is contiguous it will
not be aggregated.  It does not fall within my network and it does not
extend to a CIDR boundary contiguous to my network.  If I choose to
advertise via BGP to transit traffic for them  the customers IP will be
advertised as a separate network with a discrete route entry.




> 

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

From bill at herrin.us  Wed Jul 29 11:35:39 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 11:35:39 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>
Message-ID: <3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>

On Wed, Jul 29, 2009 at 11:22 AM, Kevin Kargel<kkargel at polartel.com> wrote:
>> In the multivendor multihomed case, each of the customers ISPs
>> connects to the rest of the Internet differently. The network topology
>> for the multihomed customer generally differs from the network
>> topology of any of the ISPs serving the customer. As a result, his
>> route is not aggregable.
>>
>
> I don't remember a topology discriminator in the BGP algorithm.

Hi Kevin,

There isn't one. When the topology differs, you have to announce a
separate route. BGP offers no way to differentiate between multiple
topologies within a single route.


> I have dual
> homed customers who use IP's from me. ?When I advertise those out my BGP
> portal they are aggregated.
>
> For example if I advertise 66.231.96.0/19 in my BGP and I have allocated
> 66.231.103.0/23 to one of my customers his network will be aggregated to be
> within my BGP advertisements without adding a specific route.

Then you would be making a mistake. His /23 announcement via the other
ISP will override your covering route, preventing him from receiving
any service from you whenever his other link is operational. The
more-specific route always overrides the less specific route.

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  Wed Jul 29 11:38:15 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jul 2009 08:38:15 -0700
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>,
	<4A6F1037.28208.146790F8@farmer.umn.edu>
	<Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>
Message-ID: <13F38AB7-ACA0-4E17-89B0-8CA3BE9E727F@delong.com>

>
> But, I have another question;
>
> Should Transfers to Specified Recipients keep a 12 month window or  
> be reduced down to 6 month and then 3 months like allocations from  
> ARIN. I think they should keep the 12 month window, but I want to  
> know what others think.

12

Owen

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

From cgrundemann at gmail.com  Wed Jul 29 12:08:16 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Jul 2009 10:08:16 -0600
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>
	<3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
Message-ID: <443de7ad0907290908i438173bbqcfa2ee15512622e5@mail.gmail.com>

On Wed, Jul 29, 2009 at 09:35, William Herrin<bill at herrin.us> wrote:
> On Wed, Jul 29, 2009 at 11:22 AM, Kevin Kargel<kkargel at polartel.com> wrote:
>>> In the multivendor multihomed case, each of the customers ISPs
>>> connects to the rest of the Internet differently. The network topology
>>> for the multihomed customer generally differs from the network
>>> topology of any of the ISPs serving the customer. As a result, his
>>> route is not aggregable.
>>>
>>
>> I don't remember a topology discriminator in the BGP algorithm.
>
> Hi Kevin,
>
> There isn't one. When the topology differs, you have to announce a
> separate route. BGP offers no way to differentiate between multiple
> topologies within a single route.
>
>
>> I have dual
>> homed customers who use IP's from me. ?When I advertise those out my BGP
>> portal they are aggregated.
>>
>> For example if I advertise 66.231.96.0/19 in my BGP and I have allocated
>> 66.231.103.0/23 to one of my customers his network will be aggregated to be
>> within my BGP advertisements without adding a specific route.
>
> Then you would be making a mistake. His /23 announcement via the other
> ISP will override your covering route, preventing him from receiving
> any service from you whenever his other link is operational. The
> more-specific route always overrides the less specific route.

Saves on bandwidth costs though I guess ;)

>
> Regards,
> Bill
>
>
> --
> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>




-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From josmon at rigozsaurus.com  Wed Jul 29 11:37:05 2009
From: josmon at rigozsaurus.com (John Osmon)
Date: Wed, 29 Jul 2009 09:37:05 -0600
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>
References: <4A6F1037.28208.146790F8@farmer.umn.edu>
	<Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>
Message-ID: <20090729153705.GA8256@jeeves.rigozsaurus.com>

On Wed, Jul 29, 2009 at 07:24:01AM -0500, David Farmer wrote:
[...]
> But, I have another question;
> 
> Should Transfers to Specified Recipients keep a 12 month window or be 
> reduced down to 6 month and then 3 months like allocations from ARIN. I 
> think they should keep the 12 month window, but I want to know what others 
> think.

I might have missed something, but...

'splain it to me why any one type of transfer should be handled 
differently on the time axis?




From cgrundemann at gmail.com  Wed Jul 29 12:48:54 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Jul 2009 10:48:54 -0600
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <20090729153705.GA8256@jeeves.rigozsaurus.com>
References: <4A6F1037.28208.146790F8@farmer.umn.edu>
	<Gophermail.2.0.0907290724010.7625@vs-w.tc.umn.edu>
	<20090729153705.GA8256@jeeves.rigozsaurus.com>
Message-ID: <443de7ad0907290948j5b8a9acfjb67a894b87cf514b@mail.gmail.com>

On Wed, Jul 29, 2009 at 09:37, John Osmon<josmon at rigozsaurus.com> wrote:
> On Wed, Jul 29, 2009 at 07:24:01AM -0500, David Farmer wrote:
> [...]
>> But, I have another question;
>>
>> Should Transfers to Specified Recipients keep a 12 month window or be
>> reduced down to 6 month and then 3 months like allocations from ARIN. I
>> think they should keep the 12 month window, but I want to know what others
>> think.
>
> I might have missed something, but...
>
> 'splain it to me why any one type of transfer should be handled
> differently on the time axis?

The two transfer types (direct vs RIR) deal with different pools of
the same resource.  Both are finite but one is shrinking and the other
growing.  Therefor it may be logical to treat them differently in
policy.

In other words, the argument could be made that because direct
transfers were instituted to create/allow liquidity in
"post-allocation" IPv4 space; they should be as unrestricted as
possible, so that such post-allocation IPv4 can flow naturally to
where it is most needed (from where it is not).  On the other hand,
unallocated IPv4 space is something that we _will_ run out of and thus
should be spread to as many Orgs as possible before we do.

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

-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From kkargel at polartel.com  Wed Jul 29 13:48:56 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Jul 2009 12:48:56 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>
	<3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFB@mail>

> 
> > I have dual
> > homed customers who use IP's from me. ?When I advertise those out my BGP
> > portal they are aggregated.
> >
> > For example if I advertise 66.231.96.0/19 in my BGP and I have allocated
> > 66.231.103.0/23 to one of my customers his network will be aggregated to
> be
> > within my BGP advertisements without adding a specific route.
> 
> Then you would be making a mistake. His /23 announcement via the other
> ISP will override your covering route, preventing him from receiving
> any service from you whenever his other link is operational. The
> more-specific route always overrides the less specific route.
> 
> Regards,
> Bill

Perhaps another factor that comes in to play here is that I do not accept
advertisements for my own networks from external peers.  There is no need, I
already know the best routes to my own networks.  

Unless I am mistaken if one of my peers sends me my customers /23 route I
believe that will trigger a rib failure and the route will not be injected
in to my tables.

Whatever the mechanism I do receive the /23 advertisement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090729/d46b9ab8/attachment.bin>

From mksmith at adhost.com  Wed Jul 29 14:03:33 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 29 Jul 2009 11:03:33 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFB@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com><4A6F0C18.1000107@bogus.com><3c3e3fca0907280829m574f96fcob235d03f035a61cd@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail><402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail><443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail><3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail><3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DFB@mail>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B690@ad-exh01.adhost.lan>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Kargel
> Sent: Wednesday, July 29, 2009 10:49 AM
> To: William Herrin
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> >
> > > I have dual
> > > homed customers who use IP's from me. ?When I advertise those out
> my
> > > BGP portal they are aggregated.
> > >
> > > For example if I advertise 66.231.96.0/19 in my BGP and I have
> > > allocated
> > > 66.231.103.0/23 to one of my customers his network will be
> > > aggregated to
> > be
> > > within my BGP advertisements without adding a specific route.
> >
> > Then you would be making a mistake. His /23 announcement via the
> other
> > ISP will override your covering route, preventing him from receiving
> > any service from you whenever his other link is operational. The
> > more-specific route always overrides the less specific route.
> >
> > Regards,
> > Bill
> 
> Perhaps another factor that comes in to play here is that I do not
> accept advertisements for my own networks from external peers.  There
> is no need, I already know the best routes to my own networks.
> 
> Unless I am mistaken if one of my peers sends me my customers /23 route
> I believe that will trigger a rib failure and the route will not be
> injected in to my tables.
> 
> Whatever the mechanism I do receive the /23 advertisement.

I think it's more about what I see of your customer's routes.  If you announce a /20 and your customer via another provider announces a /23 I will always prefer that path.  So, my bits (and your revenue) will go to the other provider.

Mike


From kkargel at polartel.com  Wed Jul 29 14:21:54 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Jul 2009 13:21:54 -0500
Subject: [arin-ppml] FW:  Rationale for /22
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFE@mail>


> 
> I think it's more about what I see of your customer's routes.  If you
> announce a /20 and your customer via another provider announces a /23 I
> will always prefer that path.  So, my bits (and your revenue) will go to
> the other provider.
> 
> Mike

Which is absolutely fine by me if that's the way they want to balance their
traffic.  My revenue is the same whether his circuit is 1% or 99% utilized.
I don't understand why you would have a problem with it?

If any of my upstream providers dictated that my traffic had to go through
them things would get exciting real quick, or I would have a different
provider.  This would be especially true in the case of a burstable circuit.

I have never had an upstream provider complain because my circuit was
under-utilized.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090729/ccf7cbb7/attachment.bin>

From mksmith at adhost.com  Wed Jul 29 14:28:27 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 29 Jul 2009 11:28:27 -0700
Subject: [arin-ppml] FW:  Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFE@mail>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFE@mail>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B69C@ad-exh01.adhost.lan>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Kevin Kargel
> Sent: Wednesday, July 29, 2009 11:22 AM
> To: ARIN PPML
> Subject: [arin-ppml] FW: Rationale for /22
> 
> 
> >
> > I think it's more about what I see of your customer's routes.  If
you
> > announce a /20 and your customer via another provider announces a
/23
> > I will always prefer that path.  So, my bits (and your revenue) will
> > go to the other provider.
> >
> > Mike
> 
> Which is absolutely fine by me if that's the way they want to balance
> their traffic.  My revenue is the same whether his circuit is 1% or
99%
> utilized.
> I don't understand why you would have a problem with it?
> 

Ah.  We bill on 95th percentile, so it does matter.

> If any of my upstream providers dictated that my traffic had to go
> through them things would get exciting real quick, or I would have a
> different provider.  This would be especially true in the case of a
> burstable circuit.
>

I don't dictate.  But, if my customer is announcing a de-aggregate of my
IP space, I announce the same de-aggregate.

Mike







From cgrundemann at gmail.com  Wed Jul 29 14:36:29 2009
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Jul 2009 12:36:29 -0600
Subject: [arin-ppml] FW: Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFE@mail>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFE@mail>
Message-ID: <443de7ad0907291136o2357d76ageeb828f6fb103e3@mail.gmail.com>

On Wed, Jul 29, 2009 at 12:21, Kevin Kargel<kkargel at polartel.com> wrote:
>
>>
>> I think it's more about what I see of your customer's routes. ?If you
>> announce a /20 and your customer via another provider announces a /23 I
>> will always prefer that path. ?So, my bits (and your revenue) will go to
>> the other provider.
>>
>> Mike
>
> Which is absolutely fine by me if that's the way they want to balance their
> traffic. ?My revenue is the same whether his circuit is 1% or 99% utilized.
> I don't understand why you would have a problem with it?

But that is not necessarily the way that "they want to balance their
traffic."  You are taking that choice away from them.

Hopefully this is not going too far off topic but just for clarity,
Bill and Mike are correct:

The issue is not about you having or not having the route, the issue
is with other providers having or not having the *best* route.

Let's say Multihomer X is a customer of both ISP A and ISP B.

ISP A assigns 10.0.10/24 to Multihomer X.
Multihomer X advertises 10.0.10/24 to ISP A and ISP B.
ISP A aggregates their space in full and only advertises 10/8 to it's peers.
ISP B cannot aggregate ISP A's space and thus advertises 10.0.10/24 to
it's peers.

PEER Y, who peers with ISP A and ISP B will select it's route to
10.0.10.1 first based on longest match.  So 10.0.10/24 is selected
with no consideration given to 10/8 regardless of Multihomer X'
preference (maybe they are sending ISP A a community to set the local
pref or they are prepending the AS path to ISP B) whatsoever.  No
matter what Multihomer X' expectation or desire, all traffic will flow
to them through ISP B.

PEER W peers with only ISP A and ISP C.  PEER W gets 10/8 from ISP A
and 10.0.10/24 from ISP C (who peers with ISP B).  PEER W has the same
"problem" as PEER Y when forwarding traffic to Multihomer X; the
longest match is 10.0.10/24 and so traffic from PEER W travels through
ISP C, then ISP B and then to Multihomer X - instead of direct through
ISP A.

ISP A not advertising the /24 has determined this behavior, Multihomer
X, ISPs B & C, PEERs Y & W all have no say in it.

>
> If any of my upstream providers dictated that my traffic had to go through
> them things would get exciting real quick, or I would have a different
> provider. ?This would be especially true in the case of a burstable circuit.

Advertising the space that you provide to a multihomed customer would
not force them to go through your network, it would allow them to...

> I have never had an upstream provider complain because my circuit was
> under-utilized.

I guess that depends on how they bill.

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





-- 
Chris Grundemann
weblog.chrisgrundemann.com
www.twitter.com/chrisgrundemann
www.coisoc.org


From bill at herrin.us  Wed Jul 29 15:10:12 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 15:10:12 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601F49DFB@mail>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD0@mail>
	<402EB9414506BC40BB42CD47317FD1B312CCDFD557@Maggie.iconnect-corp.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD2@mail>
	<443de7ad0907281032k408f9a8ex8463b66283f917d0@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DD8@mail>
	<3c3e3fca0907281715h66475157j9374327bb7041d5e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DF6@mail>
	<3c3e3fca0907290835y4770593ci7132445d6069e92e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DFB@mail>
Message-ID: <3c3e3fca0907291210o37239cd0q1a3c1b5b2bf971a2@mail.gmail.com>

On Wed, Jul 29, 2009 at 1:48 PM, Kevin Kargel<kkargel at polartel.com> wrote:
> Perhaps another factor that comes in to play here is that I do not accept
> advertisements for my own networks from external peers. ?There is no need, I
> already know the best routes to my own networks.
>
> Unless I am mistaken if one of my peers sends me my customers /23 route I
> believe that will trigger a rib failure and the route will not be injected
> in to my tables.

Then your routing is doubly broken Kevin: not only will packets for
your customer never reach you (because they prefer the more specific
path via his other ISP) but your customer won't be able to reach you
via his other ISP if his link with you is down. You will have, in
effect, delivered a service to him which is almost completely useless.

Regards,
Bill


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


From bill at herrin.us  Wed Jul 29 16:08:21 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 16:08:21 -0400
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087934B56@ex1.cait.wustl.edu>
	<4A6EBA3D.8020800@bogus.com>
	<3c3e3fca0907280701s3e006459nb63628ecb971f12d@mail.gmail.com>
	<4A6F0C18.1000107@bogus.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601F49DC8@mail>
	<4A6F17A0.50000@gmail.com> <4A6F1BC3.6000305@bogus.com>
	<691C15F3-1AD9-4F7A-9511-2C7582DEF3A7@arin.net>
Message-ID: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>

On Wed, Jul 29, 2009 at 1:10 AM, John Curran<jcurran at arin.net> wrote:
> will ISP's turn down new business that doesn't come with own IPv4 block of
> least /24 in size?

Hi John,

No, they won't turn away business. It doesn't take much of a crystal
ball to figure out that some combination of three things will happen:

1. An external factor will moot the issue. For example, if the
transition to IPv6 is far enough along then new IPv4 service may not
be worth either the customer's or the ISP's trouble. Yeah, I don't buy
that either.

2. An address transfer market will satisfy the need. ISPs who need
more addresses for new customers will buy them from ISPs who have IPs
that aren't earning them enough money versus what they could sell them
for. Not altogether different from the "premium domain name" market we
have today.

3. The ISPs will demand (and get) changes to ARIN policy which effect
the return of "underutilized" addresses for some yet-to-be-chosen
definition of underutilized.  Figure the first step in the crusade
will be something along the lines of regular utilization audits with a
rule that anything which could reasonably employ NAT is not "in use"
for audit purposes.

Tell me I'm wrong if you must, but note it in your journal 'cause I
see the writing on the wall.

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 29 18:53:46 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 29 Jul 2009 23:53:46 +0100
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>

> Figure the 
> first step in the crusade will be something along the lines 
> of regular utilization audits

Sounds a lot like the way the NANPA handles telephone number 
blocks in North America.

--Michael Dillon


From bill at herrin.us  Wed Jul 29 19:20:35 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 19:20:35 -0400
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>
References: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>
	<28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>

On Wed, Jul 29, 2009 at 6:53 PM, <michael.dillon at bt.com> wrote:
>> Figure the
>> first step in the crusade will be something along the lines
>> of regular utilization audits
>
> Sounds a lot like the way the NANPA handles telephone number
> blocks in North America.

Of course, that's not the only way. "Underutilized" addresses could be
ferreted out by a simple expedient of charging every registrant a
dollar for every address they hold and paying them ten bucks for each
one they return to ARIN. If that yields a glut of addresses then next
year its fifty cents and five bucks. If addresses are still scarce
then next year its two bucks and twenty. Kinda like real estate taxes
discourage you from holding on to prime real estate that you're using
in a low-value manner.

There's also a possible legislative route that involves actual taxes
on IP address holdings to shake loose enough addresses to keep the
Internet growing. I predict we'll be highly motivated to avoid that
possibility.

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 tedm at ipinc.net  Wed Jul 29 19:51:18 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Jul 2009 16:51:18 -0700
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>
References: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>	<28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>
	<3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>
Message-ID: <4A70E076.3040107@ipinc.net>

William Herrin wrote:
> On Wed, Jul 29, 2009 at 6:53 PM, <michael.dillon at bt.com> wrote:
>>> Figure the
>>> first step in the crusade will be something along the lines
>>> of regular utilization audits
>> Sounds a lot like the way the NANPA handles telephone number
>> blocks in North America.
> 
> Of course, that's not the only way. "Underutilized" addresses could be
> ferreted out by a simple expedient of charging every registrant a
> dollar for every address they hold and paying them ten bucks for each
> one they return to ARIN. If that yields a glut of addresses then next
> year its fifty cents and five bucks. If addresses are still scarce
> then next year its two bucks and twenty. Kinda like real estate taxes
> discourage you from holding on to prime real estate that you're using
> in a low-value manner.
> 

Real estate taxes do this??!?!?!?

I can tell you that in the area I live in, price for a standard
residential city lot of 100x50 feet is something around $100K
right now.  20 years ago it was around $35K   Property taxes
are 1.5% (as a result of a ballot measure years ago) so over
that 20 years the owners of that undeveloped lot would have
paid $20,240 in property taxes - and thus would have still
realized a profit on the sale of the lot today of $44,760
even though they never developed it, allowing for those taxes.

Likely it would have been greater since this assumes linear
growth of land value when in actual fact the growth around
here bubbled significantly in the last decade.

And your saying real estate taxes discourage you to hold on
to prime real estate your using in a low-value manner?  Can
you explain exactly how this works, please? I know I'm not that
good in math but I didn't think I was that bad!!!

Seriously, your making many sweeping assumptions here.  There's
no guarantee that a fee-per-IP number will result in return of
anything.  An IP holder may engage in speculation and fundamentally
a speculator is betting the market will be favorable to them,
and if they think that they can simply pay some fees to hold on to
a very scarce resource they may do so.  The existence of such a
fee may merely serve to tremendously drive up costs of 3rd party
directed transfers in which case the speculator would be encouraged
to hold on to the IP addresses in the hopes the price will
climb even higher.

A fee might serve to tremendously constrain the availability
of IPv4 for the first several years of IPv4 runout as the
price skyrockets, then dump massive amounts of it on the market
4-5 years after IPv4 runout.  You could end up doing serious
damage to ISP's who cannot get IPv4, then just when people
are starting to be resigned to the unavailability of IPv4
and starting to get serious about IPv6, along comes the IPv4
speculators crash and now everyone thinks there's plenty of
IPv4 - and IPv6 efforts are then smashed.

Ted


From tvest at eyeconomics.com  Wed Jul 29 20:19:02 2009
From: tvest at eyeconomics.com (tvest at eyeconomics.com)
Date: Thu, 30 Jul 2009 02:19:02 +0200
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>
References: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>
	<28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>
	<3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>
Message-ID: <AD356C4E-BCF1-49B7-BDBB-CE0E37DDBA69@eyeconomics.com>


On Jul 30, 2009, at 1:20 AM, William Herrin wrote:

> On Wed, Jul 29, 2009 at 6:53 PM, <michael.dillon at bt.com> wrote:
>>> Figure the
>>> first step in the crusade will be something along the lines
>>> of regular utilization audits
>>
>> Sounds a lot like the way the NANPA handles telephone number
>> blocks in North America.
>
> Of course, that's not the only way. "Underutilized" addresses could be
> ferreted out by a simple expedient of charging every registrant a
> dollar for every address they hold and paying them ten bucks for each
> one they return to ARIN. If that yields a glut of addresses then next
> year its fifty cents and five bucks. If addresses are still scarce
> then next year its two bucks and twenty. Kinda like real estate taxes
> discourage you from holding on to prime real estate that you're using
> in a low-value manner.


http://www.eyeconomics.com/eyecononomics.com/GreenAllocationRegime.html

TV


From bill at herrin.us  Wed Jul 29 21:01:45 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jul 2009 21:01:45 -0400
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <4A70E076.3040107@ipinc.net>
References: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>
	<28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>
	<3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>
	<4A70E076.3040107@ipinc.net>
Message-ID: <3c3e3fca0907291801r459a49bayd3ba581049ef0095@mail.gmail.com>

On Wed, Jul 29, 2009 at 7:51 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> I can tell you that in the area I live in, price for a standard
> residential city lot of 100x50 feet is something around $100K
> right now. ?20 years ago it was around $35K ? Property taxes
> are 1.5% (as a result of a ballot measure years ago) so over
> that 20 years the owners of that undeveloped lot would have
> paid $20,240 in property taxes - and thus would have still
> realized a profit on the sale of the lot today of $44,760
> even though they never developed it, allowing for those taxes.

Ted,

Factor in inflation and $35k 20 years ago is around $65k today.
Likewise, you adjust the $20k taxes for inflation and you've paid
closer to $30k in today's dollars. Of course when you sell it, you'll
pay around 10% capital gains on the paper increase of $65k, or $6.5k.
So, $65k + $30k + $6.5k = $101.5k. In "constant dollars" you're
actually in the hole for $1500.

> I know I'm not that
> good in math but I didn't think I was that bad!!!

*cough*

Sorry man, you walked right in to that one.


One of my favorite strategies for recovering underutilized addresses
is the lottery-like system. Every payment period ARIN sends out bills
for $X per IPv4 address. Flat rate, $X times the number of addresses
you have. For each block you hold, you can pay or return the
addresses. After all the payments are received, they're divvied up
among the folks who returned addresses based on the number of
addresses returned.

Meanwhile, ARIN hires an Vegas oddsmaker to figure out what to set the
payment at to shake loose the number of addresses needed to meet the
demand. And there's no financial mess at ARIN because dollars out is
exactly equal to dollars in.

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 tedm at ipinc.net  Wed Jul 29 23:51:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Jul 2009 20:51:39 -0700
Subject: [arin-ppml] On the topic of longer prefixes...
In-Reply-To: <3c3e3fca0907291801r459a49bayd3ba581049ef0095@mail.gmail.com>
References: <3c3e3fca0907291308m38471947xe30596fac64c9ed@mail.gmail.com>	
	<28E139F46D45AF49A31950F88C4974580263FE9F@E03MVZ2-UKDY.domain1.systemhost.net>	
	<3c3e3fca0907291620h3e7c510fv1a39d140e33377fa@mail.gmail.com>	
	<4A70E076.3040107@ipinc.net>
	<3c3e3fca0907291801r459a49bayd3ba581049ef0095@mail.gmail.com>
Message-ID: <4A7118CB.50004@ipinc.net>

William Herrin wrote:
> On Wed, Jul 29, 2009 at 7:51 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> I can tell you that in the area I live in, price for a standard
>> residential city lot of 100x50 feet is something around $100K
>> right now.  20 years ago it was around $35K   Property taxes
>> are 1.5% (as a result of a ballot measure years ago) so over
>> that 20 years the owners of that undeveloped lot would have
>> paid $20,240 in property taxes - and thus would have still
>> realized a profit on the sale of the lot today of $44,760
>> even though they never developed it, allowing for those taxes.
> 
> Ted,
> 
> Factor in inflation and $35k 20 years ago is around $65k today.

You don't realize that $65K if you put it in a can under your
mattress, you have to invest it in something.  Even a passbook
account - which of course you also pay tax on the interest you
would be making.  I didn't run the numbers but I suspect the
passbook option would have been much worse.

> Likewise, you adjust the $20k taxes for inflation and you've paid
> closer to $30k in today's dollars. Of course when you sell it, you'll
> pay around 10% capital gains on the paper increase of $65k, or $6.5k.

You only pay this if you don't turn around and buy more real estate
with it in the same year, creating real estate losses, which someone 
investing in real estate would certainly be doing.

> So, $65k + $30k + $6.5k = $101.5k. In "constant dollars" you're
> actually in the hole for $1500.
> 

No your not because you have to compare it to any other investments
that you would be making with the money at the same time.

Real estate has historically been one of the safest, low-risk
investments out there, particularly a lot in a city.  If you had had
that money in the stock market you might have nothing.  So what do
you expect?  There's not a lot of places that you could have
stuck $35K into 20 years ago that were as low-risk and even have
$65K today.  I can certainly demonstrate to you a certain 401K plan
by yours truly that over the last decade has LOST value if you
compare it against inflation, and I mean -significantly- lost value,
far far in excess of $1500.

>> I know I'm not that
>> good in math but I didn't think I was that bad!!!
> 
> *cough*
> 
> Sorry man, you walked right in to that one.
> 

My point was that merely assessing a fee (or telling people
that if they don't do something they are going to lose money)
doesn't guarantee that your going to see expected behavior in a market.

[begin rant]

People have been told the last 20 years that if they save for retirement 
they would beat inflation, but legions today don't have squat to
show for that logic.  NOT saving was regarded as in essence losing
money - paying a fee you might say - when in fact if they had just spent 
everything they made they would be in the same situation as today - 
with, likely, a lot more toys to show for it.

The unfortunate fact is that there's home-flippers walking around
out there who took million-dollar risks and today, are being bailed out
by the banks and getting off not owning one red cent on failed
loans of a half-million dollars.  Oh sure, the government regards
that as income - which, rightly it is - but the fact is that the
taxpayers have esentially paid each of those flippers a half million 
bucks.  So in other words, the people that did everything wrong got
golden payouts.  Meanwhile, people who paid their mortgage on time
and all of that, missed out - and many of those haven't even been
able to refinance to take advantage of the lower rates, and of those
that have qualified, many have paid their loan application fee and
are still waiting 6 months later for their lower interest rates.

What a financial lesson this is!  Do what your not supposed to do,
criminally steal money, whine to Momma that you really didn't mean to
do it - and you get rewarded.  Do what your supposed to do, and well,
forget rewarding you buddy - and by the way we are going to come to
you with our hands out so that you can fund all those other losers out
there!!!

[end rant]

> 
> One of my favorite strategies for recovering underutilized addresses
> is the lottery-like system. Every payment period ARIN sends out bills
> for $X per IPv4 address. Flat rate, $X times the number of addresses
> you have. For each block you hold, you can pay or return the
> addresses. After all the payments are received, they're divvied up
> among the folks who returned addresses based on the number of
> addresses returned.
> 

I've observed several times on this list that ARIN fees are structured
so that the more IP you have, the less you pay per-address.  I guess
this is just structural societal logic of ARIN being essentially under
the control of US citizens.  In the US, if your big and sloppy and
not efficient, people feel sorry for you and reward you.  If your
small and efficient and doing what your supposed to do, people screw you 
over.

> Meanwhile, ARIN hires an Vegas oddsmaker to figure out what to set the
> payment at to shake loose the number of addresses needed to meet the
> demand. And there's no financial mess at ARIN because dollars out is
> exactly equal to dollars in.
> 

There will never be a financial mess at ARIN because ARIN has graduated
to the status of a bona-fied "too big to fail" organization.  Even if 
ARIN's guiding hands steer the organization into the rocks I guarantee 
the US Government will be right there with it's hands out to catch them!

;-)

Ted

> Regards,
> Bill
> 
> 
> 
> 



From Wesley.E.George at sprint.com  Thu Jul 30 13:19:19 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Thu, 30 Jul 2009 12:19:19 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>

Golly this is a long thread - lot of good points already made, also some off-topic stuff. Can't find a good place to insert, so I'm top-posting.

To the question of "existing filters/inertia aside, is there a justification for *any* minimum allocation size?"
or putting it another way, "will allowing /22+X (0 < X < 9) allocations for MH customers be the end of the world as we know it?"
By itself, probably not, but when you consider that companies carrying those routes as a part of the full table will also soon be running dual-stack and carrying multiple thousand IPv6 routes in addition to the IPv4 table, there is a point at which this as a combination could become a problem. You rightly point out that we'll only know it when we trip over it. I don't want to get back into the "router vendors suck, big ISPs suck, technology will solve the problem" debate that seems to always break out when we're talking about table size. It's valid as a point to consider, because it's a short-term problem, and not the same sort of issue as long-term routing table growth in IPv6. The size of both tables is going to swell almost simultaneously until IPv4 table size peaks and then starts receding as it is supplanted by IPv6. In other words, it'll likely get worse before it gets better (and then maybe gets worse again).

I think it's a matter of finding the point of diminishing returns, at which the load on the routing system and the increased availability/efficient allocations of addresses (and the relative value of tiny blocks) are balanced. Perhaps this is another of the proposals (if it indeed leads to a proposal) that should have a floating down limit based on the amount of IPv4 addresses left (eg drop to /23 now, /24 when there are X blocks left, /25 at X-Y left, etc). This would be a combination of an "any port in a storm" philosophy (i.e. a few addresses are better than none in some cases) and providing those who want to be good citizens and renumber into a more appropriately sized block and return a larger block the opportunity to do so. The inertia of renumbering and the gradual increase in prefix length would also hopefully temper the growth of the table so that we might sneak up on it in an effort not to trip over it.

Thanks,
Wes

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Monday, July 27, 2009 12:04 PM
To: ARIN PPML
Subject: [arin-ppml] Rationale for /22

Question for y'all:

What is the rationale behind a /22 minimum size for multihomed
organizations? Why not a /24?

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

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

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

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

Excluding conspiracy theories (the big bad ISPs want lock in) I'd like
to hear ideas, answers and even recollections from folks who were
there when the size was set as to why we should prefer /22 as the
minimum multihomed size assignable by ARIN.

Regards,
Bill Herrin


--
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
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 bicknell at ufp.org  Thu Jul 30 13:56:43 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 30 Jul 2009 13:56:43 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
Message-ID: <20090730175643.GB76331@ussenterprise.ufp.org>

In a message written on Thu, Jul 30, 2009 at 12:19:19PM -0500, George, Wes E [NTK] wrote:
> To the question of "existing filters/inertia aside, is there a
> justification for *any* minimum allocation size?"

While it is a bit of a reductio ad absurdum argument, consider what
(could) happen if the minimum were a /32.

Everyone with a computer can justify a single address.  There's no
way global backbone routers can support a prefix per-user, even for
a modest amount of users.  Many of these users would be single
homed, taking the main advantage of a portable /32 as being a
"vanity" IP address.  Presumably the price for a single address
would be so low (see cost of domain names) a substantial number of
people would not see the price as a barrier.  Even if direct providers
wouldn't route these (e.g. Cable/DSL providers), it's likely tunnel
brokers could offer services to end users for modest costs.

I think many folks miss the most important item though when considering
the effects of minimum allocation size, or other polices that are
likely to affect the size of the global table.  The single most
important thing is predictability.  ISP's are buying equipment now
based on growth assumptions.  They want that equipment to have a
reasonable lifespan (3, 5, 7 years?).  If our policies and actions
allow them to predict with reasonable accuracy that the table will
be 500k routes in 3 years, and 700k routes in 5 years, and they can
buy a 1M route box, well then all is good.

But if they bought that box yesterday, and today we change the
policy such that in 3 years there are 1M routes then that ISP is
going to be in a huge bind.  It's either going to have to spend a
lot of capital early, or it's going to have to drop routes.

We've had a trend of lowering the minimum allocation nice and slowly
over the past 5-7 years, and we've been carefully watching the
results.  I think this is generally the prudent course of action,
there is a huge penality for overshooting in terms of disruption
to the global network.

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

From bmanning at vacation.karoshi.com  Thu Jul 30 14:01:33 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 30 Jul 2009 18:01:33 +0000
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730175643.GB76331@ussenterprise.ufp.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
Message-ID: <20090730180133.GB5849@vacation.karoshi.com.>

On Thu, Jul 30, 2009 at 01:56:43PM -0400, Leo Bicknell wrote:
> In a message written on Thu, Jul 30, 2009 at 12:19:19PM -0500, George, Wes E [NTK] wrote:
> > To the question of "existing filters/inertia aside, is there a
> > justification for *any* minimum allocation size?"
> 
> While it is a bit of a reductio ad absurdum argument, consider what
> (could) happen if the minimum were a /32.


	kind of like what happens when we give out everyone a /32
	of IPv6 space.  your arguments are identical for either 
	an IPv4 or IPv6 /32.  

	and yet we find it acceptable to hand out /32's in one space...

--bill

> 
> Everyone with a computer can justify a single address.  There's no
> way global backbone routers can support a prefix per-user, even for
> a modest amount of users.  Many of these users would be single
> homed, taking the main advantage of a portable /32 as being a
> "vanity" IP address.  Presumably the price for a single address
> would be so low (see cost of domain names) a substantial number of
> people would not see the price as a barrier.  Even if direct providers
> wouldn't route these (e.g. Cable/DSL providers), it's likely tunnel
> brokers could offer services to end users for modest costs.
> 
> I think many folks miss the most important item though when considering
> the effects of minimum allocation size, or other polices that are
> likely to affect the size of the global table.  The single most
> important thing is predictability.  ISP's are buying equipment now
> based on growth assumptions.  They want that equipment to have a
> reasonable lifespan (3, 5, 7 years?).  If our policies and actions
> allow them to predict with reasonable accuracy that the table will
> be 500k routes in 3 years, and 700k routes in 5 years, and they can
> buy a 1M route box, well then all is good.
> 
> But if they bought that box yesterday, and today we change the
> policy such that in 3 years there are 1M routes then that ISP is
> going to be in a huge bind.  It's either going to have to spend a
> lot of capital early, or it's going to have to drop routes.
> 
> We've had a trend of lowering the minimum allocation nice and slowly
> over the past 5-7 years, and we've been carefully watching the
> results.  I think this is generally the prudent course of action,
> there is a huge penality for overshooting in terms of disruption
> to the global network.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/



> _______________________________________________
> 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 bicknell at ufp.org  Thu Jul 30 14:15:14 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 30 Jul 2009 14:15:14 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730180133.GB5849@vacation.karoshi.com.>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<20090730180133.GB5849@vacation.karoshi.com.>
Message-ID: <20090730181514.GB79116@ussenterprise.ufp.org>

In a message written on Thu, Jul 30, 2009 at 06:01:33PM +0000, bmanning at vacation.karoshi.com wrote:
> > While it is a bit of a reductio ad absurdum argument, consider what
> > (could) happen if the minimum were a /32.
> 
> 
> 	kind of like what happens when we give out everyone a /32
> 	of IPv6 space.  your arguments are identical for either 
> 	an IPv4 or IPv6 /32.  
> 
> 	and yet we find it acceptable to hand out /32's in one space...

Bzzt.  Thanks for playing.  Please pick up a lovely parting gift on your
way out the door.

The IPv6 analogy to what I described is handing out a /128 to each
individual, which again, is not supportable.

A /32 of IPv6 space connects multiple users.  A /32 of IPv4 space does
not.  It's nice to note there are 2^32 of both, but the IPv6 network
sitll connects 2^96 more users than the IPv4 network.  The only way your
statement could be true is if someone was advocating giving IPv4 /32's
to individual end users, which no one has done.

FUD, total FUD.

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

From jlewis at lewis.org  Thu Jul 30 14:20:49 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 30 Jul 2009 14:20:49 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730180133.GB5849@vacation.karoshi.com.>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<20090730180133.GB5849@vacation.karoshi.com.>
Message-ID: <Pine.LNX.4.61.0907301411060.4187@soloth.lewis.org>

On Thu, 30 Jul 2009 bmanning at vacation.karoshi.com wrote:

> On Thu, Jul 30, 2009 at 01:56:43PM -0400, Leo Bicknell wrote:
>> In a message written on Thu, Jul 30, 2009 at 12:19:19PM -0500, George, Wes E [NTK] wrote:
>>> To the question of "existing filters/inertia aside, is there a
>>> justification for *any* minimum allocation size?"
>>
>> While it is a bit of a reductio ad absurdum argument, consider what
>> (could) happen if the minimum were a /32.
>
>
> 	kind of like what happens when we give out everyone a /32
> 	of IPv6 space.  your arguments are identical for either
> 	an IPv4 or IPv6 /32.
>
> 	and yet we find it acceptable to hand out /32's in one space...

The difference being, v6 is so much bigger than v4 that the idea seems to 
be to give each network (whether that's an RIR allocating to an LIR, or an 
LIR assigning to a customer) more space than they could possibly use in 
the forseeable future with idea that v6 is so vast we're not going to run 
out, so give them their one big block now and be done with it.  After 
years of being conservative with v4 assignment, this is kind of a hard 
transition to make...and only time will tell if its a repeat of the 
mistakes made in the early days of v4 when big blocks were handed out and 
PI space was given to anyone who filled out the right template.

>> Everyone with a computer can justify a single address.  There's no
>> way global backbone routers can support a prefix per-user, even for
>> a modest amount of users.  Many of these users would be single
>> homed, taking the main advantage of a portable /32 as being a
>> "vanity" IP address.  Presumably the price for a single address

I don't think anyone is suggesting lowering the minimum allocation size 
for single homed networks.  If so, I missed that.

>> I think many folks miss the most important item though when considering
>> the effects of minimum allocation size, or other polices that are
>> likely to affect the size of the global table.  The single most
>> important thing is predictability.  ISP's are buying equipment now
>> based on growth assumptions.  They want that equipment to have a
>> reasonable lifespan (3, 5, 7 years?).  If our policies and actions

What good is your 7 year life router if you can't get any more IP 
addresses to route through it after 3 years?

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


From bmanning at vacation.karoshi.com  Thu Jul 30 14:24:07 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 30 Jul 2009 18:24:07 +0000
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730181514.GB79116@ussenterprise.ufp.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<20090730180133.GB5849@vacation.karoshi.com.>
	<20090730181514.GB79116@ussenterprise.ufp.org>
Message-ID: <20090730182407.GC5849@vacation.karoshi.com.>

On Thu, Jul 30, 2009 at 02:15:14PM -0400, Leo Bicknell wrote:
> In a message written on Thu, Jul 30, 2009 at 06:01:33PM +0000, bmanning at vacation.karoshi.com wrote:
> > > While it is a bit of a reductio ad absurdum argument, consider what
> > > (could) happen if the minimum were a /32.
> > 
> > 
> > 	kind of like what happens when we give out everyone a /32
> > 	of IPv6 space.  your arguments are identical for either 
> > 	an IPv4 or IPv6 /32.  
> > 
> > 	and yet we find it acceptable to hand out /32's in one space...
> 
> Bzzt.  Thanks for playing.  Please pick up a lovely parting gift on your
> way out the door.

	not at all young man... there are exacatly the same number
	of /32s in IPv4 and IPv6.  but since you know best, i'll 
	sit back and watch the fireworks.


> FUD, total FUD.

	and a FIB entry is a FIB entry.  otherwise, I couldn't 
	agree with you more.

> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440

--bill


From tedm at ipinc.net  Thu Jul 30 15:56:15 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 30 Jul 2009 12:56:15 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <Pine.LNX.4.61.0907301411060.4187@soloth.lewis.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>	<20090730175643.GB76331@ussenterprise.ufp.org>	<20090730180133.GB5849@vacation.karoshi.com.>
	<Pine.LNX.4.61.0907301411060.4187@soloth.lewis.org>
Message-ID: <4A71FADF.9090605@ipinc.net>

Jon Lewis wrote:
> On Thu, 30 Jul 2009 bmanning at vacation.karoshi.com wrote:
> 
>> On Thu, Jul 30, 2009 at 01:56:43PM -0400, Leo Bicknell wrote:
>>> In a message written on Thu, Jul 30, 2009 at 12:19:19PM -0500, 
>>> George, Wes E [NTK] wrote:
>>>> To the question of "existing filters/inertia aside, is there a
>>>> justification for *any* minimum allocation size?"
>>>
>>> While it is a bit of a reductio ad absurdum argument, consider what
>>> (could) happen if the minimum were a /32.
>>
>>
>>     kind of like what happens when we give out everyone a /32
>>     of IPv6 space.  your arguments are identical for either
>>     an IPv4 or IPv6 /32.
>>
>>     and yet we find it acceptable to hand out /32's in one space...
> 
> The difference being, v6 is so much bigger than v4 

With IPv6 the host identifer portion of the address is 64 bits to
allow stateless autoconfiguration - essentially, using the MAC
address as the host ID.  THAT is why each subnet is so large.

It's a clever way to simplify and
get rid of DHCP servers and makes a huge amount of sense in some
instances.

Take a look at the following:

http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/
http://weblog.chrisgrundemann.com/index.php/2009/address_space-mac_v_ip/

As Chris says in the first link:

"...So, while there may be well over an octillion times more individual 
IPv6 addresses than there are IPv4 addresses; in terms of actual 
usability, IPv6 is only somewhere in the range of 16 million to 17 
billion times larger than IPv4.  Much larger, yes; infinite, no...."

Ted


From bill at herrin.us  Thu Jul 30 17:48:06 2009
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jul 2009 17:48:06 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730175643.GB76331@ussenterprise.ufp.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>

On Thu, Jul 30, 2009 at 1:56 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> I think many folks miss the most important item though when considering
> the effects of minimum allocation size, or other polices that are
> likely to affect the size of the global table.

Hi Leo,

If I may draw it back to the question I started with: Can you offer a
well grounded reason to believe that changing the minimum allocation
size for *multihomed* systems is likely to affect the size of the
global table?

The only one I've been able to come up with goes something along the
lines of, "If we reduce the minimum allocation size, more folks will
multihome yielding more table consumption." That seems pretty weak in
light of NRPM 4.2.3.6.

A couple of folks have said something along the lines of "you can
aggregate mutlihomed users anyway," but as you know those arguments
turn on some basic misunderstandings about how BGP works.

Another suggested that the minimums allow a convenient place to filter
when trying to preserve older hardware a little longer, but as you
know such filtering is just as functional (or dysfunctional) at any
prefix size, not just the RIR minimums. At most, the RIR minimums give
the BOFH somewhere to [disingenuously] point his finger when his
customers complain.

Like you, still others have pointed out that if every single-homed
user announced a route the Internet would collapse. That is not in
dispute. RIRs assigning addresses to single-homed users would increase
the route table size. PI for single-homed users is frankly a
discussion for another era. In BGP/IPv4, that ship has sailed. My
question covers only multihomed uses, and my real focus is multivendor
multihomed uses where route aggregation is impractical regardless of
who assigns the addresses.

So can you offer a justifiable reason to believe that changing the RIR
minimum allocation size for *multihomed* systems is likely to affect
the size of the global table?

Regards,
Bill


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


From farmer at umn.edu  Thu Jul 30 17:58:05 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 30 Jul 2009 16:58:05 -0500
Subject: [arin-ppml] IPv4 Run Out Proposals
In-Reply-To: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>
References: <4A6DB5A0.15293.F1DAB50@farmer.umn.edu>
Message-ID: <4A71D11D.16321.6D69D78@farmer.umn.edu>

On 27 Jul 2009 David Farmer wrote:

> I've been meaning to ask this for several weeks now, where 
> has the summer gone?
> 
> Leo and I are the AC Shepards for the two IPv4 Run Out 
> Proposals, they are;
> 
> 93. Predicable IPv4 Run Out by Prefix Size 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014635.html
> 
> 94. Predictable IPv4 Run Out by Allocation Window
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014392.html
> 
> Leo, I, and I believe much of the AC, think that these proposals 
> shouldn't move forward separately, but that one or the other, or 
> a merged version of the two, should move forward to Draft 
> Policy to be discussed at ARIN XXIV in Dearborn.
> 
> Therefore, Leo and I would like feed back on these two 
> proposals, and your ideas on the following options;
> 
> 1. Should they be merged together and move forward as a 
> single Draft Policy?
> 
> 2. Should "Predicable IPv4 Run Out by Prefix Size" move 
> forward to Draft Policy alone?
> 
> 3. Should "Predictable IPv4 Run Out by Allocation Window" 
> move forward to Draft Policy alone?
> 
> 4. Should they move forward as two separate Draft Policies?
> 
> 5. Should they both be abandoned? 

I've only received feedback from a few of you but what I have 
seems to mostly support the idea of merging the two and 
moving forward with that.
 
> In order to make it on to the agenda for Dearborn, Draft Policy 
> text must be ready for Staff and Legal Review by the end of 
> this week.  
> 
> So please get any suggestions you have in as soon as 
> possible, I'm going to start on a merged version of the text in 
> case the consensus is to go that way, I will share it on PPML in 
> the next day or two.
> 
> Thank you for your feed back.

Here is the merged text I've been working on, including 
incorporating comments about changing the first part from 
dates to thresholds based on the number of /8s IANA has left.  

Please get me any additional comments ASAP;

1. Policy Proposal Name: Equitable IPv4 Run-Out

2. Proposal Originator:
	a. name:  David Farmer
	b. email:  farmer at umn.edu
	c. telephone:  612-626-0815
	d. organization:  University of Minnesota

3. Proposal Version: 1.2

4. Date: 30 July 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Replace the text in NRPM 4.2.4.4 with:

After an organization has been a subscriber member of ARIN 
for one year, they may choose to request up to a 12 month 
supply of IP addresses.  

As the IANA free pool decreases, the length of supply that an 
organization may request will be reduced at the following 
thresholds.  This reduction does not apply to resources 
received via Transfers to Specified Recipients per section 8.3, 
in this case an organization may continue choose to request up 
to a 12 month supply of IP addresses.

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

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


Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and following 
Run-Out

When ARIN receives its last /8, by IANA implementing section 
10.4.2.2, a proportionally decreasing maximum allocation, and 
assignment, size will be put into effect.  The maximum 
allocation will be the next whole CIDR prefix less than or equal 
to one quarter (1/4) of the total ARIN free pool available at the 
time of each allocation, but no longer than the applicable 
minimum allocation.

An OrgID may request additional resources when it can 
demonstrate it has properly utilized all previous allocations per 
applicable policies.  However, the total of all allocations 
received within the last three (3) month period and the current 
request, cannot exceed the current maximum allocation size.

This maximum allocation size is applicable to allocations from 
the ARIN free pool only, and is explicitly not applicable to 
resources received through Transfers to Specified Recipients 
per section 8.3, or any other specially designated resources.

8. Rationale:

This proposed policy is intended to ensure an equitable 
distribution of IPv4 resources as run-out of the IANA free pool 
and subsequently the ARIN free pool occurs.  This is achieved 
in two parts; first, changing NRPM section 4.2.4.4 to reduce 
the length of supply of IPv4 resources that may be requested 
in steps as the IANA free pool runs-out.  This helps accomplish 
equity by reducing the window that an advantage or 
disadvantage can exist between competitors, that will be 
created when one competitor receives a final allocation just 
before run-out and another competitor does not.   

The first part of this policy is similar to ideas in RIPE policy 
proposal 2009-03 
(http://www.ripe.net/ripe/policies/proposals/2009-03.html), and 
has been adapted by discussion and for use within the ARIN 
region.

The second part of this policy, allows a maximum of one 
quarter (1/4) of the then current total IPv4 resources to be 
allocated in a single request, once ARIN has received its last /8 
from IANA.  This helps achieve equity by ensuring the 
available resources are spread among multiple organizations 
and that no single organization may monopolize all of the 
resources available through a single request, at least until the 
maximum allocation size has been reduced down to the 
minimum allocation size.

Incrementally reducing the length of supply and then reducing 
the maximum allocation size in proportion to the amount of 
resources available should minimize, or possibly eliminate, the 
need to fulfill requests with multiple smaller blocks.

As in the current NRPM, the length of supply only applies to 
ISP allocations.  However, the maximum allocation size is 
intended to apply to both ISP allocations and End-user 
assignments.

This policy is intended to be independent of other policies or 
proposals to reserve address space for IPv6 transition or other 
purposes.  Neither part is intended to limit Transfers to 
Specified Recipients per section 8.3 of the NRPM.

The current maximum allocation size should be published on 
the ARIN website, preferably in real-time, as it may change 
rapidly as the ARIN free pool resources are exhausted.  In the 
worst-case the maximum allocation size will decrease every 
forth allocation, when all four are the then current maximum 
allocation size.  However, in the beginning there will likely be 
many smaller allocations before the maximum allocation size is 
decreased, accelerating as the resources are exhausted.

Following the run-out phase, this policy provides an equitable 
means of distribution of resources if or when additional 
resources become available after ARIN has initially exhausted 
such resources.  Such as if resources are returned, recovered 
by other means, or additional resources are obtained from 
IANA.  Further, whenever ARIN receives a sufficiently large 
amount of additional resources, this policy intends for the 
maximum allocation size to be increased accordingly.

After ARIN receives its last /8, the intent is to normally limit an 
organization to a single maximum allocation within a three 
month period.  However, saying it that simply opens this policy 
to gamesmanship in requesting less than a maximum 
allocation.  Requiring a maximum allocation to cover new 
requests and all allocations received in the previous three 
month period, should eliminate this kind of gamesmanship.

There is a beneficial side effect of stating it this way, in the 
special situation when the maximum allocation size is 
increased, due to ARIN obtaining a sufficiently large amount of 
additional resources, an organization may receive additional 
resources earlier than the normal three month period.  But, 
only in this special situation and when an organization properly 
utilizes a previous maximum allocation in less than three 
months, may an organization receive additional resources in 
less than the normal three month period.

Other ratios, such as one half (1/2) or one eighth (1/8) could be 
considered.  One eighth (1/8) would provide greater assurance 
of eliminating the need to use multiple blocks to fulfill requests 
and ensure a greater number of organizations receive 
resources.  However, one eighth (1/8) is more likely to be seen 
as rationing and an attempt to artificially extend the lifetime of 
IPv4.  During the ARIN XXIII policy discussion there seemed to 
be a consensus that attempts to extend the lifetime of IPv4 
resources would be undesirable.  While on the other hand, one 
half (1/2) is even less likely to ration resources, but it would 
likely result in the resource being spread across significantly 
fewer organizations and increase the need to use multiple 
blocks to fulfill requests.

In conclusion, combining the final 3 month length of supply 
with the one quarter (1/4) ratio provides roughly an annualized 
equivalent of the whole ARIN free pool being made available to 
a single organization.  While it is not possible for a single 
organization to receive the whole ARIN free pool within one 
year under this policy, it is a virtual certainty that multiple 
organization will be requesting resources, and that the ARIN 
free pool will not likely last a full year following the exhaustion 
of the IANA free pool anyway.  Therefore, the ratio one quarter 
(1/4) seems to strike a balance between making resources 
available with as little restriction as possible and ensuring an 
equitable distribution of those resources during and following 
the run-out phase.

EDITORIAL NOTE:
This Draft Policy 2009-X merges ideas from two separate 
policy proposals, 93. Predicable IPv4 Run Out by Prefix Size 
and 94. Predictable IPv4 Run Out by Allocation Window.

9. Timetable for implementation:  Immediate



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



From bicknell at ufp.org  Thu Jul 30 18:46:04 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 30 Jul 2009 18:46:04 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
Message-ID: <20090730224604.GA98939@ussenterprise.ufp.org>

In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400, William Herrin wrote:
> If I may draw it back to the question I started with: Can you offer a
> well grounded reason to believe that changing the minimum allocation
> size for *multihomed* systems is likely to affect the size of the
> global table?

I believe it is reasonable to assume each decrease in prefix size
allows more orgs to qualify, and thus increases the routing table.
Now it may be we only add 1000 orgs, of which 800 previously were
multi-homing with cutouts, so the net is 200 routes, but that doesn't
mean it's not a decrease.

Your question can't be framed in the absolute.  At each size can I
find one person who chooses to multi-home who didn't add to the
routing table under the previous system?  Absolutely.  Is the number
significant, well, that's what we argue about.

Personally I believe if an org can demonstrate it has multi-homed
BGP connectivity (tunnels don't count, etc) they should probably
be able to get a prefix from ARIN.  However, even with that belief I
don't support any drastic moves in the prefix size, worried there is
some tipping point out there where the balance changes radically.

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

From owen at delong.com  Thu Jul 30 19:05:25 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Jul 2009 16:05:25 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730224604.GA98939@ussenterprise.ufp.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
	<20090730224604.GA98939@ussenterprise.ufp.org>
Message-ID: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com>


On Jul 30, 2009, at 3:46 PM, Leo Bicknell wrote:

> In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400,  
> William Herrin wrote:
>> If I may draw it back to the question I started with: Can you offer a
>> well grounded reason to believe that changing the minimum allocation
>> size for *multihomed* systems is likely to affect the size of the
>> global table?
>
> I believe it is reasonable to assume each decrease in prefix size
> allows more orgs to qualify, and thus increases the routing table.
> Now it may be we only add 1000 orgs, of which 800 previously were
> multi-homing with cutouts, so the net is 200 routes, but that doesn't
> mean it's not a decrease.
>
I don't get this...

Under current policy, any org that multihomes qualifies for a /24 from  
their
upstream.

Given that, any org that multihomes already qualifies to put a route  
in the
DFZ.

What increase are you concerned about that is added by moving the ARIN
boundary from /22 to /24?

Today, they can save $100/year and get space from an upstream that
they don't pay ARIN for, as well as getting a  /24 even if they want to
multihome a single host.  That's CURRENT ARIN policy.

If we move the boundary to /24, then, in addition to that option,  
networks
that have ~128 - ~400 hosts would gain the option of applying to ARIN
and getting a /24 or /23 to multihome with that was independent of
both of their providers.

Why would someone who is not willing to multihome for $100 less
pay $100 more to multihome _AND_ jump through more hoops just
because we changed the ARIN boundary?

Owen

>
>
> Personally I believe if an org can demonstrate it has multi-homed
> BGP connectivity (tunnels don't count, etc) they should probably
> be able to get a prefix from ARIN.  However, even with that belief I
> don't support any drastic moves in the prefix size, worried there is
> some tipping point out there where the balance changes radically.
>

Given we are at /22 and there are only 10 bits left... Please define
drastic in that context.  Is the 2 bits being discussed drastic?

Owen

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

From bill at herrin.us  Thu Jul 30 19:14:32 2009
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jul 2009 19:14:32 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090730224604.GA98939@ussenterprise.ufp.org>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>
	<F7EB0A7C707E39409A73CD0353242551A7F423D4D5@PLSWM01C.ad.sprint.com>
	<20090730175643.GB76331@ussenterprise.ufp.org>
	<3c3e3fca0907301448u13533b16k40eb2b2bbb6fb2c2@mail.gmail.com>
	<20090730224604.GA98939@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>

On Thu, Jul 30, 2009 at 6:46 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400, William Herrin wrote:
>> If I may draw it back to the question I started with: Can you offer a
>> well grounded reason to believe that changing the minimum allocation
>> size for *multihomed* systems is likely to affect the size of the
>> global table?
>
> I believe it is reasonable to assume each decrease in prefix size
> allows more orgs to qualify, and thus increases the routing table.

Hi Leo,

How do you figure that "more ARIN qualifying orgs = increased routing
table" is a reasonable assumption?

Let me rephrase the question by expanding your assumption a little bit:

1. Multivendor multihomed user connects to the Internet.
2. User announces his ISP /24 via BGP.
3. User qualifies for an ARIN /24
4. ...
5. ...
6. User announces more than just one /24.

What are steps 4 and 5 that get you from qualifying for an ARIN /24 to
consuming extra BGP slots?


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 mksmith at adhost.com  Thu Jul 30 20:10:26 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Thu, 30 Jul 2009 17:10:26 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com>
Message-ID: <C6978482.971EB%mksmith@adhost.com>




On 7/30/09 4:05 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
> On Jul 30, 2009, at 3:46 PM, Leo Bicknell wrote:
> 
>> In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400, William Herrin
>> wrote:
>>> If I may draw it back to the question I started with: Can you offer a
>>> well grounded reason to believe that changing the minimum allocation
>>> size for *multihomed* systems is likely to affect the size of the
>>> global table?
>> 
>> I believe it is reasonable to assume each decrease in prefix size
>> allows more orgs to qualify, and thus increases the routing table.
>> Now it may be we only add 1000 orgs, of which 800 previously were
>> multi-homing with cutouts, so the net is 200 routes, but that doesn't
>> mean it's not a decrease.
>> 
> I don't get this...
> 
> Under current policy, any org that multihomes qualifies for a /24 from their
> upstream.
> 
> Given that, any org that multihomes already qualifies to put a route in the
> DFZ.
> 
> What increase are you concerned about that is added by moving the ARIN
> boundary from /22 to /24?
> 
> Today, they can save $100/year and get space from an upstream that
> they don't pay ARIN for, as well as getting a  /24 even if they want to
> multihome a single host.  That's CURRENT ARIN policy.
> 
> If we move the boundary to /24, then, in addition to that option, networks
> that have ~128 - ~400 hosts would gain the option of applying to ARIN
> and getting a /24 or /23 to multihome with that was independent of
> both of their providers.
> 
> Why would someone who is not willing to multihome for $100 less
> pay $100 more to multihome _AND_ jump through more hoops just
> because we changed the ARIN boundary?
> 
> Owen
> 
Are you saying you think that a small provider with a upstream-provided /24
wouldn't want to jump through the hoops to be provider independent?  In the
past, I've been in just this type of position, advertising multiple /24's
assigned from upstreams until I could justify a /20 from ARIN.  If I had the
opportunity to number out of a /24 instead of waiting until I had a /22 I
would have jumped at the chance.

What was the rationale for the /20 in the first place?  Was it more than an
arbitrary number?  I can't see any detraction from getting providers to get
an ARIN-assigned /24 instead of having to get a /24 from one provider and
route it out another, being historically on the "purchasing" side of that
arrangement.  The only downside I can see is providers that think having a
customer with their assigned space somehow binds them together, fiscally
speaking.

Regards,

Mike



From farmer at umn.edu  Thu Jul 30 20:17:20 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 30 Jul 2009 19:17:20 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
References: <3c3e3fca0907270903pdb0bdbbg1015d36a5367e426@mail.gmail.com>,
	<20090730224604.GA98939@ussenterprise.ufp.org>,
	<3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
Message-ID: <4A71F1C0.999.7561B2A@farmer.umn.edu>

On 30 Jul 2009 William Herrin wrote:

> On Thu, Jul 30, 2009 at 6:46 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> > In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400, William Herrin wrote:
> >> If I may draw it back to the question I started with: Can you offer a
> >> well grounded reason to believe that changing the minimum allocation
> >> size for *multihomed* systems is likely to affect the size of the
> >> global table?
> >
> > I believe it is reasonable to assume each decrease in prefix size
> > allows more orgs to qualify, and thus increases the routing table.
> 
> Hi Leo,
> 
> How do you figure that "more ARIN qualifying orgs = increased routing
> table" is a reasonable assumption?
> 
> Let me rephrase the question by expanding your assumption a little bit:
> 
> 1. Multivendor multihomed user connects to the Internet.
> 2. User announces his ISP /24 via BGP.
> 3. User qualifies for an ARIN /24
> 4. ...
> 5. ...
> 6. User announces more than just one /24.
> 
> What are steps 4 and 5 that get you from qualifying for an ARIN /24 to
> consuming extra BGP slots?

You are assuming that the number of multi-homed users will remain a 
constant, if you allow a multi-home user with a PA based /24 from a provider 
to switch to a PI based /24 from ARIN.  It is entirely possible that the 
availability of PI /24s from ARIN for multi-homing could create an inducement 
for more users to multi-home, just so they can get PI space.  

Personally, I'm not sure this would actually be a bad thing.  But, the 
inducement of PI space is the kind of thing that could cause Leo's tipping.  
I'm not sure that a PI /24s are enough inducement to cause a flood of users 
to want to become multi-homed.  But, I would discount it out of hand either, 
and with an AC hat on it is enough to make me worry at least a little bit.

None of us can prove it will be a problem, but none of us can prove it won't 
be a problem either.

That said, there are ways we could mitigate the possibility of a flood, we 
could require someone who wants to get a PI /24 for multi-homing to have 
multi-homed for a year using PA space.  This wouldn't totally prevent 
someone from multi-homing solely to get PI space, but it would prevent 
instant gratification for those that would try it, and maybe make them think 
twice about it.

As a general concept I support making PI space available to end users and 
smaller providers too, but we can break the Internet doing it.




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



From bill at herrin.us  Thu Jul 30 20:39:32 2009
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jul 2009 20:39:32 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <C6978482.971EB%mksmith@adhost.com>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com>
	<C6978482.971EB%mksmith@adhost.com>
Message-ID: <3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>

On Thu, Jul 30, 2009 at 8:10 PM, Michael K. Smith<mksmith at adhost.com> wrote:
>?In the
> past, I've been in just this type of position, advertising multiple /24's
> assigned from upstreams until I could justify a /20 from ARIN. ?If I had the
> opportunity to number out of a /24 instead of waiting until I had a /22 I
> would have jumped at the chance.

Hi Michael,

Does that mean you actually used *less* BGP slots after getting your
ARIN addresses? So in your case, current ARIN policy was actually
counterproductive to its goal, causing you to announce *more* routes,
yes?


On Thu, Jul 30, 2009 at 8:17 PM, David Farmer<farmer at umn.edu> wrote:
> You are assuming that the number of multi-homed users will remain a
> constant, if you allow a multi-home user with a PA based /24 from a provider
> to switch to a PI based /24 from ARIN.  It is entirely possible that the
> availability of PI /24s from ARIN for multi-homing could create an inducement
> for more users to multi-home, just so they can get PI space.

Hi David,

Interesting. How could we mitigate this risk in a potential policy?
You suggested requiring them to multihome for a year with PA space
first. What about something more direct like requiring some fair
minimum annual payment for their Internet services to weed out the
serious folks from the DSL posers? Let's brainstorm. Are there more
ways to mitigate this problem?

Thanks,
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 bicknell at ufp.org  Thu Jul 30 23:30:41 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 30 Jul 2009 23:30:41 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <4A71F1C0.999.7561B2A@farmer.umn.edu>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
Message-ID: <20090731033041.GA14598@ussenterprise.ufp.org>

In a message written on Thu, Jul 30, 2009 at 07:17:20PM -0500, David Farmer wrote:
> You are assuming that the number of multi-homed users will remain a 
> constant, if you allow a multi-home user with a PA based /24 from a provider 
> to switch to a PI based /24 from ARIN.  It is entirely possible that the 
> availability of PI /24s from ARIN for multi-homing could create an inducement 
> for more users to multi-home, just so they can get PI space.  

David summed it up well, however, a few notes.

If a network multihomes with a subnet of a PA block and someone
somewhere else in the routing table filters that route but not the
PA block, there is still full reachability.  If someone multihomes
with a PI block and that same person filters the same route, there
is no reachability.

Thus the size of the set of all routes is the same; but the size
of the filtered routes but still global reachability set is reduced.
There are a number of people trying to use the second set.

While the most traveled road is Multihome with PA, then Multihome
with PI, there are plenty of folks who single home with PA (no
global routing table slot) until they can qualify for an ARIN PI
block, then they multi-home.  There are users who go from nothing
to multi-homed; for instance startups who make sure they qualify
day 1 for a multi-homed prefix.  Presumably if the barrier was lower
more would do so.

I suspect many of the folks on this list would spend a lot more
effort trying to multi-home if they could get 1 /32 from ARIN for
$10 per year.  The number of cable modem and DSL customers asking
their providers for BGP would skyrocket.  It's not because those
folks are multi-homed with PA space today.

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

From bill at herrin.us  Fri Jul 31 10:17:59 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jul 2009 10:17:59 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090731033041.GA14598@ussenterprise.ufp.org>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>

On Thu, Jul 30, 2009 at 11:30 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> If a network multihomes with a subnet of a PA block and someone
> somewhere else in the routing table filters that route but not the
> PA block, there is still full reachability. ?If someone multihomes
> with a PI block and that same person filters the same route, there
> is no reachability.
> Thus the size of the set of all routes is the same; but the size
> of the filtered routes but still global reachability set is reduced.
> *There are a number of people trying to use the second set.*

Leo,

I'll ask you the same question I asked Jon: Who?

People vote with their feet. In 2009, those feet have voted as
unanimously as we can detect against filtering on the RIR minimums
without also employing a default route to a transit provider that
doesn't.

Seriously, if you know of an ISP that's filtering on RIR minimums and
relying on announced covering routes (with no default route) to catch
the missing routes, I'd like to know who so I can go win an argument
with one of my transit providers about which space to assign me.


> While the most traveled road is Multihome with PA, then Multihome
> with PI, there are plenty of folks who single home with PA (no
> global routing table slot) until they can qualify for an ARIN PI
> block, then they multi-home.

I've encountered something like this exactly twice. In both cases they
were multiply single-homed with a malfunctioning network. I was
brought in to clean up my predecessor's mess.

That the /22 policy encourages folks to screw up their networks is
hardly a point in its favor.


> I suspect many of the folks on this list would spend a lot more
> effort trying to multi-home if they could get 1 /32 from ARIN for
> $10 per year. ?The number of cable modem and DSL customers asking
> their providers for BGP would skyrocket. ?It's not because those
> folks are multi-homed with PA space today.

Straw man. We're talking about /24's not /32's. And $10 per year
doesn't buy you BGP with any ISP I've ever talked to. Further, with
the right language in a /24 policy we can, if we want to, make sure it
never does.

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 mksmith at adhost.com  Fri Jul 31 11:39:28 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 31 Jul 2009 08:39:28 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com><C6978482.971EB%mksmith@adhost.com>
	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, July 30, 2009 5:40 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Thu, Jul 30, 2009 at 8:10 PM, Michael K. Smith<mksmith at adhost.com>
> wrote:
> >?In the
> > past, I've been in just this type of position, advertising multiple
> /24's
> > assigned from upstreams until I could justify a /20 from ARIN. ?If I
> had the
> > opportunity to number out of a /24 instead of waiting until I had a
> /22 I
> > would have jumped at the chance.
> 
> Hi Michael,
> 
> Does that mean you actually used *less* BGP slots after getting your
> ARIN addresses? So in your case, current ARIN policy was actually
> counterproductive to its goal, causing you to announce *more* routes,
> yes?
> 
> 
That is correct.  When we went to ARIN space, this was in 1995 mind you, we went from 6 announced PA blocks to one PI block.  But, we had to keep getting PA blocks until we could justify the block from ARIN.  This happened again in 2000 with another company when we went from 4 PA blocks to one PI block.

Regards,

Mike




From bill at herrin.us  Fri Jul 31 11:47:20 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jul 2009 11:47:20 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com>
	<C6978482.971EB%mksmith@adhost.com>
	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
Message-ID: <3c3e3fca0907310847w6cc1f0e3v94610fe5d199e162@mail.gmail.com>

On Fri, Jul 31, 2009 at 11:39 AM, Michael K. Smith -
Adhost<mksmith at adhost.com> wrote:
> That is correct. ?When we went to ARIN space, this was in
>1995 mind you, we went from 6 announced PA blocks to
>one PI block. ?But, we had to keep getting PA blocks until
> we could justify the block from ARIN. ?This happened again
> in 2000 with another company when we went from 4 PA
> blocks to one PI block.

Hi Michael,

So, I'm thinking that if we craft a /24 policy, we should probably try
to preserve the good part of that (that once you got a /20 you had
only one block that you could announce as an aggregate) while
eliminating the bad part (that before you could justify a /20 you were
announcing 6 disaggregate routes). Sound reasonable?

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 mksmith at adhost.com  Fri Jul 31 11:48:14 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 31 Jul 2009 08:48:14 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <10FB8CDC4B3B784AACD5C45FCB395A217AF42156@xenon.corp.clearfly.net>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com><C6978482.971EB%mksmith@adhost.com><3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
	<10FB8CDC4B3B784AACD5C45FCB395A217AF42156@xenon.corp.clearfly.net>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B843@ad-exh01.adhost.lan>



> -----Original Message-----
> From: Ken Mix [mailto:Ken.Mix at clearfly.net]
> Sent: Friday, July 31, 2009 8:45 AM
> To: Michael K. Smith - Adhost; William Herrin
> Cc: ARIN PPML
> Subject: RE: [arin-ppml] Rationale for /22
> 
> So if you'd been able to get PI /24s, you'd still be announcing those
> individual blocks instead of a single, larger block?
> 
> Ken
> 
My assumption is that I would aggregate up much in the same way I do
now.  If I was in a position to justify subsequent /24's I would get a
/23, then a /22 and so on.  Hopefully ARIN would reserve at least one
block higher for each /24 deployment with the assumption a small
provider would probably get to a /23.  If I got /24's from ARIN, I would
have returned the PA blocks as part of the process.  Why would I keep PA
space when I was getting PI space?

Regards,

Mike


From Ken.Mix at clearfly.net  Fri Jul 31 11:45:27 2009
From: Ken.Mix at clearfly.net (Ken Mix)
Date: Fri, 31 Jul 2009 09:45:27 -0600
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com><C6978482.971EB%mksmith@adhost.com>
	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
Message-ID: <10FB8CDC4B3B784AACD5C45FCB395A217AF42156@xenon.corp.clearfly.net>

So if you'd been able to get PI /24s, you'd still be announcing those individual blocks instead of a single, larger block?

Ken

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith - Adhost
Sent: Friday, July 31, 2009 09:39
To: William Herrin; ARIN PPML
Subject: Re: [arin-ppml] Rationale for /22



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Thursday, July 30, 2009 5:40 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Thu, Jul 30, 2009 at 8:10 PM, Michael K. Smith<mksmith at adhost.com>
> wrote:
> >?In the
> > past, I've been in just this type of position, advertising multiple
> /24's
> > assigned from upstreams until I could justify a /20 from ARIN. ?If I
> had the
> > opportunity to number out of a /24 instead of waiting until I had a
> /22 I
> > would have jumped at the chance.
> 
> Hi Michael,
> 
> Does that mean you actually used *less* BGP slots after getting your
> ARIN addresses? So in your case, current ARIN policy was actually
> counterproductive to its goal, causing you to announce *more* routes,
> yes?
> 
> 
That is correct.  When we went to ARIN space, this was in 1995 mind you, we went from 6 announced PA blocks to one PI block.  But, we had to keep getting PA blocks until we could justify the block from ARIN.  This happened again in 2000 with another company when we went from 4 PA blocks to one PI block.

Regards,

Mike


_______________________________________________
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 jlewis at lewis.org  Fri Jul 31 11:29:27 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 31 Jul 2009 11:29:27 -0400 (EDT)
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
	<3c3e3fca0907310717u7bc48aaapa7d522fc55292b75@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907311059460.4187@soloth.lewis.org>

On Fri, 31 Jul 2009, William Herrin wrote:

> Seriously, if you know of an ISP that's filtering on RIR minimums and
> relying on announced covering routes (with no default route) to catch
> the missing routes, I'd like to know who so I can go win an argument
> with one of my transit providers about which space to assign me.

I know people who've used at least subsets of the ISP-Ingress-Strict 
prefix filter to filter on some RIR minimums...but not without also 
pointing default at a provider who didn't do such filtering.

>> While the most traveled road is Multihome with PA, then Multihome
>> with PI, there are plenty of folks who single home with PA (no
>> global routing table slot) until they can qualify for an ARIN PI
>> block, then they multi-home.
>
> That the /22 policy encourages folks to screw up their networks is
> hardly a point in its favor.

A few more negative side effects of current policy I've seen on networks 
where I was brought in to "help":

Multihoming with PA space...the org gets a /24 at a time (as needed) from 
one of their providers.  Each /24 gets announced in BGP.  Worst case 
(which I have seen and cleaned up), the org may have gotten a mix of /24s, 
/23s, and even some /22s (don't ask me why they hadn't applied for PI), 
and because they don't know any better, it all gets announced as /24s.

Multihoming with PA space...in what I think is a violation of NRPM 
4.2.3.6, it seems typical for a multihomed org to be assigned a /24 from 
each of their providers ("you're buying a T1 or better and multihoming, 
here's your /24") and then announce one or more PA /24s in BGP.  The worst 
case I saw was an org that heavily used NAT (they had hundreds, perhaps a 
thousand) IP devices, but only perhaps a dozen or fewer public IPs in use, 
and they were assigned /24s concurrently from 4 different upstream 
providers.

Sure, these junk routes can be filtered...but in general they're not, and 
at the "Tier 1" level, they're almost certainly not.  In cases like the 
above, lowering the minimum allocation and encouraging orgs to get their 
own space would actually subtract routes from the global table.

> >> I suspect many of the folks on this list would spend a lot more
>> effort trying to multi-home if they could get 1 /32 from ARIN for
>> $10 per year. ?The number of cable modem and DSL customers asking
>> their providers for BGP would skyrocket. ?It's not because those
>> folks are multi-homed with PA space today.
>
> Straw man. We're talking about /24's not /32's. And $10 per year
> doesn't buy you BGP with any ISP I've ever talked to. Further, with
> the right language in a /24 policy we can, if we want to, make sure it
> never does.

Good luck getting any of the Bells to provision BGP for your DSL 
connection.  I did it for a DSL customer once...it was probably a 
mistake to agree to do it...but I only did it because he had his own 
legacy /24 and ASN.

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

From mksmith at adhost.com  Fri Jul 31 12:53:05 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 31 Jul 2009 09:53:05 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <3c3e3fca0907310847w6cc1f0e3v94610fe5d199e162@mail.gmail.com>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com>
	<C6978482.971EB%mksmith@adhost.com>
	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
	<3c3e3fca0907310847w6cc1f0e3v94610fe5d199e162@mail.gmail.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B868@ad-exh01.adhost.lan>



> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William
> Herrin
> Sent: Friday, July 31, 2009 8:47 AM
> To: Michael K. Smith - Adhost
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Fri, Jul 31, 2009 at 11:39 AM, Michael K. Smith -
> Adhost<mksmith at adhost.com> wrote:
> > That is correct. ?When we went to ARIN space, this was in
> >1995 mind you, we went from 6 announced PA blocks to
> >one PI block. ?But, we had to keep getting PA blocks until
> > we could justify the block from ARIN. ?This happened again
> > in 2000 with another company when we went from 4 PA
> > blocks to one PI block.
> 
> Hi Michael,
> 
> So, I'm thinking that if we craft a /24 policy, we should probably try
> to preserve the good part of that (that once you got a /20 you had
> only one block that you could announce as an aggregate) while
> eliminating the bad part (that before you could justify a /20 you were
> announcing 6 disaggregate routes). Sound reasonable?
> 
> Regards,
> Bill

I'm up for the challenge if you are.  :-)

Mike


From sethm at rollernet.us  Fri Jul 31 13:48:46 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 31 Jul 2009 10:48:46 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
References: <DE039243-5B44-4802-BD6D-5C70630B19CB@delong.com><C6978482.971EB%mksmith@adhost.com>	<3c3e3fca0907301739s2b531e34n6de1887a5f8fba22@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D5203160676B83A@ad-exh01.adhost.lan>
Message-ID: <4A732E7E.9030706@rollernet.us>

Michael K. Smith - Adhost wrote:
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Thursday, July 30, 2009 5:40 PM
>> To: ARIN PPML
>> Subject: Re: [arin-ppml] Rationale for /22
>>
>> On Thu, Jul 30, 2009 at 8:10 PM, Michael K. Smith<mksmith at adhost.com>
>> wrote:
>>>  In the
>>> past, I've been in just this type of position, advertising multiple
>> /24's
>>> assigned from upstreams until I could justify a /20 from ARIN.  If I
>> had the
>>> opportunity to number out of a /24 instead of waiting until I had a
>> /22 I
>>> would have jumped at the chance.
>> Hi Michael,
>>
>> Does that mean you actually used *less* BGP slots after getting your
>> ARIN addresses? So in your case, current ARIN policy was actually
>> counterproductive to its goal, causing you to announce *more* routes,
>> yes?
>>
>>
> That is correct.  When we went to ARIN space, this was in 1995 mind you, we went from 6 announced PA blocks to one PI block.  But, we had to keep getting PA blocks until we could justify the block from ARIN.  This happened again in 2000 with another company when we went from 4 PA blocks to one PI block.
> 


I did the same thing to get my /22. Policy pretty much demands it.

~Seth


From owen at delong.com  Fri Jul 31 14:59:19 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 Jul 2009 11:59:19 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <C6978482.971EB%mksmith@adhost.com>
References: <C6978482.971EB%mksmith@adhost.com>
Message-ID: <8C299159-5B55-411B-BA29-3015E34566CA@delong.com>


On Jul 30, 2009, at 5:10 PM, Michael K. Smith wrote:

>
>
>
> On 7/30/09 4:05 PM, "Owen DeLong" <owen at delong.com> wrote:
>
>>
>> On Jul 30, 2009, at 3:46 PM, Leo Bicknell wrote:
>>
>>> In a message written on Thu, Jul 30, 2009 at 05:48:06PM -0400,  
>>> William Herrin
>>> wrote:
>>>> If I may draw it back to the question I started with: Can you  
>>>> offer a
>>>> well grounded reason to believe that changing the minimum  
>>>> allocation
>>>> size for *multihomed* systems is likely to affect the size of the
>>>> global table?
>>>
>>> I believe it is reasonable to assume each decrease in prefix size
>>> allows more orgs to qualify, and thus increases the routing table.
>>> Now it may be we only add 1000 orgs, of which 800 previously were
>>> multi-homing with cutouts, so the net is 200 routes, but that  
>>> doesn't
>>> mean it's not a decrease.
>>>
>> I don't get this...
>>
>> Under current policy, any org that multihomes qualifies for a /24  
>> from their
>> upstream.
>>
>> Given that, any org that multihomes already qualifies to put a  
>> route in the
>> DFZ.
>>
>> What increase are you concerned about that is added by moving the  
>> ARIN
>> boundary from /22 to /24?
>>
>> Today, they can save $100/year and get space from an upstream that
>> they don't pay ARIN for, as well as getting a  /24 even if they  
>> want to
>> multihome a single host.  That's CURRENT ARIN policy.
>>
>> If we move the boundary to /24, then, in addition to that option,  
>> networks
>> that have ~128 - ~400 hosts would gain the option of applying to ARIN
>> and getting a /24 or /23 to multihome with that was independent of
>> both of their providers.
>>
>> Why would someone who is not willing to multihome for $100 less
>> pay $100 more to multihome _AND_ jump through more hoops just
>> because we changed the ARIN boundary?
>>
>> Owen
>>
> Are you saying you think that a small provider with a upstream- 
> provided /24
> wouldn't want to jump through the hoops to be provider independent?   
> In the
> past, I've been in just this type of position, advertising multiple / 
> 24's
> assigned from upstreams until I could justify a /20 from ARIN.  If I  
> had the
> opportunity to number out of a /24 instead of waiting until I had a / 
> 22 I
> would have jumped at the chance.
>
I'm saying that said same entity would not increase the routing table by
getting their space from ARIN.

Nobody who wants to multihome is avoiding doing so because they can't
get space from ARIN.

> What was the rationale for the /20 in the first place?  Was it more  
> than an
> arbitrary number?  I can't see any detraction from getting providers  
> to get
> an ARIN-assigned /24 instead of having to get a /24 from one  
> provider and
> route it out another, being historically on the "purchasing" side of  
> that
> arrangement.  The only downside I can see is providers that think  
> having a
> customer with their assigned space somehow binds them together,  
> fiscally
> speaking.
>
Exactly.  I'm disagreeing with Leo's assertion that allowing ARIN to  
issue
longer prefixes would somehow increase the routing table.

Owen



From owen at delong.com  Fri Jul 31 15:11:09 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 Jul 2009 12:11:09 -0700
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090731033041.GA14598@ussenterprise.ufp.org>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
Message-ID: <5BEEF8AF-E116-469C-B58D-44EC438170D6@delong.com>


On Jul 30, 2009, at 8:30 PM, Leo Bicknell wrote:

> In a message written on Thu, Jul 30, 2009 at 07:17:20PM -0500, David  
> Farmer wrote:
>> You are assuming that the number of multi-homed users will remain a
>> constant, if you allow a multi-home user with a PA based /24 from a  
>> provider
>> to switch to a PI based /24 from ARIN.  It is entirely possible  
>> that the
>> availability of PI /24s from ARIN for multi-homing could create an  
>> inducement
>> for more users to multi-home, just so they can get PI space.
>
> David summed it up well, however, a few notes.
>
> If a network multihomes with a subnet of a PA block and someone
> somewhere else in the routing table filters that route but not the
> PA block, there is still full reachability.  If someone multihomes
> with a PI block and that same person filters the same route, there
> is no reachability.
>
While this is sort of true, the reality is that the point of multihoming
is to have connectivity even if one of your providers goes away.
Given that, if the route is filtered, the functionality of multihoming
is partially lost or degraded.

> Thus the size of the set of all routes is the same; but the size
> of the filtered routes but still global reachability set is reduced.
> There are a number of people trying to use the second set.
>
Not really, but, sort of kind of enough that some people choose
to buy into this myth.

> While the most traveled road is Multihome with PA, then Multihome
> with PI, there are plenty of folks who single home with PA (no
> global routing table slot) until they can qualify for an ARIN PI
> block, then they multi-home.  There are users who go from nothing
> to multi-homed; for instance startups who make sure they qualify
> day 1 for a multi-homed prefix.  Presumably if the barrier was lower
> more would do so.
>
Sure, but, I'm not buying that these numbers are large enough for
that to be a bad thing.

I would agree with policy limits that prevent people from getting
multiple /24s rather than trading up until they reach /22 or possibly
even /21.

> I suspect many of the folks on this list would spend a lot more
> effort trying to multi-home if they could get 1 /32 from ARIN for
> $10 per year.  The number of cable modem and DSL customers asking
> their providers for BGP would skyrocket.  It's not because those
> folks are multi-homed with PA space today.
>
I think that /32 is reductio ad absurdum.  However, /24 is not and
I think that there is an under-served class of users still stuck with
a relatively arbitrary and in some ways punitive policy that we
should have rectified long ago.

Owen



From bicknell at ufp.org  Fri Jul 31 15:31:29 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 31 Jul 2009 15:31:29 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <5BEEF8AF-E116-469C-B58D-44EC438170D6@delong.com>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
	<5BEEF8AF-E116-469C-B58D-44EC438170D6@delong.com>
Message-ID: <20090731193129.GA78183@ussenterprise.ufp.org>

In a message written on Fri, Jul 31, 2009 at 12:11:09PM -0700, Owen DeLong wrote:
> Sure, but, I'm not buying that these numbers are large enough for
> that to be a bad thing.

I never said they were.  What I said was, I am worried there is a
tipping point, and I think that argues for making small steps, and
not large ones so we don't overshoot.

> I would agree with policy limits that prevent people from getting
> multiple /24s rather than trading up until they reach /22 or possibly
> even /21.

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

A /22 is the smallest prefix for a multi-homed end-user.

End users must demonstrate:

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

So the current policy means that if you get a /24 from Provider A's
PA block, and a /24 from Provider B's PA block, use 50% of the
addresses in each block (256 used, which is 25% of a /22), and plan
to use 512 (50% of a /22) in one year you get a /22 from ARIN.

I suspect most of the folks popping up and saying they had 6-10
different /24's in the global table before getting an ARIN allocation
either did it prior to us relaxing the limits (at one time it was
a /20), or didn't want to deal with ARIN for some reason.  Today I
see no reason why a someone should need more than 2-3 blocks before
qualifing for an ARIN PI assignment.

I'll also note that in this system when getting the ARIN PI block
the PA blocks are usually returned, they are not permanently used
routing table slots where as the PI blocks are.

So I'm failing to see the big problem everyone describes. I think
in fact the last policy change that moved things to a /22 resolved
95%+ of all the problems that have been brought up in this forum
before.

However, I am quite willing to entertain moving the limit down
further, as there seems to have been few ill effects from the move
to /22.  I am however worried that there is a tipping point out
there, so I support going to a /23, not further, at this time.

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

From Wesley.E.George at sprint.com  Fri Jul 31 15:42:50 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 31 Jul 2009 14:42:50 -0500
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090731193129.GA78183@ussenterprise.ufp.org>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
	<5BEEF8AF-E116-469C-B58D-44EC438170D6@delong.com>
	<20090731193129.GA78183@ussenterprise.ufp.org>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F42BB514@PLSWM01C.ad.sprint.com>



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
Sent: Friday, July 31, 2009 3:31 PM
To: Owen DeLong
Cc: ARIN PPML
Subject: Re: [arin-ppml] Rationale for /22

I never said they were.  What I said was, I am worried there is a
tipping point, and I think that argues for making small steps, and
not large ones so we don't overshoot.
<snip>
However, I am quite willing to entertain moving the limit down
further, as there seems to have been few ill effects from the move
to /22.  I am however worried that there is a tipping point out
there, so I support going to a /23, not further, at this time.

Agree that we shouldn't do it all at once. I think you honed in too much on my rhetorical question and took it to mean that I was advocating dropping the limit altogether. ;-)

So what about going to /23 now, and to /24 when the last /8s are assigned? Then maybe if there's interest, we even go further as the rest of the space goes away, noting of course that it'll get progressively harder to ensure that the route will be carried through legacy filters.

Wes

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 bill at herrin.us  Fri Jul 31 16:24:13 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jul 2009 16:24:13 -0400
Subject: [arin-ppml] Rationale for /22
In-Reply-To: <20090731193129.GA78183@ussenterprise.ufp.org>
References: <3c3e3fca0907301614m65ca5e7aw402ad730fd9d4231@mail.gmail.com>
	<4A71F1C0.999.7561B2A@farmer.umn.edu>
	<20090731033041.GA14598@ussenterprise.ufp.org>
	<5BEEF8AF-E116-469C-B58D-44EC438170D6@delong.com>
	<20090731193129.GA78183@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0907311324t65c57144rae60c4f8f108116d@mail.gmail.com>

On Fri, Jul 31, 2009 at 3:31 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> I suspect most of the folks popping up and saying they had 6-10
> different /24's in the global table before getting an ARIN allocation
> either did it prior to us relaxing the limits (at one time it was
> a /20), or didn't want to deal with ARIN for some reason. ?Today I
> see no reason why a someone should need more than 2-3 blocks before
> qualifing for an ARIN PI assignment.

Hi Leo,

>From their descriptions most of them were small ISPs rather than end
users, where the standard is still /20.  But I agree with you that we
should take cautious steps forward.

What is a cautious step forward? /21 for ISPs and /23 for end users?
Perhaps. On the other hand, we have described some issues during this
discussion that could be exacerbated by just blanketly lowering the
bar.

On the flip side, the latest 2U DL380 servers from HP have 8 CPU
cores, 144 gigs of RAM and 16 300gig hard disks. How many of these do
you need at 1 IP address each before you've created an Internet
service of sufficient value to merit multihoming?

Would it be reasonable to consider bridging the gap between /20 and
/24 with an entirely different policy? Something that more directly
attacks the "whose routes and how many can we afford to carry" problem
instead of the sideways "250 machines now" requirement that a /22
imposes?

Perhaps tackling the problem from a different direction could get us
to /24 with a step that's more cautious and more conservative than
just lowering the limit to from /22 to /23.

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