[ppml] ARIN Policy Proposal 2002-9

[David Conrad]

Hi,

Speaking personally, not as an ARIN board member, and apologies in advance
for the length...

On 10/1/02 5:22 PM, "Trevor Paquette" <Trevor.Paquette at TeraGo.ca> wrote:
> The issue here is if there is a viable reason for allocating a /24 to an
> entity.  Past history shows that this was the case,

Actually, the registry allocation of /24s (as with the /8s to folks other
than registries and pretty much all /16s in the "class B" space) occurred
during the Internet's infancy, long before anyone thought this TCP/IP stuff
would catch on like it did (after all, the governments and telcos were
working on this stuff called OSI and, of course, it'd be much better than
this stuff produced for/by the US Dept. of Defense).  Address space was
treated _much_ differently then than it is today.

(Yes, this situation can be considered unfair by later entrants into the
Internet, which is, of course, the vast majority.  However, given (according
to the routing summaries posted by APNIC) only 54% of the IPv4 address space
has been allocated, I personally don't see a need to rush into the lawyer
filled swamp of trying to force people to give back address space they don't
want to (voluntary return of address space should be encouraged).  The
issues the registries try to deal with are not exclusively conservation of
address space, but rather balancing address space conservation and limiting
routing system bloat.)

> but for some reason it was changed to a /20.

A bit of history (at least as I remember it) might help here...

In the early 90's, folks noticed the class B space was being consumed pretty
quickly.  Estimates of run out of the class B space (note, not all the
address space, just the class B space) was something like 1996.  This caused
some concern within the IETF and elsewhere as class Bs were the preferred
allocation unit, given class Cs were too small for most and class As were
too large.  After lots of discussion within the IETF, the IEPG, the
regional-techs (network operators involved with the NSFNet), and other
venues, the IANA decided to have InterNIC allocate blocks of class Cs
instead of class Bs.  Since the Internet was still classful, this caused a
different (and not unexpected) problem -- the routing tables grew much too
fast, threatening the NSFNet core routers.  CIDR was deployed (pretty much
just in the nick of time) to address the routing tables growing too fast
problem, using aggregation of routing prefixes to reduce the number of
routes in (and more importantly, the number of routing updates propagating
through) the "default free zone".

However, this aggregtion only works when you can take a bunch of routing
tree leaves and hide them behind a shorter prefix.  As such, address space
needs to be allocated to providers (commercial ISPs or otherwise) who can
aggregate a number of their "customers" into a single prefix.  This is why
there is a minimum block size and that "leaf" entities (in terms of network
topology) should get address space from their upstream.

It isn't, despite the bizarre assertions of a couple of individuals who have
posted in this forum, a grand conspiracy on the part of (pick one or more)
the large ISPs, the US government, ICANN, the RIRs, the Illuminati, or me
personally.  It is simply that we don't know how to scale up networks
without hiding information and CIDR/provider-based addressing is how this
information hiding has been implemnted.  If you have better ideas, there are
still a whole bunch of VCs with money in Silicon Valley desperately looking
for startups with investable ideas...

> This motion had to be brought to the ARIN members before. So
> why was it changed from a /24 to a /20??

I believe (I wasn't directly involved with ARIN at the time, being busy with
APNIC), ARIN's initial allocation policy was a /19, inherited from
InterNIC's address allocation policy when ARIN was formed, changing to a /20
at the beginning of 1999 at the request of the membership.  It is probably
worth noting that the amount of address space ARIN initially allocated at
its inception was inline with both APNIC and RIPE-NCC at the time.

> ** Before any policy is brought to a vote to the ARIN members, I strongly urge
> ARIN to dig up the history on this and present it to this list.

Looking at the archives on ARIN's web site of past member meetings and the
minutes of the AC and board can give you an idea of how ARIN's policies were
established.  The whole CIDR deployment stuff is probably best documented in
the IEPG archives and the IETF CIDRD and ALE working group mailing list
archives.  Also, probably lots of relvant stuff in the NANOG archives (and
its predecessor regional-techs, if archives of that exist anywhere).  It is
a lot to read through and you'll find the pretty much the same arguments
repeated over and over again.

The problem is that the registries are stuck in the middle between the
desires of service providers (commercial or otherwise) to keep their
infrastructures from falling over and the (entirely understandable) desires
of service provider customers for address portability and/or multi-homing.
It can be (and often is) argued that existing restrictions are too harsh,
however the implications of overly generous allocation (namely routers being
unable to handle updates and/or filtering of prefixes to avoid same) are
such that it has historically been felt that it was better to err on the
side of being conservative.  However, address policies are established by
forums such as this and if there is consensus that the policies should
change, they will.  It happened once already (when ARIN moved from /19 to
/20)...

Rgds,
-drc