[arin-ppml] Rationale for /22

[Ted Mittelstaedt]

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