[arin-ppml] Rationale for /22

[Scott Leibrand]

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.