[ppml] Returning blocks of IP space

[Michael.Dillon at radianz.com]

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