- Test - lists.nanog.org

2q98 in-addr walk starting soon
by Bill Manning 31 May '98

31 May '98

Hi, I appologize for duplicates. Its almost time for the next quarterly walk of the inverse tree of the DNS. For the last few quarters, I've been walking the in-addr tree looking for numbers of delegations, accurate delegations, and types and styles of error conditions. So... this is a heads up that you will be seeing zone transfers being generated by a couple of the collecter machines here. For those of you who utilize BINDs access controls, I'd appreciate your inclusion of the collector machines in allowed transfers. The expectation is that they will be the following IP addresses: 128.9.160.57 and 198.32.4.13 If there are any questions or concerns, I'd be happy to talk about them. Past data has been presented at IEPG, Apricot and RIPE meetings. The expectation is that future data will be presented in the same and similar forums. --bill

1 0

RE: ingress filtering
by John Fraizer 31 May '98

31 May '98

>>Might I recommend that you actually drag out a packet sniffer and look at a >>REAL network to see it for yourself? We all know that MS of ALL companies >>believes that RFC means Request For Compliance and since it's only a >>request and not a mandate, they often opt NOT to conform to standard. >> > >Packet sniffer shows no NetBIOS over IP traffic at all. Sorry. Try again. You must have a lame sniffer. I show encapsulated packets with ours just fine. I guess it could be the silly operator and not the silly sniffer that has the problem though. >The packet sniffer shows nothing wrt port 137. I admit when I'm wrong, but >since I'm not, I won't > >Have a nice day. Will do. Please give me directions to Utopia though. Since you live there and don't see any netbios traffic with your sniffer, I would like to vacation there. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

The Great Exchange
by Pickett, David 30 May '98

30 May '98

It's evident, from reading through all of the responses to my questions on exchange of Internet traffic, that there are a lot of problems in this space, but not a lot of agreement on how to address them. Here are some summary observations based on group-wide communication, and notes sent to me directly. 1) More needs to be done to leverage locality of traffic Some great examples were given wherein simple cross-state connections were accomplished via an exchange point some one thousand miles away, a clearly sub-optimal arrangement. Fixing this problem was a point of some contention. Some said to forget about national exchange points, and just make private peering arrangements. Others noted that local exchange points are springing up in the areas that need them. Often these exchange points are the product of local ISPs working cooperatively, sometimes with the assistance of a corporate sponsor. Still others noted some commercial enterprises that are building an infrastructure and business model around the need for decent peering arrangements. To add complexity to this issue, differences arose over implementation details of a national peering system that preserved locality of traffic. Some advocated a hierarchical model, tiered if you will, that frankly sounded a lot like 5-level PSTN switching model. Others advocated a flatter model, although how that model relieves traffic at the core, and leverages locality remains to be seen. 2) Who dropped the packet? You can't fit 20 gallons of water in a ten gallon hat, at least not all at once. Oversubscription generated some heated comments from various factions. It is clear that one person's oversubscription is another person's unethical business practice. So, just how do we handle the delicate topic of oversubscription? Where is it okay to oversubscribe? Where can it absolutely not be tolerated? Oversubscription is fundamental to the design of many network switches, and is an essential aspect of many network technologies, and business plans. It's here. It's reality. How does one use it responsibly? A lot of finger pointing was done in the area of highly asymmetric and grossly underprovisioned connections to the Internet. What policies might mitigate such problems? Thoughts? 3) Internet SLAs and customer verification There was a modest amount of chest beating around verifiable levels of service. Nobody came right out and proposed Internet SLAs, but some did suggest that it would be nice to give the customer the tools for verifying the level of performance delivered by their access provider. This is an interesting angle, and we've seen evidence in the industry of some providers giving the customer limited ability to access this kind of information. NDAs seems to be at the heart of this problem. What tools do the ISPs need to provide this kind of information to the customer? Do the ISPs even want to provide this information? Is it pointless to provide this information since so much of the customer's total performance picture is dependent on factors that can't be controlled by the ISP? dp David R. Pickett Northchurch Communications Inc 5 Corporate Drive Andover, MA 01810 978-691-4649

13 14

More smurf networks. FIX YOUR ROUTERS.
by Dalvenjah FoxFire 30 May '98

30 May '98

Hi folks, I found a small list of smurf relays in a hacked account today and managed to mail all those folks privately asking that they fix their routers. I was reasonably proud of myself. Then I found this list, full of 175 different networks. Nearly all the ones I tried work, and the ones that didn't work didn't respond on other IPs either, so I'm assuming unreachability. This is a fresh list from an active smurfer, however, so it does work. (Boy, does it work. }:P ) Since it would take me upwards of two weeks just to mail these folks - unless I put off work, school, and the like - I determined it would be much better to post the list to nanog and see what doesn't work after a few weeks. (Translation: there is no way in hell I'm mailing all these folks, not even with a script to try and parse all the internic/apnic/ whatever whois outputs.) Yes, I realize this means that The Scum will start smurfing like crazy; however, this also means that those networks will get fixed quicker when they realize their outbound link is completely saturated with ECHO_REPLY. Please pass this around, call folks you know, call folks you don't know, do whatever it takes to get these folks to fix their routers. I have spent the past week dealing with various smurfs taking down ISPs, and I am getting extremely sick of it. (Note, if you're fixed, and you're on this list, I apologize; again, I don't have the time to check each and every address.) -dalvenjah 141.161.19.0 141.164.240.0 142.3.0.0 168.198.79.255 168.208.21.255 168.216.14.255 168.84.3.255 168.84.7.255 193.190.1.255 193.190.10.255 193.190.4.255 193.190.8.255 193.190.9.255 193.226.100.255 193.38.83.255 193.38.84.255 193.38.85.255 193.64.68.255 193.76.0.255 194.111.55.255 194.152.36.255 194.215.85.255 194.251.75.255 194.28.6.255 199.171.110.255 199.171.198.255 200.0.166.255 200.19.104.255 200.23.51.255 200.230.142.255 200.230.143.255 200.38.168.255 200.5.128.255 200.5.129.255 202.184.18.255 202.184.25.255 202.45.53.255 202.45.59.255 202.45.61.255 203.108.227.255 203.11.118.255 203.150.240.255 203.22.70.255 203.64.170.255 204.101.117.255 204.115.171.255 204.116.248.255 204.141.218.255 204.147.235.255 204.155.99.255 204.161.118.255 204.161.61.255 204.166.161.255 204.166.161.255 204.167.48.255 204.17.178.255 204.171.179.255 204.177.145.255 204.187.84.255 204.191.160.255 204.191.212.255 204.199.101.255 204.199.102.255 204.199.106.255 204.199.107.255 204.208.154.255 204.208.155.255 204.216.139.255 204.216.139.255 204.216.86.255 204.222.194.255 204.222.195.255 204.228.161.255 204.229.220.255 204.229.221.255 204.229.222.255 204.229.43.255 204.229.45.255 204.233.137.255 204.235.79.255 204.235.79.255 204.242.172.255 204.242.172.255 204.244.155.255 204.249.16.255 204.249.16.255 204.26.102.255 204.26.102.255 204.26.103.255 204.26.104.255 204.26.109.255 204.29.160.255 204.29.160.255 204.30.35.255 204.30.35.255 204.31.135.255 204.31.137.255 204.31.137.255 204.33.249.255 204.34.141.255 204.34.141.255 204.64.182.255 204.64.22.255 204.71.176.255 204.71.179.255 204.71.179.255 204.71.180.255 204.71.180.255 204.71.191.255 204.71.243.255 204.80.124.255 204.96.225.255 205.136.165.255 205.148.1.255 205.172.3.255 205.178.8.255 205.184.109.255 205.197.176.255 205.203.72.255 205.211.168.255 205.218.18.255 205.232.119.255 205.232.191.255 205.232.8.255 205.252.144.255 205.67.128.255 206.110.105.255 206.129.95.255 206.170.24.255 206.186.126.255 206.204.56.255 206.219.101.255 206.219.102.255 206.31.88.255 206.39.100.255 206.39.101.255 206.39.72.255 206.39.75.255 206.39.76.255 206.39.77.255 206.39.78.255 206.39.79.255 206.39.81.255 206.39.91.255 206.39.92.255 206.39.93.255 206.39.98.255 206.39.99.255 206.72.47.255 207.65.122.255 208.128.161.255 208.128.185.255 208.132.236.255 208.132.69.255 208.145.80.255 208.154.16.255 208.154.18.255 208.154.23.255 208.193.238.255 208.20.149.255 208.202.212.255 208.24.87.255 209.160.26.255 209.206.19.255 209.206.21.255 209.206.22.255 209.49.157.255 209.63.185.255 209.66.101.255 209.7.76.255 209.81.151.255 209.84.61.255 209.88.144.255 -- Dalvenjah FoxFire (aka Sven Nielsen) Fundamentalist Agnostic: "I don't Founder, the DALnet IRC Network know, and neither do you!" e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

7 6

INTERNIC Question
by Al Reuben 30 May '98

30 May '98

I've got a quickie, and I am not sure where to ask it. I am in the process of writing a domain-name registration tracking system, and I want to put some stuff in the Headers so that I can add our internal tracking numbers on it so that when we get a response, I can have a process look it over and decide what do do with it. In specific, I put X-NAC-DTS-Number: [a alex-generated number] in the header, and it didn't get returned. So, my questions are: 1) Should the Internic be retaining this X Headers? 2) Why can't the Internet put interesting things in the header so that we could unifiy the way we look at them to automatically process them? Like: X-Internic-Response: Registered or X-Internic-Response: Not-Registered-Already-taken etc? Comments welcome. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

11 11

Re: The Great Exchange
by shields＠crosslink.net 29 May '98

29 May '98

In article <19980528100840.19859(a)scfn.thpl.lib.fl.us>, "Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> wrote: > On Wed, May 27, 1998 at 10:34:18PM +0000, Michael Shields wrote: [...] > > Why are you assuming that the Internet will continue to have > > non-distance-sensitive pricing, when it clearly has distance- > > sensitive costs (ultimately)? > > Because that has been the primary driver to date of the kind of growth > the Internet has undergone. Mature markets and new markets behave differently. $19.95 unlimited dialup was a big factor in 1995 and much less so now. > That it has distance sensitive costs only > matters if you're trying to be a nationwide ultra-backbone. Actually I was thinking about international ultrabackbones. I don't see any theory or evidence that they are going away or being marginalized. You will always have to deal with them. It's in their interest to be sure that the pricing is fair. I think pricing based on the actual destination makeup of your traffic is more fair than pricing based on the assumption that your traffic is like everyone else's. I could be wrong, and I'd be happy to be shown why. But I think distance-pricing has a sound basis, even if it never materializes in the market. The major reason I see that it might not happen is that customers would tend to remain fairly similar to each other in terms of their locality; just as when customers have similar bandwidth usage, circuits tend to be sold unmetered. If I were an Australian ISP, I'd look very seriously at pricing transoceanic packets different from intracontinental packets. From what I understand the market there would be accepting; and unless there is a flaw in the reasoning of my message yesterday, you can collect that data cheaply with today's technology. > and the "big 5" would be _really_ pissed off. Good. You think ultrabackbones are doomed? Why? -- Shields, CrossLink.

3 3

RE: Cable & Wireless buys MCI Internet
by Goldstein_William＠bns.att.com 29 May '98

29 May '98

1 0

Re: flat vs non-flat charging
by Kent W. England 29 May '98

29 May '98

Jerry Scharf <scharf(a)vix.com> wrote: >I think the idea of distance charging is going away in many cases. ... >Using archaic telephone pricing models to argue cost of providing bulk IP >services is just not right. > I agree that using the regulated telephone network for Internet pricing doesn't make sense, but there is a difference developing on the Net between locally cached data and data that has to be fetched from a distance. I would not be surprised to find differential pricing being used to incent browsers to re-use locally cached data whenever possible. --Kent

1 0

The Cidr Report
by Tony Bates 29 May '98

29 May '98

This is an auto-generated mail on Fri May 29 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29May98 0) General Status Table History ------------- Date Prefixes 220598 51216 230598 51177 240598 51178 250598 51283 260598 51277 270598 51199 280598 51156 290598 50967 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3606 Number of ASes announcing only one prefix: 1730 (908 cidr, 822 classful) Largest number of cidr routes: 359 announced by AS3561 Largest number of classful routes: 1096 announced by AS701 1) Gains by aggregating at the origin AS level --- 29May98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS816 807 522 285 35.3% UUNET Canada (ASN-UUNETCA-AS4) AS4293 468 238 230 49.1% IMCI AS2493 500 294 206 41.2% iSTAR Internet, Inc. AS174 815 626 189 23.2% Performance Systems International AS3602 493 310 183 37.1% Sprint Canada Inc. AS701 1096 918 178 16.2% Alternet AS3749 220 65 155 70.5% TECNET AS2048 164 92 72 43.9% LaNet AS5668 115 46 69 60.0% Century Telephone Inc. AS3221 110 41 69 62.7% EENet Autonomous System AS3248 129 61 68 52.7% VIAnet AS4755 95 28 67 70.5% Videsh Sanchar Nigam Ltd. India AS10928 108 44 64 59.3% UNKNOWN AS271 113 54 59 52.2% BCnet Backbone AS7046 190 132 58 30.5% UUNET-CUSTOMER AS3804 200 142 58 29.0% Bell Solutions AS549 206 154 52 25.2% ONet Backbone AS4539 74 24 50 67.6% NETROPOLIS AS1221 274 224 50 18.2% AARNET-AS AS72 85 37 48 56.5% Schlumberger Information Network AS6335 67 19 48 71.6% NTRNET AS1239 541 494 47 8.7% SprintLink Backbone AS4740 357 314 43 12.0% ASN-OZEMAIL (Ozemail Pty Ltd) AS852 159 118 41 25.8% AGT Advance Communication AS4200 136 96 40 29.4% AGIS (Apex Global Information Ser AS1591 144 105 39 27.1% SAIC DISM AS719 442 404 38 8.6% LANLINK autonomous system AS3493 165 127 38 23.0% INTERLINK AS6392 68 31 37 54.4% MidWest Communications, Inc. AS6181 65 28 37 56.9% FUSE-NET For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: ingress filtering
by John Fraizer 29 May '98

29 May '98

At 08:09 AM 5/29/98 -0400, you wrote: >Actually it has nothing to do with WINS. If all the ISP's would implement >solid in-addr.arpa reverse mappings, this would go away. Microsoft's DNS >resolver has been extended, when DNS lookups fail, to do a reverse NETBIOS >query against the target machine so it can use its name when displaying >stuff via NBTSTAT, etc. It was designed this way, before the Internet >became popular. The reverse on the name being queried works just fine: [OverKill]:/# nslookup www.stefcam.com Server: NS1.ENTERZONE.NET Address: 209.41.244.5 Name: STEFCAM.COM Address: 209.41.244.238 Aliases: www.stefcam.com [OverKill]:/# nslookup 209.41.244.238 Server: NS1.ENTERZONE.NET Address: 209.41.244.5 Name: StefCAM.Com Address: 209.41.244.238 ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1