November 1996 - Test - lists.nanog.org

the promised text
by Vadim Antonov 22 Nov '96

22 Nov '96

I loaded the text on merits of ATM vs native IP routing to the Pluris Inc's web server. You may find it at http://www.pluris.com Please contact me if you have any problems with the text. I'll also appreciate your comments. --vadim

1 0

Re: RWHOIS, SWIP, and proving ownership
by owen＠DeLong.SJ.CA.US 21 Nov '96

21 Nov '96

> Consider this a side note to the preceding discussion. > > 1. Most of our clients understand that their ''lease'' on network address > space is at our whim, by contract for IP connectivity, and is subject > to renumbering if WE assign them new space, if WE are assigned new space, > or if they move elsewhere. > > Therefore they don't ask us to SWIP the nets nor do they care. > So... > 2. RWHOIS doesn't run on any production operating system. I know Unix is > in vogue, but since we do the 99.96% uptime schtick, we use operating > systems that stay up (VMS). This means we can't run RWHOIS (even if we > did want to, which if you read #1 above you'll see we don't.) > I don't see any reason you couldn't modify RWHOIS to compile/run on VMS. It's pretty straightforward C code with very few UNIX specific calls in it. Admittedly, we run UNIX (which has been up 99.96%+ at our site). In fact, the last time I worked in a shop with a bunch of VMS users, the VMS system was down alot more often than our UNIX systems. Oh well... Guess it's religion. > 3. We currently use almost all of a /18, two thirds of a /19, a few /22s, > and some /24s. It would be easy to justify a /17 based on all this, but > if someone wanted to be rigid about RWHOIS and SWIP, even a bunch of > traceroutes aren't going to convince them. > > Back in THE GOOD OLD DAYS (tm), we said "Be flexible with what you accept, > be rigid with what you send out." (Others made it sound better and put it > in RFCs... D.C. for one.. :) > That applies to network protocols and interactions between machines. > Nowadays I see the motto has become "Be rigid in what you accept, and modify > your templates as often as possible." This criticism applies equally to the > RA IRR as it does to the InterNIC. > I will support this criticism of the NIC, but the RA has not refused any of my submissions based on templates over a year old. > Gee, and this started out as one sentence that went "We don't run RWHOIS, our > clients don't want it, our operating system won't support it, and you better > listen when we ask for a /17 ;)" > We don't conform to any standard, we don't care what the rest of the net does, and you better give us what we want when we want it. Cute. I expected better from you of all people, Ehud. > Ehud > Owen

1 0

RFC - Roots For Consensus
by Jim Fleming 21 Nov '96

21 Nov '96

---------- From: Jim Fleming[SMTP:JimFleming@unety.net.] Sent: Thursday, November 21, 1996 9:38 AM To: 'New Newdom'; 'paul(a)vix.com'; Bob Allisat Cc: bobm(a)nic.ddn.mil; jamesf(a)arl.mil; Jim Fleming; koda(a)isi.edu; marcel(a)nsipo.nasa.gov; 'Mark Kosters'; markk(a)netsol.com; matti(a)comedia.se; psinet-domain-admin(a)psi.com; sneeri(a)ni.umd.edu Subject: RE: FW: RFC - Roots For Consensus On Wednesday, November 20, 1996 11:42 PM, Paul A Vixie[SMTP:paul@vix.com] wrote: @ > Paul A Vixie wrote: @ > >(edit)... Each root name server operator (*.ROOT-SERVERS.NET) @ > >carries exactly the data that the IANA has approved. Never more and @ > >never less. @ > @ > IANA was one fellow with a few @ > assistants. So this one fellow @ > tells nine other guys who run these @ > root servers exactly what names @ > will or will not be recognized? @ @ Yes. Think of the root name servers (not "the popular..." or "the old..." @ but simply THE ROOT NAME SERVERS) as common carriers. They are respon sible @ for accuracy and delivery but not content. @ Paul, I think it might be useful to define some common terminology. Root Name Server Primarily directs ISP Name Servers to TLD Name Servers TLD Name Server Primarily directs ISP Name Servers to SLD Name Servers SLD Name Server Primarily directs ISP Name Servers to Web and Mail Servers ISP Name Server Primarily serve customers' stub resolvers and interface with all of the above name servers in a frequency that decreases from the top (Root) to the Bottom (SLD and below) because of caching. No one argues that accuracy and coherence are not important. In fact, one way to gain better accuracy and coherence is to make sure that name servers are properly classified, configured, and maintained. One of the current problems with the overall DNS system is that the 9 "popular" Root Name Servers mix (or combine) the function of a Root Name Server and a TLD Name Server. In a similar manner, many ISPs combine the function of their ISP Name Server and one or more SLD Name Servers. This is especially true in the case where "virtual" domains are used. There are many reasons why accuracy and coherence are important. One of the main reasons is to ensure accuracy in financial accounting records, interstate commerce, and accurate fullfillment of Federal and State tax laws. I suggest that everyone operating a Root Name Server and a TLD Name Server consult with their attorneys and accountants regarding how income derived from the operation of those servers has to be properly and "accurately" attributed to the proper taxing authority at the Federal and State levels. One of the reasons why it is important to separate the Root Name Servers from the TLD Name Servers is because there may be no income and/or profits derived from operating a Root Name Server. On the other hand, operating a .COM TLD Name Server, in a particular State (let's say Kansas) means that some portion of the income derived from operating that server and service has to be attributed to the State of Kansas. That way there will be accuracy and coherence when companies file their tax returns. @ > And this is how a critical element @ > in the communications of 50+ @ > million people was being governed? @ @ Yes. This is a "principle" and its name is "coherence". (I'm quoting those @ words for the benefit of Mr. Fleming, who will probably need to look both of @ them up in a dictionary.) @ @ > What an amateurish, closed and @ > utterly bankrupt process! Bring @ > on Root 64 Mr Fleming! NOW! At @ > least there will be 64 or more @ > participants. That makes abuses @ > far more unlikely. @ > Bob Allisat @ @ You are arguing in favour of "the tyranny of the majority" and if you'll @ check your history books you'll see that it hasn't worked out well whenever @ it's been tried. @ @ If you would rather have 64 root name servers that DO NOT LISTEN TO SOME @ CENTRAL AUTHORITY and each offer their own version of the DNS name space, @ then you do not understand (a) history, (b) politics, (c) economics, @ (d) engineering, (e) science, and (f) ethics. @ Once again, I suggest that people check with their attorney's and accountants on how tax laws work at the Federal and State levels. I believe that these laws have been developed over hundreds of years and certainly cover (a), (b), (c), and (f). It seems to me that people who are focused on (d) and (e) may not understand all of the ramifications of their actions. @ "Coherence" is how we got "here" and it's how we'll get from here onward. @ IANA is changing the authority model so that there will be more lawyers and @ more insurance policies and more people able to take the heat, and under @ that expanded shield there is room for a mechanism that admits more iTLD's. @ @ But while we will see an end to the single-person authority model, we will @ NOT see an end to the need for, and the presence of, DNS coherence. You can @ rail against this and you can wail about this but DNS just will not work @ without coherence and the Internet citizenry will not be able to get useful @ work done without coherence. @ @ I have directed followups to a mailing list that I do not read. Please @ continue this discussion there without me. @ @ Paul, as long as you operate a Root Name Server and more importantly a TLD Name Server for the "commercial" .COM domain in the State of California then I would think that you would want to keep up with how the laws of that State apply to you. Also, since you appear to be operating this commercial venture as a non-profit operation (ISC?), I would think that you would also be interested in Federal Tax laws and how accuracy and coherence are key to making that system work. You can bury your head in the sand, but if you do, I suggest that it be in International waters off the coast of California, because at this point in time you are standing on Federal and State soil, and that makes you, your companies and your servers subject to the laws of those regions. If you have some special "dispensation" from the IANA or the ISOC that makes you immune from Federal and State laws, please let everyone know. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

new TERENA activity on European traffic measurements
by Ariel T. Sobelman 21 Nov '96

21 Nov '96

Hi all, Enclosed is the text of a project proposal for a TERENA activity on network metrics and statistics collection. As a kick off, we have created a task force mailing list for those interested. If you would like to join, send a message to: listserv(a)terena.nl containing only the text: subscribe tf-etm Your Real Name replacing "Your Real Name" as appropriate. Feel free to forward this to any parties you think might be interested. Regards, Ariel T. Sobelman Project name: TERENA Task Force on European Traffic Studies ----------------------------------------------------------- Justification --------------- The problem of network traffic growth prediction may be attributed to the difficulties associated with network operation. There is one common ground, however, that which is the end result: performance. Many network operators already collect basic statistics on their own network's performance and traffic flows. Typically, this includes measurement of throughput, delay and availability. However, the only baseline against which networks evaluate performance is their own past performance metrics. There is no data available for national-level comparisons with other networks' performance. It is vital for both users and providers to have access to information on end-to-end performance. Such information is beyond the realm of what is currently undertaken by individual networks. The project objective is to collect and analyse data, which will enable focusing on the causes of decreased performance, and proposing corrective actions. The activities include the development a mechanism and structure for collecting statistics of traffic loads on an end-to-end international level, measurements of delays, flow capacity and packet loss information. Objectives --------------- The vacuum created in national-level statistics/metric collection has significantly complicated planning by member countries and service providers. While detailed traffic and performance measurements are essential to identifying the causes of network problems and formulating corrective actions, it is trend analysis and accurate network/system monitoring which permit network managers to identify "hot spots", predict problems before they occur, and identify ways to avoid them by efficient deployment of resources and optimising of network configuration. As the explosive growth and dependence on the Information Infrastructure continues, it is critical that mechanisms be established to enable infrastructure planning and analysis. This proposal describes a possible mechanism for undertaking a project to concentrate current efforts. It is proposed to address these problems on two levels of relevance: 1. significance to analysis of network performance 2. relevance to Internet settlements These activities will include cross-European measurements of total traffic through specific links and the mapping of reachable destinations covered by a route, Delay measurements,flow capacity, continental averages of hops, and rate of packet loss monitoring. These measurements will be conducted using publicly available software packages. The project is not anticipated to require efforts beyond minor changes to some software. In order to enable reliable statistical analysis, the sampling periods have been set at 6 months per phase, from the starting date of phase I & II experiments. It is also intended to participate in the IPPM working group of the IETF Deliverables: ---------------- Software kit for all participating members - for total traffic stats: TCP dump samples, router stats, Network Probe Daemon - for delay measurements: ping-based utilities, Treno - for packet loss stats: To be discussed - Hop counts: traceroute Report: Guidelines for setting up a statistics-collection operation compatible with the rest of the project - guidelines for peering - topology of participating links Web site concentrating the European statistics collected - General database with all raw data - various views of the data (graphical and numeric) - analysed data, patterns, related papers, ongoing work etc. Report: Summary of network patterns and problems identified by the project Report: Results of phase I, and recommendation for immediate possible corrective steps. Final Report: Results of traffic model. A report on network patterns and identification of necessary long terms predictions and recommendation for corrective steps. Milestones -------------- Phase I 1. Web page with description of the project, participating partners and updates 2. List of issues that need to be addressed and agreed 3. Available equipment from participants (and document this on the Web site) 4. Structure of phase I statistics collection 5. Construction of data base 6. End of Phase I experiments and population of database 7. Analysis & evaluation Phase II 8. Planning of Phase 2 goals for predictive model 9. List of issues to be addressed and agreed 10. Planning experiments phase 2 11. Begin sampling 12. Analysis & final reporting Timeline Phase I November 1996: Milestone 1 & 2 December 1997: Milestone 3 April 1997: Milestone 4 June 1997 Milestone 5 June- Nov. 1997: Data collectioe phase November 1997: Milestone 7 Phase II January 1998: Milestone 8 , 9 March 1998: Milestone 10 April-Nov. 1998: Data collection phase December 1998: Milestone 12 Ariel T. Sobelman TERENA Singel 466-468 1017 AW Amsterdam The Netherlands +31-20-639-1131 (Tel) +31-20-639-3289 (Fax)

1 0

Re: Internic address allocation policy (fwd)
by William Allen Simpson 21 Nov '96

21 Nov '96

> From: Bradley Dunn <bradley(a)dunn.org> > > I do not know of any organization that would allow internal network information > > to be made available to an outside party. I think this ranks pretty > > high up on any security policy. It would probably not even be possible on > > correctly secured network. And on one that wasn't properly secured, you > > would probably hear lots of complaints about scanning or searching that > > network. > > If the internal network is that "top secret" it should be behind a > firewall and using RFC 1918 space. > Yes. Last year, when I was scanning the Class A's to determine number of actually connected hosts, my service provider kept getting complaints from so-called security folks at the affected companies. Oh, and I found a lot of routing problems (loops, etc) which are really aggravated when you hit them 255 times (each address in the range, all of them looping).... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

RE: Internic address allocation policy (fwd)
by Jim Fleming 21 Nov '96

21 Nov '96

On Wednesday, November 20, 1996 4:54 PM, Kamau Wanguhu[SMTP:kamau@africaonline.com] wrote: @ Kim Hubbard wrote: @ > @ > > @ > Now that we've established that I don't have fangs or horns (thanks to @ > Chris and Matt for clearing that up :-)) I would like to urge you all @ > to join the IRE mailing list to discuss the IP polices. @ @ Please post the subscription address. @ -- @ ================================================================ @ E. Kamau Wanguhu mailto:kamau@AfricaOnline.com @ Africa Online Inc mailto:kamau@BORGcube.com @ Medford, Massachusetts http://www.AfricaOnline.com @ TEL: 1.617.494.1515 FAX: 1.617.494.9422 @ ================================================================ @ @ Also, I suggest that people be informed of the IRE Mailing List policies. When I joined the list, I was told by the list operator, Mr. David Conrad, that some people on the list requested that I "quietly be removed". Instead of removing my name, Mr. Conrad and I agreed that it would be best if I not post to the list. I think that people should be told that some people on the list would like to be able to control who participates. People should read the exchanges on the list with that in mind, and should probably also be cautious when they post to the list, because they might be "quietly removed". -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

2 1

RWHOIS, SWIP, and proving ownership
by Ehud Gavron 21 Nov '96

21 Nov '96

Consider this a side note to the preceding discussion. 1. Most of our clients understand that their ''lease'' on network address space is at our whim, by contract for IP connectivity, and is subject to renumbering if WE assign them new space, if WE are assigned new space, or if they move elsewhere. Therefore they don't ask us to SWIP the nets nor do they care. 2. RWHOIS doesn't run on any production operating system. I know Unix is in vogue, but since we do the 99.96% uptime schtick, we use operating systems that stay up (VMS). This means we can't run RWHOIS (even if we did want to, which if you read #1 above you'll see we don't.) 3. We currently use almost all of a /18, two thirds of a /19, a few /22s, and some /24s. It would be easy to justify a /17 based on all this, but if someone wanted to be rigid about RWHOIS and SWIP, even a bunch of traceroutes aren't going to convince them. Back in THE GOOD OLD DAYS (tm), we said "Be flexible with what you accept, be rigid with what you send out." (Others made it sound better and put it in RFCs... D.C. for one.. :) Nowadays I see the motto has become "Be rigid in what you accept, and modify your templates as often as possible." This criticism applies equally to the RA IRR as it does to the InterNIC. Gee, and this started out as one sentence that went "We don't run RWHOIS, our clients don't want it, our operating system won't support it, and you better listen when we ask for a /17 ;)" Ehud

2 1

IRR
by Brian Merritt 20 Nov '96

20 Nov '96

Ok, this is in follow up to a discussion Bill Woodcock, John Hawkinson, Kim Claffy and I had on the IPNMoo (or CAIDAnce or whatever it's called) regarding the IRR. This discussion led me to ask a bunch of questions. I'd like to present these questions for discussion, and share a few of my comments. How accurately does the IRR represent the actual routing policy of the various participating networks and of the Internet as a whole? Well, according to the IRR Violations statistics at http://compute.merit.edu/problems.html, not very well. Since MAE-East is the "most important" (don't even start on that one) exchange on the Internet, let's look at the very few datapoints available. 10187 IRR violations at MAE-East on 11/13/96 9873 IRR violations at MAE-East on 11/12/96 There is no data available on the web page for any other days. Barring all of the obvious flames about the "if's" involved (number of data points, statistical methodology, what constitutes a violation, multiple violations, Merit stats don't mean anything, etc.) this doesn't look real good. If there are about 42000 paths in the "default-free" routing table (this part we know), and every last one of them is registered in the IRR (which isn't true), ~25% of the routes on the Internet do not jive with the IRR, according to these Merit stats. Obviously, this calculation isn't exactly statistically sound, but it's something to think about. The fact that there are so many if's is kind of the point, too. If you don't trust Merit stats, whose? Is there anything else available to base any sort of conclusions on? I know of at least one example of a reported "IRR violation" that isn't, so there could certainly be (many) more. Anyone from Merit care to explain how these stats are collected, and/or if they should be considered accurate? There's nothing on the web pages concerning IRR violation statistic collection methodology so far as I can tell. To quote the eloquent folks at Merit: "Maintaining accurate IRR information is important as several providers base their router configurations on IRR information. Incorrect IRR data may result in loss of connectivity. The IRR also provides a valuable source of information for analysis and debugging tools." How many providers are basing their policy solely on IRR information? Are these providers (if they exist) at all concerned with the notion that (if the RA statistics on IRR violations are at all useful) they may not be able to get to up to 25% of the Internet at any one time? Might the IRR be more harmful than goodful if it's actually used to generate router config's by any small group of providers, and not by everyone? (Unless you think segmentation is good). Is the IRR more valuable as a "source of information for analysis and debugging tools" than as a source of information to base routing policy on? I would say apparently so. Is the IRR supported? Well, as far as I can tell almost everyone that should be participating (in some form) is. Is it supported in the sense that everyone that is participating is commited to maintaining accurate information? I would say apparently not. Is it supported in the sense that it is actually used for anything other than "analysis and debugging"? (And what sort of useful analysis can be done with data that is 25% bad anyhow?) I don't know. Should the IRR be used for anything presumed to be "actually useful"? Well, I certainly wouldn't rely (solely) upon it. How about you? If the IRR were useless would it break the Internet? Nope. Could the IRR improve the Internet if it were used by everyone? Maybe. Should the IRR exist? I think yes. This whole "discussion" begs a lot of other questions. Adressing them is "beyond the scope of this document". :) To be Scott Bradner for a moment, here's a disclaimer. I don't have large sums of grant money to do statistics, and I have to rely on people who do, so don't complain about how terrible my stat is. I know many (all?) of these questions have been brought up before. I believe there is interest in discussion, and so I have brought them up again. If you don't want to talk about it, don't. These bits will not break your network (well, unless you're <insert anyones favorite congested network here>). Brian ___ Brian Merritt bmerritt(a)getnet.net ___ Principal Network Engineer GetNet International

5 4

RE: Internic address allocation policy (fwd)
by Jim Fleming 20 Nov '96

20 Nov '96

On Wednesday, November 20, 1996 3:34 PM, Snowdog[SMTP:snowdog@charm.net] wrote: @ Hello, @ @ I think that intentions of the original email is harmless and a good idea, @ however, I also think that the suggested implementation below simply 'should' @ not work. @ My main theme was that the Internet could be a nice self-policing sort of place. It is unfortunate that people and companies have grabbed addresses in the 80's and now sit on them and do not want to discuss how they are being used. Meanwhile, ISPs are asked to jump through hoops and justify tiny allocations. In my opinion, people are looking at the wrong end of the allocation food chain. While I understand that people might subscribe to the idea of..."counting the nickels and the dollars will take care of themselves..." It seems useful to point out that while this is occuring, the millions are being thrown out with the baby, the bath water and the kitchen sink. @ I do not know of any organization that would allow internal network information @ to be made available to an outside party. I think this ranks pretty @ high up on any security policy. It would probably not even be possible on @ correctly secured network. And on one that wasn't properly secured, you @ would probably hear lots of complaints about scanning or searching that @ network. @ I think that you might be jumping to conclusions as to what would go in a report. If only information went in the report which could be easily deduced via public methods would people be concerned ? Also, again I stress that the bulk of the reports would be self-generated. What we are talking about is a cultural shift, similar to what happened with Ecology. We had a neighbor who 10 years ago prided herself in telling everyone privately that she thought ecology was useless. When our city went to "vanity cans", she was one of the first to sign-up, because it was now culturally "cool" to have recycling bins at the curb. The idea is NOT to have people snooping on their neighbors. The idea is to have people check to see if their neighbors "checked" in and develop a simple report and maybe to send a reminder that the report is due. @ So, I think you are going to find in almost every instance, the other @ company telling you to politely mind your own business. Now, another @ solution might be to have one organization (InterNIC or sorts) to be @ responsible for obtaining and reviewing this information. They @ already do this to smaller providers trying to obtain new IP addresses. @ It might be possible to implement some sort of continued observations @ of issued IP addresses to ensure proper allocation. But this sounds @ like alot more potential work for an already busy entity like the InterNIC. @ That is a lot of work, and "centralized" intelligence agencies are not what the Internet world needs. @ I don't know, I just thought to mention that I liked the idea, but @ at the same time it just doesn't seem like a practical solution. @ @ Just my added thoughts... @ @ Sean Rolinson @ snowdog(a)charm.net @ Thanks for the comments. I think that it is fair to mention that I have found, in a limited survey, that people who are hording addresses hate this system and those that have nothing to hide and are PROUD of their frugal allocations and network management methods seem to endorse this sort of program. Again, the proposal is to encourage people and companies to be proud of their Internet ecology activities. In order to do that, people have to get to the PR departments of companies and show them how much GOOD publicity they will get for cleaning up their allocations. These clean-up efforts can be detected and recognized by their "binary neighbors" on the neighbor net. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

RE: Internic address allocation policy (fwd)
by Justin W. Newton 20 Nov '96

20 Nov '96

At 12:06 PM 11/20/96 -0600, Jim Fleming wrote: >I have suggested in the past a "neighbor net" approach. >It is a simple approach in which people on each side >of an allocation, be responsible for publishing a periodic >usage report. They would obtain this information from >their "neighboring" administrator. > >This approach can work for /24s, /16s and any size >allocations, as long as one is aware of who their binary >neighbor is in the IPv4 address space. > >To illustrate a /8 example, Hewlett Packard and Apple >Computer would be responsible for the report on >Digital Computer Corporation. > > Hewlett Packard - 15.0.0.0 > Digital Computer - 16.0.0.0 > Apple Computer - 17.0.0.0 > MIT - 18.0.0.0 Jim, This lynches it. You are absolutely insane. You whine and moan about having to tell the EvilInternic(tm) about your network, potential customers, etc etc, yet you believe that DEC would gladly give information to Apple about their internal network etc etc. More effort would be sepnt in court with lawyers haggeling over what DEC had to give Apple and Apple had to give DEC in order to properly be audited than would have originally been spent with an audit by an external agency doing the audit. Or wait, let me guess DISA wants to be audited by a foriegn company (30.0.0.0 for DISA and 32.0.0.0 for the foriegn company, 31 is IANA reserved, so I am assuming that it would be skipped). Yeah, that. Justin Newton Network Architect Erol's Internet Services

4 3