[ppml] Returning blocks of IP space
Michael.Dillon at radianz.com
Michael.Dillon at radianz.com
Thu Dec 5 05:51:06 EST 2002
> > 2. ARIN should publish a directory, updated daily, that identifies all
> > unallocated ARIN space at the largest aggregate level. This should be
> 1. ARIN does not have the technical experience and operational
> clue to maintain this list.
ARIN already maintains such a list internally in order to know which IP
addresses are available to allocate for any new allocations. It doesn't
take much operational clue to dump this database (presumably an RDBMS)
into a directory and publish that. Since the people who do have
operational clue like to use BGP as the format for publishing lists of IP
address blocks (i.e. RBL, etc.) it seems reasonable that ARIN should also
publish their directory in that format.
> 2. ARIN does not have the financial ability to staff such a position
> 7x24x365, which would be needed incase of a posting error.
Anyone who connects ARIN's announce-only BGP feed directly into production
Internet routers is nuts. The BGP feed is there to *PUBLISH* the
directory, i.e. make the information available. I won't tell network
operators how to deal with the feed but I'd suggest that it makes most
sense to mirror the ARIN directory data internally and when it changes,
have some internal process that checks the changes and then moves them
into the system that generates route filters. Whenever there is an abuse
incident, the response team will have the data available and can expedite
this process if they choose.
> 3. This is non-scalable and thus not useful. I see thousands of
> unallocated prefixes being announced. The filter sizes would be
> large and have a negative impact on router CPU performance.
I said something about the ARIN list being the largest possible aggregate
size. And let me remind you about a technique called BGP route filtering
that allows someone receiving a BGP feed like ARIN's to ignore routes
smaller than a certain size. :-P
> 4. BGP feed is non-scaleable without expending financial resources
> that could be better spent elsewhere.
Everything costs money. It's up to the ARIN members and BoT to decide the
wise ways to spend that money.
> 5. Mirrors have a tendency to exacerbate the above problems.
You cannot prohibit people from recording a copy of the data they receive.
In fact, the whole routing registry concept encourages it. Also, if you
are running a network that depends on having the ARIN filters in place
then you will not want to be dependent on a live BGP connection to ARIN.
Therefore best practice would be to mirror the data and configure your
routers from the mirror.
> 6. Legal tort issues with screwing up the list and knocking someone
> off the net for X period of time.
Let the BoT and the lawyers worry about the law. IMHO there is no tort
issue for ARIN to publish their authoritative data that describes the
factual state of the IPv4 address space.
--Michael Dillon
More information about the ARIN-PPML
mailing list