- NANOG - lists.nanog.org

[whoisdatabase@hotmail.com: Re: Network Solutions Lists]
by James Rishaw 13 Dec '98

13 Dec '98

Ugh! There's *got* to be a way to keep people from walking the database... -- jamie rishaw (efnet:gavroche) American Information Systems, Inc. jamie at ais dot net infrastructure engineering "I will NOT go to a party with a version number." -davidr

3 3

Re: [whoisdatabase@hotmail.com: Re: Network Solutions Lists]
by John Fraizer 13 Dec '98

13 Dec '98

At 10:44 AM 12/13/98 +0800, Mathias Koerber wrote: >Lern to quote properly, James Rishaw did *not* say what you attributed to >him below, in fact he complained about it. I tell you what. If you will turn on your spell checker and take a `lude and chill out, I'll be more careful when I quote. (Notice your spelling of the word "learn" above.) If you will note the email a bit more carefully, you will notice that I did not attribute it directly to Jamie. >At 06:12 PM 12/12/98 -0600, James Rishaw wrote: > >>Please do not be offended by this email. >>This is not a mass spam mailing. Your >>email address is on an Opt-In list of domain >>owners who are interested in increasing >>their website traffic. Do you notice the ">>"? That indicates that it has been quoted twice. I am quoting HIS quoting something. ------------------------------------------------------------------ ML.ORG is gone. Check out http://EZ-IP.EnterZone.Net ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8

1 0

Re: Y2K Was: Re: POWER: San Mateo/San Francisco power outage report
by Roeland M.J. Meyer 12 Dec '98

12 Dec '98

At 05:52 PM 12/9/98 , Forrest W. Christian wrote: >On Wed, 9 Dec 1998, Nathan Stratton wrote: > >> I just wanted to clarify something, I got a few email messages from people >> who said I was one of the nuts who is saying the world would fall apart >> Y2K, I think everything will work out. I do not recommend anyone fill >> baggies full of dried food, buy a gun, or build a house underground. I >> think we will get though this ok. > >While I fully agree with Nathan, having appropriate supplies around to be >able to survive a week or so without power or heat or water or being able >to buy food is probably a good thing. Regardless if it is January 1, 2000 >or not. It is always a good-thing(tm) when living in earthquake country <grin>. BTW, underground shelters are also viewed as ready-made coffins around here. BTW, any SF Bay Area ISPs effected by that little shindig on the Hayward fault last week? ___________________________________________________ Roeland M.J. Meyer - e-mail: mailto:rmeyer@mhsc.com Internet phone: hawk.lvrmr.mhsc.com Personal web pages: http://staff.mhsc.com/~rmeyer Company web-site: http://www.mhsc.com ___________________________________________________ Who is John Galt? - "Atlas Shrugged" - Ayn Rand

1 0

The Cidr Report
by Tony Bates 11 Dec '98

11 Dec '98

This is an auto-generated mail on Fri Dec 11 12:00:00 PST 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 11Dec98 0) General Status Table History ------------- Date Prefixes 041298 56909 051298 54481 061298 54434 071298 54459 081298 54420 091298 54487 101298 54540 111298 54438 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: 4309 Number of ASes announcing only one prefix: 2109 (1119 cidr, 990 classful) Largest number of cidr routes: 357 announced by AS3561 Largest number of classful routes: 981 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Dec98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 349 152 197 56.4% BCnet Backbone AS3749 230 70 160 69.6% TECNET AS2493 331 184 147 44.4% iSTAR Internet, Inc. AS1785 542 402 140 25.8% NYSERNet Backbone AS701 981 845 136 13.9% Alternet AS174 678 548 130 19.2% Performance Systems International AS4200 188 96 92 48.9% AGIS (Apex Global Information Ser AS5668 125 39 86 68.8% Century Telephone Inc. AS1267 109 30 79 72.5% IUNET-AS AS4293 205 133 72 35.1% IMCI AS4755 136 65 71 52.2% Videsh Sanchar Nigam Ltd. India AS549 220 154 66 30.0% ONet Backbone AS4740 387 326 61 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS1221 396 338 58 14.6% AARNET-AS AS8517 127 71 56 44.1% UNKNOWN AS7046 249 196 53 21.3% UUNET-CUSTOMER AS7545 116 66 50 43.1% TPG Internet Pty Ltd AS7657 136 88 48 35.3% The Internet Group Limited AS72 88 40 48 54.5% Schlumberger Information Network AS1239 524 477 47 9.0% SprintLink Backbone AS7496 75 30 45 60.0% Power Up AS577 209 164 45 21.5% CA*net Networking Inc Backbone AS3221 84 42 42 50.0% RIPE-ASNBLOCK4 AS852 172 131 41 23.8% AGT Advance Communication AS10928 88 47 41 46.6% UNKNOWN AS719 438 401 37 8.4% LANLINK-AS AS803 71 35 36 50.7% SaskNet Backbone AS3564 69 36 33 47.8% Microserve Infromation Systems In AS2707 65 32 33 50.8% WEC AS7122 107 75 32 29.9% MTS ADVANCED Network Policy 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

Verio New York City problems
by Rishi Singh 11 Dec '98

11 Dec '98

At 7:22 PM EST, we lost all routing & DNS our upstream; Spacelab.Net (Verio NYC). Calls to1-888-837-4628 (Verio Customer Care Center) result in a message stating that "Verio New York City is currently experiencing technical difficulties which prevent you from accessing the internet. Engineers are working on the problem." Calls to our provider, SpaceLab result in no one picking up, even on their LAN Support Lines and after hours pager. Anyone else out there in NYC using Verio and having problems? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <o> Rishi M. Singh - Sysadmin & Network "Cleaner" <o> "My Mackie 8*bus console, Alesis Monitor Two, Fostex DAT & <o> "Shure Mics. Sit right here baby, and let me show you the power." <o> --The Cool Manhattan Midnight Groove dipped in brandy, light up <o> --the sax, dim the lights and record till daylight! - Living by Jazz <o> --Standard Time, a memory of summer 95'. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

DNS TTL
by Andrew Staples 11 Dec '98

11 Dec '98

I hope this is considered operational... A new customer of ours, blah.com, was using a different (unnamed) network for dns services. This other company had messed up the dns zone, with a 1 year ttl in some of the dns records. The domain has been transferred to our dns servers, with correct settings. Various disparate networks are unfortunately using the old cache entries. Short of emailing each network as we find the problem (usually by email not getting through), or asking the old mx ip owner (critical path) to forward the mail from their smtp server, is there anything else to be done? Hmm, just checked, and the old provider is still lame hosting the dns zone, even though it isn't authoritative. Perhaps they just like it that way. Thanks, Andrew

1 0

A tribute to Jon Postel
by Martin Cooper 10 Dec '98

10 Dec '98

/* Apologies to those who receive multiple copies of this owing to their presence on multiple mailing lists. */ I was saddened to learn of the recent passing of Jon Postel, to whom so many people owe so great a debt of gratitude for his contribution to shaping the Internet which so many people use and earn their living through today. In pondering how I should remember him, I settled upon his robustness principle, which is as equally good advice when applied to life as to internetworking. /* 1.3.2 Robustness Principle At every layer of the protocols, there is a general rule (from [TRANS:2] by Jon Postel) whose application can lead to enormous benefits in robustness and interoperability: Be conservative in what you do, be liberal in what you accept from others. */ Also, whilst browsing the Bibliography of the O'Reilly Sendmail V8 text recently, I was amused to find a reference to the following early RFC, published in the year I was born, which illustrates Jon's great vision wonderfully appropriately. /* Network Working Group Jon Postel (SRI-ARC) Request for Comments: 706 Nov 1975 NIC #33861 On the Junk Mail Problem In the ARPA Network Host/IMP interface protocol there is no mechanism for the Host to selectively refuse messages. This means that a Host which desires to receive some particular messages must read all messages addressed to it. Such a Host could be sent many messages by a malfunctioning Host. This would constitute a denial of service to the normal users of this Host. Both the local users and the network communication could suffer. The services denied are the processor time consumed in examining the undesired messages and rejecting them, and the loss of network thruput or increased delay due to the unnecessary busyness of the network. It would be useful for a Host to be able to decline messages from sources it believes are misbehaving or are simply annoying. If the Host/IMP interface protocol allowed the Host to say to the IMP "refuse messages from Host X", the IMPs could discard the unwanted messages at their earliest opportunity returning a "refused" notice to the offending Host. How the IMPs might do this is an open issue -- here are two possibilities: The destination IMP would keep a list (per local Host) of sources to refuse (this has the disadvantage of keeping the network busy). The destination IMP on receiving the "refuse messages from Host X" message forwards the message to the source IMP (the IMP local to Host X). That IMP keeps a list (per local Host) of destinations that are refusing messages from this source Host. This restriction on messages might be removed by a destination Host either by sending a "accept messages from Host X" message to the IMP, or by resetting its Host/IMP interface. A Host might make use of such a facility by measuring, per source, the number of undesired messages per unit time, if this measure exceeds a threshold then the Host could issue the "refuse messages from Host X" message to the IMP. */

1 0

POWER: CORRECTION: San Mateo/San Francisco Power
by Sean Donelan 10 Dec '98

10 Dec '98

Some corrections: Official Start time: 8:17AM Pacific Standard Time Official End time: 3:52PM Pacific Standard Time Root cause, failure by a work crew to *UN*ground two safety ground straps after completing work on the 115Kvolt line at the San Mateo Coyote Point substation. 1 Fatality, a women struck at an intersection with non-functioning traffic signals. San Francisco has two subway systems. BART was able to move their trains to the next station, reportedly in some cases after a 1-2 hour delay. MUNI evacuated people on foot through the tunnels. San Francisco International Airport had emergency power for runway lights and navagation, and did land planes during the outage. The jetways, baggage conveyers, security checkpoints, ticketing systems, etc did not have power. Because the airport can't handle large numbers of passengers without power other flights were delayed, cancelled or diverted to other airports. Effect on Major/Minor Internet providers. A number of people wrote in saying that provider XYZ had problems. There may not have been any 'major' problems with 'major' providers, there were some minor/major problems with major/minor providers. How individual customers were affected varied, mostly depending on the customers' own backup planning. Generally the Customer Premise Equipment lost power (or backup power) before the ISP's equipment went down. Telephone calling volume was up 43% in the Bay area. This may have lead to a higher number of ISP/busy/no connection problems with dialup access. The most common reported problem was with webserver farms only having limited backup battery. I also received a report of a provider's customer service PBX system battery failing, so their phones gave ring-no answer. Providers generally gave priority to routers and access servers over web and mail servers. You could often use the Internet, but your mail or web page may have been unavailable. E-Mail is automatically queued for 2-4 days, so very few e-mail messages should have been lost, only delayed a few hours. When evaluating how your provider did, ask where their POP is and if it lost utlity power. I've noticed some provider sales people already enaging in some competitor bashing, saying they stayed up while provider X didn't. However in some cases, it was because they were located in a different area and never lost utility power. Effects on other industries. Banks may have a lot of backup systems to protect them, but their customer access systems appear less reliable. 600 ATM machines, and 200 bank branches in the area were shutdown due to the power outage. One person noted that Nordstroms, long noted for their customer service, remained open throughout the power outage. At other stores, clerks couldn't make sales without computer price lookup and approval, especially for 'sale' items. VISA/Mastercard say their credit card approval systems remained operational, but some store's inhouse PBX and Verifone terminals didn't have battery backup. Some grocery stores shutdown, others implemented an "honor" system where people used pencil and paper to write the prices off the shelf tags, since the UPC laser scanners require power. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Help with identifying a kind of attack.
by Adam D. McKenna 10 Dec '98

10 Dec '98

tcp and udp are transport layer protocols. If someone is sending raw IP packets that aren't using a particular transport protocol, maybe they could get through (?) --Adam -----Original Message----- From: Thom Youngblood <thom(a)cais.net> To: North America Network Operators Group <nanog(a)merit.edu> Date: Tuesday, December 08, 1998 5:55 PM Subject: Help with identifying a kind of attack. :-----BEGIN PGP SIGNED MESSAGE----- :Hash: SHA1 : : :I've been tracking an attack all day long, and have been frustrated :trying to figure out both what was being attacked, and how. Finally, :I realized it was *not* ICMP, UDP, or TCP. : :#sh access-lists 151 :Extended IP access list 151 : permit icmp any 20.0.0.0 0.255.255.255 (1023 matches) : permit udp any 20.0.0.0 0.255.255.255 (4347 matches) : permit tcp any 20.0.0.0 0.255.255.255 (86444 matches) : deny ip any 20.0.0.0 0.255.255.255 (5547308 matches) : permit ip any any (4450563 matches) : : :In the above, notice the disparity? So, my question is... : :What the hell kind of packet is it if it's not ICMP, UDP, or TCP? : : :-----BEGIN PGP SIGNATURE----- :Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com> : :iQA/AwUBNm2jB2fkezbzToVaEQIQQQCgllupf+cmax8w5n/RgYhlATz+BuQAn38r :Di2Ec9bI2Prrahm9yKp5rohS :=/qOm :-----END PGP SIGNATURE----- : :

3 2

Re: More Sidgemore on per-bit pricing
by Dean Anderson 10 Dec '98

10 Dec '98

At 06:43 PM 12/9/1998 -0500, Jay R. Ashworth wrote: >> I was just saying how you could lower the cost of the ADSL loop from >> around $150 to $30, with both you would need to supply the IP. The idea >> would be that you would not just use the port for internet traffice. You >> would provide voice services, you would provice VOD (video on demand), and >> cable services (using something like I Magic TV). > >Oh yeah, I got that, Nathan. It's just that I get miffed when people >keep going on (don't take this personal) about how cool it is that I >can get my loop down from $300 to $150... when my router port is still >$1800. Nice, yeah, but not what people mean when they blather about >"cheap bandwidth". If it's _that_ cheap, it's running under completely >different assumptions than a standard T-1; viz: cable modems. Um, actually, I think think you can get DSLAM's for about $700 per port or less going by my recent informal surveys. Router ports have been way overpriced for a long time. They were overpriced when an AGS sold for 30K with a stack of ethernet, serial, and an fddi port. Of course, back then the pricing model optimistically expected to sell only a few thousand. They got even more overpriced later, and now expect to sell hundreds of thousands. What I've yet to find out is what sort of latency one gets with a DSL modem as compared to a DSU... I'm not sure DSL is somehow inferior technology (as Bob Metcalfe seems to think from an article several years ago), or if it just represents a (slight) change and a collapse of the fee structure. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2