I would like to bring up the matter of address ownership. Here is the story: 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. Company FOO which has a class C decides to leave their current ISP - D. They move to ISP - N - which has their own CIDR block and does the good thing - forces the company to renumber and then informs ILAN that the company has relinquished the old class C. This allows me to reclaim IP addresses and form blocks of /22 and /21 which previously could not be done. All good up to this point. ISP D says since they paid the �50 registration fee - they now own the class C forever. I tell them that that is not the case and that the address was registered in the name of the company and not in the name of the ISP. They reassign the class C to other customers - at the same time I have reassigned the reallocated class C to some one else. Their upstream service provider - U - says to D: "Please inform me to delete the networks below from your access-list per Ilan request. It is a policy of U to only delete networks per U's customer request and not anyone else. This issues needs to resolved by you and ILAN and once it has been resolved, please let me what networks to delete." Ok so far. I trust D and ILAN will resolve this peacefully. But what about cases where it cannot be resolved peacfully? The routing tables are gonna start growing. ILAN withdrew 190 routes on August 1st when it started announcing 192.114.0.0/16 and 192.115.0.0/16. Now, since D is announcing a more specific (/24) - it turns out that his route supercedes my larger aggregate. How to combat it? I would have to start reannouncing all my specifics so as to counter-override his /24. What were to happen if this ISP picked a chunk of unused IP address space in my blocks, and started advertising it as /24s? His upstream service provider - U - just accepts it and starts routing. We maintain the authoritative source for IP address ownership in whois.ripe.net. We found that the upstream service provider - U - went and added a route object in whois.ra.net for the /24s (there are 2 cases now) - basely solely on the word of ISP D. So now there is a contradiction between the two databases. Now if D were to start advertising many unallocated /24s, I would be in a big problem and have to restart announcing my specifics. What are people doing in this area today? Are we going to start seeing routing wars? Thanks, Hank Nussbacher Israel
Hank expresses concern: <condensed>
What are people doing in this area today? Are we going to start seeing routing wars?
Hank, In the practical spirit of your question..... I distinctly remember in 1993, preCIDR deployment, when the question was asked around the table at a major corporation (.... not a net discussion, an old-fashioned, face-to-face, meeting :-) We were brainstorming future implementations of CIDR. I had been in the early hot seat as big corps came onto the capital-I Internet, vis-a-vis marketing types having a difficult choice (i.e. their potential big $$ client was using unregistered address space) of renumbering an entire enterprise or losing the account. I held fast, doing the 'right thing', and was very unpopular to the marketing gurus as I held ground stating *renumber* or take your business elsewhere. Luckily, management supported our engineering decisions. Then, in parallel, CIDR was hailed as the 'way to help save B space deletion problems'. At the time, very few had a crystal ball and believed the use of address space would explode to it's post WWW rate. (some did, is the amazing thing!) I have stated this innumerable times, and by saying so put myself in a very unpopular position with certain Internet groups; at the time we consided CIRD blocks to be *portable*. "After all", we stated, "the address space does *not* belong to the provider of connectivity". We also, as a major player at the time, had the unwritten policy " portability of the customer address space, so they could easily move to another provider, was a number one priority". We understood that this opened the door for punching zillions of holes in CIRD, but after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. Like most people, I moved on to greener, more profitable career pastures and was very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. It was very suprising to me to learn that fate had changed the course of history and aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Historically, when society has been forced into a solution that the general population finds unacceptable, those decisions come back to haunt and trouble us. This is causality, and causality always holds true, IMO. This does not mean that aggregation is not a good thing, it certainly has proven to be the saving technology of the Internet. On the other hand, there are future social and political implementations of global aggregation that are negative. We have discussed these issues and roasted the 'core ideas' repeatedly and my body is scared from raging fires. Cause and effect. No matter what we hope, pray, or design.... it is impossible to design, hope or pray causality out of the event stream. Even the best laid plans of both 'mice and men' ride the big causal ferris wheel. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Regards, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+
participants (2)
-
Hank Nussbacher
-
Tim Bass