small multihomed organizations
dan at netrail.net
Mon Aug 6 19:14:28 EDT 2001
It is well past time that organizations wishing to multihome, but not
requiring a /20 of space, should be able to acquire PI space from RIR's. The
problems with our current arrangement is that...
1) It provides an incentive to be less than truthful in requesting an
initial allocation, which leads to waste in the use of that initial /20. If
an organization can subsist on a /23, they should be able to request that.
By forcing only those who can "justify" a /20 to receive PI space, ARIN
inadvertently causes deception, which leads to a lack of trust.
2) Organizations that do not qualify for a /20, yet are multihomed, are at
several disadvantages. These include...
a) The possibility of a severely non-symmetrical traffic load to upstreams,
if their address space is assigned out of an upstream's summary aggregate. A
lack of flexibility in making routing announcements.
b) The additional cost of renumbering if they choose to change transit
providers. While changing transit providers was once quite difficult, it has
become very easy. However, those who choose to stay honest, and not
"gundeck" their Initial Allocation, are at a competitive disadvantage again
those who are not as honest. Honesty should never be a competitive
It is well passed time to allow /24 allocations from a specific /8 block
that is set aside for the purpose of smaller allocations for multihomed
organizations. The requirements for allocation from this block should
1) Possession of an Autonomous System number
2) Multihomed to two or more upstream networks
3) Standard justification on a per-host/per port/etc basis
ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
AS's per year, assuming a steady state. As economic conditions improve, and
taking into account the other RIR's, this indicates an extremely large
number of organizations that may benefit from this policy.
The effect of this change on global routing tables will probably be minimal,
as most providers currently allow /24s to be advertised through their
networks, with few exceptions. This will limit the growth in routing table
size, which, in any case, has proven to be a controllable linear growth,
rather than the much feared exponential growth. Current BGP-speaking edge
and core routers are certainly capable of handling any nominal growth in
table size caused by this change.
Most of those who might benefit from this sort of change are not a part of
ARIN's traditional membership, and do not present a uniform constituency to
ARIN. In spite of this, I would hazard to guess that organizations with
AS's, but not PI space now represent the majority of ARIN's membership base.
- Daniel Golding
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> R Huberman
> Sent: Monday, August 06, 2001 5:26 PM
> To: vipar at verio.net
> Cc: Lee Howard; ppml at arin.net
> Subject: Re: small multihomed organizations
> Lee Howard wrote:
> > ARIN's current policy, as I understand it, is that multihoming is not
> > justification for a /24. I would like to hear recommendations and best
> > practices from others for how to address the customer (pun intended)
> > without violating ARIN policy. Should ARIN accept multihoming as
> > justification for a /24?
> Lyric Apted responded:
> > like you, I think most of us have an unofficial policy that runs against
> > ARIN's for the reasons you've mentioned - personally I believe that
> > multihoming should be justification for a /24. in reality it
> is already.
> I'll chime in with a quick nod to Lyric's comment. More and more I am
> seeing bona fide engineering plans that require organizations to break
> from following ARIN's address usage policies. When we, as operators, deem
> customer and/or internal engineering goals as legitimate, it behooves us
> to support these efforts despite traditional policy.
> Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> between an RIR and its membership. To me, this is a classic example where
> the operator must be entrusted by the RIR to balance mutually exclusive
More information about the ARIN-PPML