Hi Hank! I don't know to what extent you have been following the discussions recently within RIPE wrt Registries of Last Resort... My first answer to the story below would be "stop the Registry of Last Resort business asap". Just to avoid making the mess even bigger...
ILAN acts as registry of last resort in Israel. It owns and assigns IP addresses in the 192.114-118.0.0 address range. These 5 blocks are owned by ILAN (AS378). Over the years, many IP addresses have been assigned - in the past to individual companies and more lately CIDR blocks to local ISPs. ILAN takes a $50 one time fee to register the IP address for the requestor.
Just a matter of terminology, I'm worried by your mixing of the LRL function and phrases like "owns and assigns" in the same sentence with "owned by ILAN (AS378)". If you were really sending these signals to your peers then there is a good chance of mis-understandings. With regard to the rest of your message - here is what we do, both as a Service Provider Registry and a as backbone provider which has to deal with routing: We strictly refuse requests to assign address space for further sub-assignement. Adresses are *directly* assigned to the eventual user. If a service provider wants to act as a Local-IR, then the proper way of doing it is to get in touch with the RIPE-NCC and establish a registry of it's own. Just to make sure that everybody understands the rules, we explicitely point out that the assignement is only valid for the purpose of connecting (directly or through an intermediate step) to our backbone. We explicitely reserve the right to reclaim the address space if these conditions are not (or no longer) met. I know that RLR are slightly different, of course. With regard to routing, the answer is both collaboration by all service providers (which is working rather well, I think) *and* filtering based on the route objects in the RIPE database (which appears to gain popularity). If somebody tries to play games, and most of the backbones would have filters, then there is a good chance that the hickup is confined to a small part of the Internet - which eventually makes the "highjacked" addresses more or less useless. And the multiple database issue should be sorted out anyway, because the problem of inconsistency *is* there, even without malicious intent on any side. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------