- Test - lists.nanog.org

Re: History question, Morris worm
by Dean Anderson 22 Nov '99

22 Nov '99

I don't have a reference, but I suspect that what you are thinking of is that CSNet shutdown very early, preventing the innoculation message (sent by Morris via his friend from the OSF which was a CSnet customer) from getting out for 3 days. The worm was <probably> released from MIT, and Morris <probably> went across the street to the OSF to see his friend from his undergraduate days at Harvard about the problem. They composed and sent out a message describing the worm, its accidental escape, what it exploited, and how to stop it. But CSnet had already shutdown and the message stayed in queue at the OSF for 3 days. Much of the panic was due to the lack of communications about the nature of what was going on. This was made worse by sites shutting down. Morris' message didn't get out for 3 days. By then, Spafford and others had decompiled and analyzed the program, figured out by themselves how to stop it, and were making fun of it. And they were pissed. Due to lack of information, they assumed it was hostile. If the innoculation message had gotten out early on, fears of a hostile attack would have been allayed, and people would not have responded as though under hostile attack. So, I suppose CSnet bears some responsibility for the ensuing panic, and Morris' subsequent prosecution. --Dean Around 03:50 PM 11/21/1999 -0800, rumor has it that Sean Donelan said: > >>and what's more fun, when they come back up on jan 3 or whatever, they will >>have whatever y2k problems then. > >I recall after the Morris worm hit the Internet, reading a report sites >which unplugged their ARPANET connection were down longer than sites which >remain connected and got repair information over the net. > >Does anyone else remember that, and knows a citation for the report (or >news story) I'm recalling? > >Thanks. > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: ISP Address Allocation
by Aleksi Suhonen 21 Nov '99

21 Nov '99

Hello, Let me guess: you want to make demographics of different ISPs' users for web advertising purposes and that is why you need to know which IP belongs to which ISP. RIPE database licence says you can't use their data for that purpose and I would be surprised if ARIN (or any of the others) allowed it. (Just as a reminder.) -- Aleksi Suhonen

1 0

Re: ARIN to Allocate from 64.0.0.0/8
by Aleksi Suhonen 21 Nov '99

21 Nov '99

Hello, Richard Steenbergen and Kai Schlichting discussed how this new allocation policy affects ingress filtering. I was disgruntled too when I heard of it for the same reason. The way I fixed it was that I just changed the filter from 64.0.0.0/2 to 96.0.0.0/3. It isn't as perfect though of course. -- Aleksi Suhonen

1 0

Some networks will be down on Jan 1
by Sean Donelan 20 Nov '99

20 Nov '99

A person forwarded me this information. Whether Y2K affects anything, sites plan to shutdown over New Year's. In case you get trouble calls, you won't be able to send e-mail to places like Cornell. http://www.cit.cornell.edu/y2k/y2kdown.html Fortunately they are leaving the phone switch up, assuming you got their phone number ahead of time. Why do I get this sinking feeling there will be a lot of confusion over what is up, what is down, what is supposed to be down, and what is supposed to be up. And contacting their upstream usually isn't much help. The last time Tufts and Boston were down, their upstream didn't respond for over 24 hours. And then only to say, everything looked ok to them a day later.

2 1

Merit IRR Service Announcement
by Gerald Andrew Winters 19 Nov '99

19 Nov '99

Merit will be suspending RIPE-181 IRR service tomorrow morning, November 20, at 7am EST for routine system maintenance. The downtime is expected to last for less than an hour. During this period RIPE-181 queries to whois-rpsl.radb.net will be unavailable. Database updates to auto-ripe181(a)radb.net may be submitted but expect a delayed response until the maintenance is complete. Our primary production RPSL service will be unaffected. If you have any questions please direct them to db-admin(a)radb.net. Jerry Winters IRRd Team

1 0

should TCPs do MTU black hole detection?
by Vern Paxson 19 Nov '99

19 Nov '99

The IETF's tcp-impl (TCP implementation) working group has a draft document discussing problems with path MTU discovery: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-02.txt The main issue we're trying to decide is whether the draft should advocate "black hole detection". That is, when a TCP is doing PMTU discovery, but somewhere the necessary ICMPs are either not being generated or are being filtered out before the TCP receives them, the TCP notices that it's losing multiple packets of the same size, so it then tries sending smaller segments, even though it hasn't received a "Datagram Too Big" ICMP. The plus of black hole detection is that it can work around a sometimes very hard to debug problem. The minus is that it masks problems that should instead be fixed. To help resolve this issue, I'm wondering whether the ISP community has a clear preference for either yes-do-detection or no-we-want-the-problems-fixed. Comments appreciated. Thanks, Vern

7 9

The Cidr Report
by Tony Bates 19 Nov '99

19 Nov '99

This is an auto-generated mail on Fri Nov 19 12:00:00 PST 1999 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 19Nov99 0) General Status Table History ------------- Date Prefixes 041199 66135 051199 66177 061199 66189 071199 66095 081199 66195 091199 66908 101199 65842 111199 67577 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: 4241 Number of ASes announcing only one prefix: 1433 (0 cidr, 1433 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1720 announced by AS1890 1) Gains by aggregating at the origin AS level --- 19Nov99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1890 1720 797 923 53.7% UUNET NL Autonomous System AS271 383 141 242 63.2% BCnet Backbone AS7046 389 258 131 33.7% UUNET-CUSTOMER AS2609 126 11 115 91.3% EUnet-TN AS1221 614 506 108 17.6% TELSTRA-AS AS9269 123 30 93 75.6% Hong Kong CTI AS7657 253 162 91 36.0% The Internet Group Limited AS7545 146 60 86 58.9% TPG Internet Pty Ltd AS7496 123 38 85 69.1% Power Up AS174 555 471 84 15.1% Performance Systems International AS4293 220 138 82 37.3% Internal ASN for C&W AS577 263 182 81 30.8% Bell Canada Backbone AS3749 138 63 75 54.3% TECNET AS4200 181 111 70 38.7% AGIS (Apex Global Information Ser AS6944 63 6 57 90.5% RapidSite, Inc. AS4740 347 292 55 15.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS816 239 190 49 20.5% UUNET Canada (ASN-UUNETCA-AS4) AS209 304 257 47 15.5% Qwest Communications AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS9304 55 16 39 70.9% Hutchcity AS4755 107 68 39 36.4% Videsh Sanchar Nigam Ltd. India AS6528 45 7 38 84.4% WORLD-LYNX AS549 206 168 38 18.4% ONet Backbone AS2493 125 87 38 30.4% iSTAR Internet, Inc. AS719 195 159 36 18.5% LANLINK autonomous system AS701 962 926 36 3.7% Alternet AS6629 63 28 35 55.6% NOAA-AS AS1 503 468 35 7.0% GTE Internetworking AS7568 48 14 34 70.8% C.S. Communications Co., Ltd. AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) 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

GW-List - Routing Maintenance
by brandon＠rd.bbc.co.uk 19 Nov '99

19 Nov '99

I haven't seen this mentioned, they'll go on to do the others then life will be wonderful? ----- Begin Included Message ----- >From Gateways-owner(a)COWS.NET Fri Nov 19 00:07:28 1999 From: n1uro(a)www.n1uro.ampr.org Date: Fri, 19 Nov 1999 0:03:49 GMT Subject: GW-List - Routing Maintenance On Wednesday 11/24 at 12:01AM PST MAE-West Ames will be taken down for reconfiguration. The outage window is from 12:01AM PST to 6:00AM PST. The purpose of the reconfiguration is to eliminate the Head-Of-Line blocking problems caused by the DEC Gigaswitch FDDI. The Gigaswitches will be moved to an edge position at the exchange and divided into multiple logical bridges AKA: expect ampr.org to vanish for a few ----- End Included Message -----

1 0

Proactive notification, one disaster at a time
by Sean Donelan 19 Nov '99

19 Nov '99

Since I posted about the problem, I guess I should also post when a company announces an improvement. Worldcom announced today it will proactively notify customers about network problems. Its subsidary, UUNET, had a proactive notification program for a few years. Worldcom joins other companies such as BBN (now GTEI), who established a proactive notification program after a rat took down its west coast operation and AT&T announced improvements in its notification program after its network outage last year including multiple notification methods. We all know there will be network problems from time to time. Its good to see one more company's management decide to add proactive customer notification. I speak only for myself.

2 1

RFC1712 - is anyone actually using GPOS RR's ?
by Jesper Skriver 18 Nov '99

18 Nov '99

Hi, As subject says, is anyone actually using these ? We were thinking of adding this to our automated dns scripts ... but if nobody actually uses them, we don't want to spend time on it ... /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

4 5