- Test - lists.nanog.org

a modest proposal
by Walt Haas 18 Apr '94

18 Apr '94

The idea below seemed to make sense last night after a couple of margaritas at the Rio Grande Cafe, let's see if anybody else thinks it will fly. If this isn't the right place to discuss it let me know, I will forward it appropriately. -- Walt ======= PROPOSAL FOR A NEW NAME/ADDRESS PARADIGM FOR THE INTERNET April 16, 1994 Walter O. Haas University of Utah Salt Lake City, UT 84112 <haas(a)ski.utah.edu> 1. Internet names are the property of the user, not the network service provider. An Internet name has much the same legal status as a registered trademark, and is suited to appear in advertising and other literature completely independently of the Internet service provider currently employed by the user. Internet names will be issued by a central authority directly to the user. Optionally, a network service provider may handle the necessary paperwork for a user to obtain a name, but this does not give the said provider any right or interest in the name issued and the provider must not attempt to mislead the user to the effect that it has such a right. 2. Internet addresses consist of a <provider-part> and a <customer-part>. The <provider-part> belongs to the Internet service provider, and is used by Internet routers to switch traffic to agreed points of that service provider's network. The <customer-part> belongs to the customer. A complete Internet address is of the form <provider-part>.<customer-part>. If the customer decides to obtain services from a different provider, the customer shall adopt addresses using the <provider-part> of the desired provider. It shall be possible for a customer host to be multi-homed to two addresses with different <provider-parts>, either temporarily or permanently. The <provider-part> consists of two areas: a <provider-id> which identifies the organization providing service, followed by a <provider-specified> part which tells that provider's network how to route to the customer network. Thus a complete Internet address can be specified as <provider-id>.<provider-specified>.<customer-part> Providers are assigned a <provider-id> by a global authority, but may choose their <provider-specified> part according to their internal criteria, which may include (but are not limited to) technology, geography, business plan, and perceived customer desires. All providers are required to forward traffic to any of the globally-defined <provider-id> values, but are not required to process any portion of the Internet address beyond that (except their own). There shall however be a defined upper limit on the size of the <provider-specified> and <customer-part>. 3. Each user host shall be configured with its Internet name. Upon booting, the host shall send a Name-to-Address Request (NARQ) packet to a defined broadcast address. The NARQ packet will contain the host's name. A server will respond with a Name-to-Address Reply (NARP) packet containing the Internet address of that host. 4. If the customer decides to change Internet service providers, it will need to assign a new <provider-part> corresponding to the new Internet address of the new service provider to each host. This will be done by giving the new <provider-part> to the customer's nameserver, which will then send appropriate NARP packets to the relevant network hosts which will then each have two Internet addresses. This operation obviously needs appropriate security. When the customer's network has acquired the new set of addresses and the old service provider is no longer in use, then the customer's nameserver can send an appropriate Name-to-Address Invalid (NANA) packet to each host to invalidate that address from its configuration. This operation also needs to be secure. -------

2 1

CIDR testing
by yakov＠watson.ibm.com 18 Apr '94

18 Apr '94

Ref: Your note of Fri, 15 Apr 1994 20:26:47 +0200 Havard, >What this means is that I think it's fairly safe to say that there >will be no connectivity problems when you pull the specific routes. I guess we can declare the as of April 15, 1994 the Internet "guts" have been adequately CIDRized :-) Yakov.

3 2

Re: 20402 routing entries
by Jeff.Ogden＠um.cc.umich.edu 17 Apr '94

17 Apr '94

About three years ago we renumbered all of the state Universities in Michigan (except Michigan State U). It was a lot of work and I wouldn't want to do it very often, but the whole business went much better than I expected. The key is good planning. Another key is getting people to use domain names rather than IP addresses whenever possible. We had signs up saying "Names good, numbers bad!". -Jeff Ogden Merit/MichNet

1 0

Re: 20402 routing entries
by Jessica Yu 16 Apr '94

16 Apr '94

Date: Fri, 15 Apr 1994 16:02:57 -0400 From: "Martin Lee Schoffstall" <schoff(a)us.psi.com> And is only downside is that anyone not doing BGP4 he won't be able to talk to at all. If an AS does not do BGP4 but defaults to a CIDR capable AS, he can still reach it. Only the ASs which does neigher BGP4 nor default will have problem. Maybe you could help him a little bit and tell him who that might be. About 1000 more specific routes have been withdrawn from the Internet during the past two weeks. Have not heard any complain yet. If you know anyone who does neigher CIDR nor default and therefore will have reachability problem when specific routes withdrawn,please let us know. --Jessica

1 0

Re: 20402 routing entries (renumbering)
by t.c.streater＠dante.org.uk 16 Apr '94

16 Apr '94

Renumbering workstations in principle *is* a no-brainer. But there are always wrinkles. And if those workstations are running a particle accelerator (as when a year or so ago I coordinated some renumbering at SLAC), you better have a damn good reason for doing it. A $20M facility running 7*24 expects good reasons for you to possibly screw it up, and their operational philosophy is to assume you will. I was able to renumber two largish groups of machines (200 or so in each), with quite a bit of coordination needed, and because of the various overlapping schedules it took a while before I could even start. Then, for each group I had to assemble numerous experts (Macs, Amigas, PCs, Next, RS/6000, Sun, Ultrix, VAX, Cisco). Luckily we had a good database of workstations so that I could tell the platform experts which machines were going to be involved. In some cases changes had to be backed out a couple of times because of something the platform experts forgot (or didn't know about). Now, can you imagine the conversation I might have had if still working there and SLAC agrees to exchange its class B (with about 1k out of 64k addresses assigned) for some number of class C: Me: SLAC has to renumber! Users: Again? OK Tim - but why? And what's in it for us? Me: (explanation of routing overload deleted) Users: So you are saying that of the 20k or so addresses in routers, SLAC renumbering saves just one entry? Me: Err, yes. Users: Don't ring us, we'll ring you! As Marty says, there is (unfortunately) no carrot - and users resent the stick. You apply the stick too often and you are out the door, either as an external provider or internal expert. Users barely (in some instances) know what an IP address is. They expect the network to be like the phone or power outlets; you just plug in where you happen to be. If we expect renumbering and provider-based addressing to be feasible, it seems to me that w/s vendors need to provide powerful tools to enable *transparent* *on-the-fly* renumbering - else it won't happen. And even if they do (and where's the carrot for *them*?), it will be quite a while before such tools are ubiquitous enough to make the process always easy. Should we be working with vendors in this area? Now will you all *go* *home* - it's the weekend, damnit! Tim Streater, DANTE. t.c.streater(a)dante.org.uk +44 223 302992

6 6

Re: 20402 routing entries
by Vadim Antonov 16 Apr '94

16 Apr '94

>>you have no plan... >Would you be so kind as to tell us whether you have a plan ? "Mister Fiks, do you have a plan?" "Do I have a plan? Do I have a plan? I have two sacks of plan!" :-) --vadim

1 0

egregious waste of bandwidth...
by Robert E. Seastrom 16 Apr '94

16 Apr '94

Hmmm, the regional-techs and bgpd lists are looking a lot like com-priv these days... ---Rob

1 0

Re: 20402 routing entries
by Vadim Antonov 15 Apr '94

15 Apr '94

Not, Marty; the "market reality" is that you do CIDR or people will stop getting PSI's routes. By not doing it you already got screwed routing; the next step is loss of global connectivity, i guess. God bless your customers. Your analogy with 800 portability and IP renumbering is more than artificial. The whole debate about 800 portability rotated around retracting published numbers and loss of investments in advertisements. So far i didn't hear anyone publishing IP numbers in their ads. Changing providers *always* involves some expenses and probably disruption of service. Also, nobody was really interested in renumbering technology in pre-CIDR times; now market will force software vendors to provide network number discovery as a standard feature. The host portability problem is not new -- the mobile communications folks worked on it for quite a time; but it wasn't anywhere near the interest field of regular TCP/IP community. Now it is -- as well as IPNG, video and security. New times, new problems. --vadim

1 0

Dups
by bmanning＠is.rice.edu 15 Apr '94

15 Apr '94

I am getting a lot of these.... Perhaps this is the carrot to dump an AS or two. :) -- Regards, Bill Manning

1 0

Re: 20402 routing entries
by Walt Haas 15 Apr '94

15 Apr '94

>The problem is that there are many things that can be easily >overlooked. I believe if done right, renumbering 20 workstations in a >single department is a no-brainer. However, what it would require is >some cheat sheet of things that can be easily overlooked. Some recipe >of how to do it right. Exactly my point, the recipe could be defined in an RFC and implemented in code, so that the execution cost would be very low. This might be an easier problem to solve than the problem we are trying to address with CIDRizing. -- Walt -------

2 1