- Test - lists.nanog.org

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

Re: Why does Sprint have address filters again?
by Sean M. Doran 29 May '98

29 May '98

| I think either I am missing the point or others are. We plan on | sending traffic through each others backbones. In essence we will be | one huge network. Sharing traffic. I can do this with private as | numbers? As long as your AS numbers are unique within a limited scope, they can be any number. The "limited scope" part is important, and requires care to avoid accidentally leaking the advertisements beyond the scope (especially into another limited scope where the same AS numbers are in use). If you are providing the announcements learned at an exchange point (or more precisely, within the limited scope) to nth parties (or more precisely, ASes not within the limited scope), it would suffice to remove the private-use AS(es) from the AS path and prepend one own's AS (maybe multiple times) to keep the path length consistent. A twisty way to think about it is that if you are one huge network, in your words, you can be an AS confederation of sorts. Sean.

1 0

Re: Why does Sprint have address filters again?
by John Golovich 29 May '98

29 May '98

I think either I am missing the point or others are. We plan on sending traffic through each others backbones. In essence we will be one huge network. Sharing traffic. I can do this with private as numbers? > On Fri, 29 May 1998, John Golovich wrote: > > > In the Detroit area alot of smaller ISPs are looking to create a > > peering between each other to create shorter router for wherever > > traffic needs to go (ie. transit routing). > > > > This plan has been placed on hold and almost officially shelved > > because alot of the smaller ISPs dont see the need for an AS number. > > Since it's private peering anyway, why not use 64xyz numbers? > > Not to sound spoiled or something, but once those ISPs stop being small > ISPs and become reasonably large ISPs they'll need an AS number anyway. > $500 is way too much for an ASN, but it's not much compared to what I pay > for a 4500 router. > > With regards, > > -- > Niels Bakker, * * EuroNet Internet BV > Network Operations * * Herengracht 208-214 > * 1016 BS Amsterdam > NJB9 * +31 (0)20 535 5555 >

2 1

RE: Cable & Wireless buys MCI Internet
by Pete Farmer 29 May '98

29 May '98

J.D. Falk [mailto:jdfalk@vix.com] wrote on Friday, May 29, 1998: > God, this is all so DERANGED. > >> It would if MCI was selling off the entire Internet segment >> of the company. Right now it looks like they're actually >> only selling a tiny chunk (probably the chunk that's got >> "Internet" in the name as opposed to "data services"), so >> it's pretty clearly just a token effort -- but it might >> work, leaving MCI Worldcom free to screw us all over. ISP/C's objection to the MCI/WorldCom combination was stated as follows: ++++++++++ Worldcom's UUNet division has made recent changes in its peering and pricing policies which lead us to be concerned about possible predatory actions in this regard [if the merger is allowed]. Furthermore, Worldcom has control of most of the peering points domestically through its MFS division, while international peering points are controlled by Worldcom's division of UUNet... If the merger is approved, we urge strong consideration to the divestment of InternetMCI from the merger equation. ... [Additionally,] the extent of [MCI/WorldCom's] underlying [transmission] capacity poses a reasonable threat to a broad spectrum of traditional stratification in the telecommunications marketplace. http://www.ispc.org/policy/filings/fcc19980320.shtml ++++++++++ I assume that their concerns stated in that first paragraph are satisfied by MCI's action. Commercial ISPs will be contracting with C&W, not MCI/WorldCom, for wholesale access and peering. The second concern is not addressed. However, I regard it as without merit. The merger will not cause undue concentration of transmission capability, given strong direct competitors (AT&T, Sprint) and numerous upstarts (Level 3, Qwest, IXC, Williams, et. al.). Any reaction from current MCI wholesalers or other ISPs? Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

2 1