February 2002 - Test - lists.nanog.org

Re: Contact for Telemail.com.mt / Datastream.com.mt
by Stephane Bortzmeyer 09 Feb '02

09 Feb '02

On Saturday 9 February 2002, at 3 h 5, Avleen Vig <lists-nanog(a)silverwraith.com> wrote: > If anyone has a contact address for either of these ISP's, please contact > me off list. Did you try the phone numbers in the RIPE database? After all, maintaning that database up to date is so much work that it has to be useful some times :-) person: Philip Cassar address: Telemail Limited address: Suite 1 Cali House address: Naxxar Road address: San Gwann address: Malta address: SGN07 phone: +356 380180 fax-no: +356 380190 e-mail: philip(a)telemail.com.mt nic-hdl: PC4939-RIPE changed: philip(a)telemail.com.mt 20000703 source: RIPE person: Christopher Debono address: Telemail Limited address: Suite 1 Cali House address: Naxxar Road address: San Gwann address: Malta address: SGN07 phone: +356 380180 fax-no: +356 380190 e-mail: chris(a)telemail.com.mt nic-hdl: CD3238-RIPE changed: chris(a)telemail.com.mt 20000703 source: RIPE person: Geoffrey Cauchi address: Datastream Ltd. address: Telepage Buildings address: Psaila Street address: B'Kara address: Malta address: BKR 02 phone: +356 2567 7257 fax-no: +356 446830 e-mail: geoffrey.cauchi(a)datastream.com.mt nic-hdl: GC5493-RIPE notify: geoffrey.cauchi(a)datastream.com.mt mnt-by: GC5493-RIPE-MNT changed: geoffrey.cauchi(a)datastream.com.mt 20011203 source: RIPE

1 0

The Cidr Report
by CIDR Report 09 Feb '02

09 Feb '02

This is an auto-generated mail on Fri Feb 8 23:00:00 PST 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 08Feb02 0) General Status Table History ------------- Date Prefixes 010202 105568 020202 105595 030202 105578 040202 105667 050202 105600 060202 105584 070202 105721 080202 105598 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12381 Number of ASes announcing only one prefix: 7537 (4280 cidr, 3257 classful) Largest number of cidr routes: 717 announced by AS701 Largest number of classful routes: 1357 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1156 892 264 22.8% Telstra Pty Ltd AS701 1357 1126 231 17.0% UUNET Technologies, Inc. AS577 323 197 126 39.0% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 821 703 118 14.4% AT&T AS4151 261 149 112 42.9% USDA AS6595 168 60 108 64.3% DoD Education Activity Network As AS17557 195 88 107 54.9% Pakistan Telecom AS705 293 189 104 35.5% UUNET Technologies, Inc. AS852 425 325 100 23.5% Telus Advanced Communications AS7046 329 230 99 30.1% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS12302 110 31 79 71.8% MobiFon S.A. AS1239 475 398 77 16.2% Sprint AS4755 221 150 71 32.1% Videsh Sanchar Nigam Ltd. Autonom AS4323 406 340 66 16.3% Time Warner Communications, Inc. AS703 279 217 62 22.2% UUNET Technologies, Inc. AS3464 157 97 60 38.2% Alabama SuperComputer Network AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 209 151 58 27.8% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS3908 320 264 56 17.5% Supernet, Inc. AS226 145 89 56 38.6% Los Nettos AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS19834 63 8 55 87.3% NetForce, Inc. AS702 654 600 54 8.3% UUNET Technologies, Inc. AS1 491 438 53 10.8% BBN Planet AS2149 308 256 52 16.9% Performance Systems, Inc. AS9051 73 22 51 69.9% INCONET Autonomous System Total 53855 42131 11724 21.8% 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: Reducing Usenet Bandwidth
by Michael Painter 09 Feb '02

09 Feb '02

>>If you ask a question, you should pay. If I provide you with useful help, you should pay. If I suggest a commercial solution to your problem, who should pay? If I harass you for not knowing the answer to the question, I should pay.<< Hmm, reminds me of the Compu$erve Forums, which, ironically, met their demise (imho) when the WWW (and Usenet) started to blossom. ex 70720,151 ----- Original Message ----- From: "David Schwartz" <davids(a)webmaster.com> To: "Stephen Stuart" <stuart(a)tech.org>; <nanog(a)merit.edu> Sent: Friday, February 08, 2002 3:32 PM Subject: Re: Reducing Usenet Bandwidth > > > >I would argue that what USENET needs is a way for the cost of > >publication to be incurred by the publisher; storing the data in your > >own repository (or repositories) while pointers get flooded through > >the USENET distribution system would give publishers an incentive to > >do garbage collection that they do not have today. > > Like many Internet settlement schemes, this seems to not make much sense. If > a person reads USENET for many years enjoying all of its wisdom, why should > he get a free ride? And why should the people who supply that wisdom have to > pay to do so? A USENET transaction is presumed to benefit both parties, or > else they wouldn't have configured their computers to make that transaction. > > Does it make sense for the New York Times to pay me to read it? But perhaps > it does for the Weekly Advertiser. > > The reason that automated schemes such as "publisher pays" will fail is > because determining who "should" pay is too complex for automated schemes. > You will just push around who takes advantage of who. > > If you ask a question, you should pay. If I provide you with useful help, > you should pay. If I suggest a commercial solution to your problem, who > should pay? If I harass you for not knowing the answer to the question, I > should pay. > > DS > >

1 0

Contact for Telemail.com.mt / Datastream.com.mt
by Avleen Vig 08 Feb '02

08 Feb '02

Foreword: I know this list is be definition for 'North America' but I've run out of places to turn to. telemail.com.mt are currently operating a huge smurf amplifier in Malta, and the have been unresponsive to requests to fix it, for 3 weeks. Emails to their upstream provider's abuse address (abuse(a)datastream.com.mt) are bouncing. This is a Bad Thing. If anyone has a contact address for either of these ISP's, please contact me off list. For the curious, the average number of responses from this network is currently ~17,000. -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

1 0

Re: Reducing Usenet Bandwidth
by Steven M. Bellovin 08 Feb '02

08 Feb '02

In message <00e801c1b0fe$e15f8580$0100007f(a)flex.com>, "Michael Painter" writes: > >Kinda' off topic, but I've seen this gibberish in many spam posts to usenet >groups. What purpose does it serve? > >Thanks, > >--Michael > > >"She may will virtually cook above Ron when the sticky wrinkles >nibble with the sharp river. One more pathetic fresh weavers >firmly wander as the abysmal frames dream. > >Why will you reject the sweet deep tags before Priscilla does? > >Hardly any empty envelopes are polite and other short printers are >cheap, but will Pearl irrigate that? She'd rather cover eventually than >scold with Ophelia's fat dose. > >Are you kind, I mean, arriving without handsome candles? He might >judge the difficult sauce and explain it in front of its light. >Every proud dryers dye Jay, and they wistfully receive Elisa too. Get your >easily climbing ball inside my mirror. You won't help me recommending >outside your smart monument. Some forks fear, excuse, and taste. Others >angrily sow." > Some spammers add random gibberish to foil assorted anti-spam techniques. If this gibberish is different than the gibberish the same ad has in another newsgroup, it will appear to be a different post, and won't be canceled. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

Ethernet EP - MAC Address Filtering
by David McGaugh 08 Feb '02

08 Feb '02

Just curious if anyone is performing MAC Address Filtering at any of the Ethernet Exchange Points. If so has it been found to be easy to administer or difficult where by peers may be changing Layer 3 devices or Interfaces without notice? Alternately is MAC Address Filtering considered an unneeded security measure? Thanks, Dave

2 3

C&W Engineering
by German Martinez 08 Feb '02

08 Feb '02

Hi, Somebody from C&W Engineering that can contact me off-line Thank you German ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * THE DILBERT FUTURE * * Thriving on Stupidity in the 21st Century * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Internet capacity will increase indefinitely to keep up with the egos of the people using it"

1 0

Re: Reducing Usenet Bandwidth
by Jonas M Luster 08 Feb '02

08 Feb '02

Quoting Vadim Antonov (avg(a)exigengroup.com) > In other words - USENET cannot be fixed with technological improvements as > long as the root problem (admission control) is not solved. Improving > transmission or storage systems would only let spammers to send more spam > for free. > > Therefore, i'd say it is time to declare USENET defunct. It was fun while > it lasted. Usenet. That's the sum of all systems exchanging data via RFC1036. Usenet, that's not the Big5 or, even less so, alt.ALL. Declaring Usenet defunct because a part of it, using its structures, has failed to exercise the righth measures, is about as logical as declaring the Web defunct just because Slashdot is. Usenet's traffic is to some 98% comprised of binaries. A huge amout of them (some 85%, actually) is repeat traffic, IOW the same picture maybe with a different slogan attached to it or a different URL superimposed over it. By limiting Usenet back to something that can be read with more in /var/spool/news, you reduce traffic and storage requirements. Usenet, also, ist not Outlook Express or something one should read with multipart-reassemblers, one hand on the mouse. Let's face it. Usenet is not defunct. It works quite well, and that for more than twenty years, whereas the Web still lies in its infancy and already shows sings of decay. Its users may be defunct. Its adminitative mechanisms may be defunct. But Usenet is not. But, and here i aggree with you, unless clue-midgets such as Cable and Wireless start having an abuse department, unless Joe A CIO learns that networks are more than just cables to bring his website to the masses, Usenet will have no chance to remain what it once was - a bandwidth friendly, system agnostic, blazing fast communications medium.

1 0

The Great RADB Clean-Up
by Christerfer R. Frazier 08 Feb '02

08 Feb '02

Effective April 2, 2002, Merit Network, Inc. will begin the process of removing RADB maintainer objects that have not been renewed and paid for 2002. This message is to inform the community about our clean-up process so that RADB users can take measures to minimize any operational impact. All maintainers scheduled for removal will be posted before March 15, 2002 at http://www.radb.net/docs/deletelist.html. Currently, about 2,100 maintainers with 52,000 total objects are unpaid and scheduled for removal beginning April 2 unless payment is made. Of the total 2,100 maintainers, 1,100 have associated valid objects in the RADB. These 1,100 maintainers, in turn, have 22,000 associated valid objects that are currently being routed in the Internet. For example, eleven of the top twenty maintainers (in terms of number of total objects) have not yet been renewed and are scheduled for removal. We are currently making a targeted effort to remind the owners of maintainers with valid objects about the deadline. About 1,000 "stale" maintainers with either invalid objects or no objects at all will be removed as part of the clean-up. All maintainer IDs scheduled for removal will be posted on the RADB Clean-up web page at http://www.radb.net/docs/deletelist.html before March 15, 2002. As of today, only some of the maintainers have been posted. At the same URL, you will also find a tool to check for a specific maintainer and associated objects (if any) targeted for removal. If you are filtering routes based on the RADB, we urge you to stay abreast of this information. We will be providing regular updates via the NANOG list and on the web page. The RADB service fee for January 1, 2002 through December 31, 2002 is $250 per maintainer object. The RADB service agreement must be renewed annually. Merit's policy, as specified in the agreement, is to remove maintainers that have not been renewed and paid. As a non-profit organization, Merit does not pursue profit as a goal. The $250 maintainer fee is strictly a cost recovery mechanism that helps support the ongoing 24x7 operations of the RADB. Costs that Merit must cover through maintainer fees include contracting for 24x7 NOC monitoring; server maintenance and connectivity; help-desk support; second-level 24x7 on-call engineering; and maintenance of the IRRd database server software that powers the RADB. We welcome your input on the RADB clean-up. The Merit RADB team will be on hand to discuss questions and concerns about the database clean-up during the Route Registry BOF at NANOG24 on Monday, 9:00-10:30 PM. We hope you'll join us! URLS: To view or query the list of maintainer IDs scheduled for removal: http://www.radb.net/docs/deletelist.html To review the RADB maintainer object agreement: http://www.radb.net/docs/agreement.html To renew RADB service and pay for your maintainer object: https://www.merit.edu/cgi-bin/radb/pay/alive For general information: http://www.radb.net For Merit RADB, Chris Frazier

1 0

"Tier 1 Backbones" which don't filter IP packets? --SUMMARY
by Ehud Gavron 08 Feb '02

08 Feb '02

On January 27th, while pimping the latest NANOG Traceroute at ftp://ftp.login.com/pub/software/traceroute/beta I asked about providers that don't administratively prohibit LSRR and SSRR packets. Response was overwhelming, and I've finally gone through all the responses. Requests for summary were overwhelming, and I've BCCd all of those who requested that, but thought I'd CC the list since there's such interest. Thanks for all the feedback, especially those who took the time to provide official responses from the various corporations... and I'm sorry I couldn't respond to everyone individually. Ehud LSRR and SSRR SUMMARY: Some providers REQUIRE it for peering. Lots of providers ALLOW it from customers and peers. Only one was verified to deny LSRR/SSRR and admit to it. There is a good work in progress page at http://www.gweep.net/~crimson/networks/lsrr.html REQUIRE: (alpha order) Genuity [verified] RCN [from URL above] ViaNet [from URL above] Verio [verified] WiscNet [from URL above] ALLOW: Cable & Wireless Sprintlink Global Crossing Hurricane Networks E.Spire Worldcom AT&T DO NOT ALLOW AND ADMIT TO IT: Time Warner Telecom [verified] -end-

1 0