[arin-ppml] Rationale for /22

[Scott Leibrand]

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.