[arin-ppml] Rationale for /22

George, Wes E [NTK] Wesley.E.George at sprint.com
Thu Jul 30 13:19:19 EDT 2009


Golly this is a long thread - lot of good points already made, also some off-topic stuff. Can't find a good place to insert, so I'm top-posting.

To the question of "existing filters/inertia aside, is there a justification for *any* minimum allocation size?"
or putting it another way, "will allowing /22+X (0 < X < 9) allocations for MH customers be the end of the world as we know it?"
By itself, probably not, but when you consider that companies carrying those routes as a part of the full table will also soon be running dual-stack and carrying multiple thousand IPv6 routes in addition to the IPv4 table, there is a point at which this as a combination could become a problem. You rightly point out that we'll only know it when we trip over it. I don't want to get back into the "router vendors suck, big ISPs suck, technology will solve the problem" debate that seems to always break out when we're talking about table size. It's valid as a point to consider, because it's a short-term problem, and not the same sort of issue as long-term routing table growth in IPv6. The size of both tables is going to swell almost simultaneously until IPv4 table size peaks and then starts receding as it is supplanted by IPv6. In other words, it'll likely get worse before it gets better (and then maybe gets worse again).

I think it's a matter of finding the point of diminishing returns, at which the load on the routing system and the increased availability/efficient allocations of addresses (and the relative value of tiny blocks) are balanced. Perhaps this is another of the proposals (if it indeed leads to a proposal) that should have a floating down limit based on the amount of IPv4 addresses left (eg drop to /23 now, /24 when there are X blocks left, /25 at X-Y left, etc). This would be a combination of an "any port in a storm" philosophy (i.e. a few addresses are better than none in some cases) and providing those who want to be good citizens and renumber into a more appropriately sized block and return a larger block the opportunity to do so. The inertia of renumbering and the gradual increase in prefix length would also hopefully temper the growth of the table so that we might sneak up on it in an effort not to trip over it.

Thanks,
Wes

-----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 12:04 PM
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.


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.




More information about the ARIN-PPML mailing list