[arin-ppml] Rationale for /22

[Ted Mittelstaedt]

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.