[arin-ppml] Rationale for /22

Joel Jaeggli joelja at bogus.com
Tue Jul 28 04:43:41 EDT 2009



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



More information about the ARIN-PPML mailing list