Operational Issues with 69.0.0.0/8...

Wed Dec 4 12:01:07 UTC 2002

This topic came up on cisco-nsp, but was really more appropriate 
here.  Been meaning to post summaries when I got enough round tuits.  

A suggestion was made there that the RIRs give a bgp feed of 'unused' 
routes to interested parties such that they can be blackholed, etc.  
Sounded like a lot of overhead and things which could go wrong to
me. Skipping over the arguments about who would/wouldn't modify 
processes and would take such a feed, I wouldn't want to have to pay 
for that infrastructure, its support and maintenance out of my 
regsitry fees.  I do think it makes LOADS of sense to have the 
(un)allocations clearly visible in the IRR.  Some of the RIRs do it 
today for their 'greater aggregates' [eg, whois -h whois.ripe.net 
82.0.0.0/8].

Sure, you'd still have providers ignoring the IRR, but it gets a 
lot harder for them to whine about the time it takes to update 
filters or the lack of automation if the data is in a standard 
format in globally distributed DBs for which there are umpty public
tools.  There's always the gripe about authentication. Perhaps 
the IANA should set up a routing registry which merely publishes in
RPSL format the allocated/unallocated list 
(http://www.iana.org/assignments/ipv4-address-space) and the truly
paranoid can just consult *only* that registry for their 
configuration magic? That would be a one-time hit for IANA [or 
volunteers] to make the flat-file-to-RPSL code, and being a single-
source could be cyptographically signed/confirmed if needed.

Cheers,

Joe

-- 
 crimson at sidehack.gweep.net * jprovo at gnu.ai.mit.edu * jzp at rsuc.gweep.net
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE