- Test - lists.nanog.org

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 02 Oct '95

02 Oct '95

> From: Michael Dillon <michael(a)junction.net> > On Fri, 29 Sep 1995, Mark Kent wrote: > > Announce now that by Oct 1, 1996 no individual /24 will be routed. > > This is a reasonable timetable. > > > Filter 204/24 and 205/24 on Oct 31, 1995 > > Filter 202/24 and 203/24 on Nov 30, 1995 > > This is not! > > The great bulk of the world, especially management types, gets their > technical news with a 4 to 6 month time delay from glossy technical > magazines. This delay is due to the time required for writers to I want to thank Mark Kent, and disagree with Michael Dillon. Last April, folks at IETF stood in the front of the room and said they were going to start reducing the prefixes. I heard within a _month_! Now, it has been 6 months. We've already had plenty of time for the news magazines to print and management types to absorb the news. Some competent providers have already informed their customers that they need to renumber, have already started planning, and are actually renumbering! Others are not so competent. Time to announce to them that we're sorry, but unless they pay out lots of money to upgrade their competitors and fund the research, their competitors aren't going to accept their /24 routes anymore. We are all in this together. Now, the pier wg is trying to help put together a list of OS's and pin-pointing "how to" work through renumbering. That should help. But there's no time like the present to get on with doing it! The only difference I'd make is to _START_ with 192, not end there. We get a lot more bang for the buck there, as renumbering will help aggregate both continentally and regionally, and also free up badly managed space for the future. That nice table from Dennis was an eye-opener (just what I was looking for, thanks)! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

5 6

Re: Comments on Routing and Allocation Policy Wanted
by Sanjay Dani 02 Oct '95

02 Oct '95

>From: patrick(a)Verity.COM (Patrick Horgan) >> From: "Walter O. Haas" <haas(a)xmission.com> >> >> Somehow I'm under the impression that it's possible to have SMTP over a >> PPP dialup by logging into the mail server, is that not correct? > >Not exactly. smtp is just a tcp protocol. You only need to do a tcp [snip] >One easy way to do mail is to nfs mount the directory containing [snip] >The next choice is POP (Post Office Protocol). With pop, your machine [snip] Alternatively, if you want to SMTP over email for a domain over the dialup connection, assign the PPP client a primary MX record and a fully connected server on the PPP server's network a secondary. The PPP reconnect script on the client can be instrumented to flush the outgoing queue and also send email to pseudo alias on the secondary MX server that triggers a flush of its incoming queue for your domain. You have to make sure you dialup at least once every three days or so. This strategy requires the PPP client have a static IP. Sanjay.

2 1

Re: Comments on Routing and Allocation Policy Wanted
by patrick＠Verity.COM 02 Oct '95

02 Oct '95

> From: Sanjay Dani <sanjay(a)professionals.com> > > > Alternatively, if you want to SMTP over email for a domain over the > dialup connection, assign the PPP client a primary MX record and a > fully connected server on the PPP server's network a secondary. The > PPP reconnect script on the client can be instrumented to flush the > outgoing queue and also send email to pseudo alias on the secondary > MX server that triggers a flush of its incoming queue for your domain. > You have to make sure you dialup at least once every three days or so. > > This strategy requires the PPP client have a static IP. > > Sanjay. > Sanjay is quite right:) I missed this because of my own assumptions. I'd like to be able to read mail from home via pop and from work via an NFS mounted spool directory. Sanjays solution is one that works quite well if you want to only read your mail remotely, i.e. you might be in a situation where you have no direct access to read mail on the normal mailhost. Another possibility that neither of us has mentioned is to have the mailhost use uucp delivery for your mail domain. Then it queues in the uucp spool until your machine calls (or until the mailhost calls you if you have it set up that way.) Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Comments on Routing and Allocation Policy Wanted
by patrick＠Verity.COM 02 Oct '95

02 Oct '95

> From: "Walter O. Haas" <haas(a)xmission.com> > > Somehow I'm under the impression that it's possible to have SMTP over a > PPP dialup by logging into the mail server, is that not correct? Not exactly. smtp is just a tcp protocol. You only need to do a tcp connection to do smtp. That means that no login to the mail server is needed to do smtp. You might have meant something different though. Let me give a brief overview of issues involved in doing mail via a ppp connection. The first assumption is that your remote ppp-connected host doesn't have a full time ppp-connection. If it did you could just make it an smtp host. One easy way to do mail is to nfs mount the directory containing your email on your ppp connected host and do mail just as you always would. This isn't always possible since nfs mounting might not work from your host, (you might not have the appropriate software,) or policy might not allow it. The next choice is POP (Post Office Protocol). With pop, your machine contacts the pop server on the mailhost and is able to access the mail in your spool file. After reading a mail you're able to leave it in the spool file, or delete it. (Note that pop passes your password in the clear:( ) Your MUA (mail user agent, i.e. what you used to read and send mail), talks SMTP via TCP over PPP directly to the mailhost. If this is unclear, please send me mail, I could give you a lot more information. > Assigning > an IP address on the fly gives better utilization of the space if you can > get the functionality you need. Using pop over ppp gets the functionality you need as long as you don't need a "full time connection." All the reasons you would need a full time connection would have implications that you need static IP. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

geeting NANOG listed in Encyclopedia of Associations
by Nigel Allen 02 Oct '95

02 Oct '95

Groups like NANOG may find it useful to be listed in the _Encyclopedia of Associations_, a directory of national non-profit groups in the United States, so that journalists, researchers and potential new members can get in touch with you more easily. I have transcribed the questionnaire that the _Encyclopedia of Associations_ uses to compile its listings, and I would be happy to send a copy to anyone who would like their group listed. The Encyclopedia of Associations is published by Gale Research Inc. of Detroit, a well-known publisher of reference books. Your local library probably has a copy of the _Encyclopedia of Associations_ that you can look through to see how other progressive groups are listed. To request a questionnaire, send me e-mail (ndallen(a)io.org) or contact: Encyclopedia of Associations Gale Research Inc. 835 Penobscot Building Detroit, MI 48226-4094 U.S.A. telephone (313) 961-2242 or 800-877-GALE fax (313) 961-6815 -- Nigel Allen, Toronto, Ontario, Canada ndallen(a)io.org Web page: http://www.io.org/~ndallen

2 1

Re: Peering in the LA region?!?
by Marcos Della 02 Oct '95

02 Oct '95

Well, it sounds like several people are interested in peering somewhere in the LA region. We were just out to the one wilshire building last Monday to look at the layout and the interconnects within the building. There are several people located on various floors there. For those that are in the building, you all probably know about the "cost" of doing business between floors. We just purchased a 4" pipe from P1 to the 18th floor (our location) with drops on each floor (hense the right of way). We also have a thousand spare feet of space that leased to us for the next generation or so :-) With this in mind, this week, we are starting the buildout of both co-location space as well as interconnect racks. We are planning on putting a 7500 in this location as well as a CDDI ring. We can just as easily put up an ethernet hub and interconnect this down to Peter's spot on the 14th floor. Bill, if you want to locate a RADB processor, you are welcome to install one in our location if need be. We will also allow low speed frame or T1 groups to connect in to the PCH router that we will probably be setting up there as well (packet clearing house) for a "star" peering arrangment. This router will back end into our connections also. As for anyone else, let me know since we are flying down to LA Wednesday to begin the rollout. Also, we will have MFS fiber and PacBell fiber on our floor as well if needed. We are talking to TCG for fiber as well for anyone who wants to connect via any of these methods. Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella(a)InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella

1 0

Comments on Routing and Allocation Policy Wanted
by Forrest W. Christian 30 Sep '95

30 Sep '95

I'm currently in the process of working on a "rough draft" of a policy on IP number usage. I'd like to solicit a few comments from those of you who seem to be making the majority of the routing decisions. Here's a copy of what I'm presently working on. Please feel free to rip it to shreds if necessary.... THE MONTANA INTERNET COOPERATIVE INTERNET ADDRESS ASSIGNMENT AND ROUTING POLICY September 29, 1995 Standard Dialup SLIP, CSLIP and PPP customers will be allocated a Single Static IP Address to be used to configure their software. There are many advantages to be gained by Statically allocating the numbers, including the ability to have multiple mailboxes by using SMTP, etc. Dedicated and Routed-Dialup customers will be allocated a block of numbers from MIC's CIDR block. The size and quantity of blocks will depend on the number of machines to be connected to the network at the customer's premises and the customer's network architecture. MIC currently allocates blocks containing 8, 16, 32, 64 or 256 "individual" addresses. Multiple consecutive blocks will be allocated depending on need of the customer. Dedicated and Routed-Dialup customers who already have a set of Internic allocated addresses may continue to use those numbers as long as the following conditions are met: 1) The numbers MUST be listed and registered in the internic database. 2) Only blocks addressable with a prefix of /21 or smaller for addresses with an initial octet less than 205, and blocks addressable with a prefix of /19 or smaller for addresses with an initial octet of 205 or higher will be permitted. If you are uncertain whether certain addresses meet these criteria, contact MIC support for details. 3) The customer is aware that MIC will not guarantee the routablity of any customer provided numbers. The customer should also be aware that routing policies can and will change, and as a result, the customer's numbers may not be routed by various Service Providers at any point in the future. forrestc(a)imach.com

3 4

Re: number of unaggregated class C's in swamp?
by Walter O. Haas 30 Sep '95

30 Sep '95

Seems to me like the logical place to start renumbering, if that's going to be forced, is by outlawing new CIDR block exceptions - if you switch providers you renumber. It's a hateful approach in that it raises the barrier to new providers entering the market, but it's more understandable to customers. The next step would seem to be outlawing *existing* CIDR block exceptions. Give up your portable numbers and get back under the provider's umbrella. We renumbered a group of machines by hand once. Not an experience any of us want to repeat. Flag Day turned into Flag Week! At least if you're switching to another provider you have the chance of running with two addresses on each machine for a month or two. Has a chance of being managed less disruptively. Would be nice if everybody supported DHCP. Reprogram the server then go shut off the main circuit breaker ;-) Anybody care to bet when that will actually happen? Ugh. Renumbering is *NOT* going to be popular. -- Walt

1 0

Re: number of unaggregated class C's in swamp?
by William Allen Simpson 30 Sep '95

30 Sep '95

> Date: Fri, 29 Sep 1995 20:16:54 -0400 > From: Dennis Ferguson <dennis(a)mci.net> > The one thing that hasn't been done, however, is to set an actual > goal for routing efficiency. Excellent! > I'd like to state my guess that a good number to aim at might be > about 1200 routes per fully-utilized class-A-sized chunk of address > space. This would put the IPv4 end state at a maximum of about 250,000 > routes, ... > I like the idea of measuring each and every class-A-sized block > against some standard separately, since a lot of the class-C space has > been allocated to regional registries this way and it inconveniences > those places which have done the best the least. I'm less attached to > the number 1200 in particular, but I do think an explicit target should > be chosen which represents both a tractable limit to design big routers for > and which allows the implementation of efficient address allocation strategies > which won't have to be tighened over time. I suggest that it be 2048 for each _pair_ of class As, since that's how they were assigned in RFC-1366 & 1466. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: number of unaggregated class C's in swamp?
by jnc＠ginger.lcs.mit.edu 30 Sep '95

30 Sep '95

From: Dennis Ferguson <dennis(a)mci.net> I also wouldn't bet the farm on some amazing new routing architecture saving us Actually, I think you can safely bet the farm in the other direction, that there is no such thing possible. Yakov and I have some substantial non-agreements about routing architectures, but we are fully agreed that aggregation/abstraction is the only way to make the routing overhead scale, and that means connectivity-sensitive assignment of routing-names, aka renumbering. Sure, at a fixed point on the cost/performance curve, over time you can buy more powerful machines at the same price, and that will allow you to be able to run larger routing tables over time (imagine trying to stuff 28K routes into an IMP :-). There are other things going on too, e.g. some routing designs inherently have more or less overhead than others. However, the bottom line will always be the same, which is that free-form allocation of routing-names in a global-scale network will not be possible. To keep routing overhead within a workable (although probably slowly growing) bound, routign-names will *always* have to be assigned based primarily on network connectivity. I think not dealing with pre-existing allocations is going to mean putting an ever-tighter squeeze on future allocations in a way that is counter-productive, Yes. This also spreads the burden to everyone. what I think we should be doing is trying to pick a routing efficiency which gives us a number of routes ... which seems tractable Exactly. the IPv4 end state at a maximum of about 250,000 routes, a number which I think is not an unreasonable target for new high-end router designs Hmmm. I think this is probably a bit agressive for the next generation, but then again we aren't likely to arrive at the end state for at least several product cycles anyway. Also, the limit I most worried about is the stabilization time, and looking at individual router performance is unlikely to tell you if you can meet this. I'd much rather see each space filled .. as appropriate ... rather than picking an arbitrary, one-size-fits-all filter limit. The latter is a sign of failure. I agree, but the latter does have the advantage of being easier to "police". Getting a whole address block under a limit requires the cooperation of everyone in the block, whereas filters (as we have seen) are easy to impose... Noel

3 2