North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Operational Issues with 220.127.116.11/8...
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 18.104.22.168/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 -- [email protected] * [email protected] * [email protected] RSUC / GweepNet / Spunk / FnB / Usenix / SAGE