- NANOG - lists.nanog.org

InterNIC problems?
by Peter Murray 04 Mar '98

04 Mar '98

I've not heard anything from the InterNIC in recent days - forms submitted via their web page aren't resulting in forms in my inbox anymore. Has anyone else noticed a distinct lack of InterNIC mail lately? The last time I got anything from them was 15.45 on 2/28/98. Hmmm.. now that I think of it, I haven't seen any recent NANOG postings in a while - not since the "Halon-protected colo space available" posting on 3/1/98, at 21.12. I've received other mail, but these two sources have been noticeably quiet. We'll see what this posting does. Thanks for any insight! -Pete Pete Murray - FASTNET(tm) / You Tools Corporation > pete(a)fast.net (610) 954-5200 - http://www.fast.net > FASTNET - Business and Personal Internet Solutions >

5 4

Re: routing registries....
by Ben Kirkpatrick, ELI 04 Mar '98

04 Mar '98

As I mentioned in my original post, I will summarize the responses I received. This is fairly easy since I only got one message and it said simply, "Use the RADB". To a company like the one I'm currently participating in, using the RADB is unacceptable because they want to have complete security and control over the database. This is rather short-sited, but it's not my decision. I'll be researching more in the near future and send an update then. --Ben Kirkpatrick. On Tue, 3 Mar 1998 someone wrote: > on 2/9/98, you sent a posting to nanog, asking what most large NSP's were > doing in the way of routing registries? RADB or a local database....what > kind of responses did you get?

2 1

Re: Internic PGP Auth busted
by Sanjay Dani 03 Mar '98

03 Mar '98

> requirement so that you can then change each one to CRYPT. [File away > that first response that has your encrypted password. I am told you don't > ever get it again.] If you are lucky (?), the (A)ck/(N)ak NOTIFY message that goes to the "other" contact might include your password. I saw my password, as the admin contact for a domain, included in the NOTIFY message that went to the technical contact, luckily it was our own NOC. Regards, Sanjay. PS. Thanks to everyone who responded to my query on overseas telco provisioning, I will post one summary when the info is complete. --------------------------------------------------------------- Web Professionals, Inc. Direct: +1 408-863-4850 20111 Stevens Creek Blvd, Suite 145 Biz/NOC: +1 408-863-4848 Cupertino CA 95014 USA http://web.professionals.com --------------------------------------------------------------- -=- Your Outsourcing Partner for Website and Server Hosting -=-

4 3

Halon-protected colo space available (how do I market it?)
by Brian Topping 02 Mar '98

02 Mar '98

Hi all, I have a 1000 sq ft Halon protected vault in San Francisco (about 1.5 miles from downtown) that I am looking to sublet some space in. We can rack it out or sell it by the square foot. It has about 10 tons of redundant AC and copper access to a PacBell Lightspan 200 mux in the building MPOE. We also have about a thousand square feet of concrete outside for the location of condensers and generators. We are very close to the power plant and as a result were not affected by the power outage in SF the other day. We expect that we will improve the HVAC and power as time proceeds. I would like to move quickly to get some deposits on moving in, and am willing to do what it takes to get them. If anyone has ideas about targeted marketing in this arena or are interested themselves, please contact me at this address. Thanks! Brian Topping

1 0

don't fall victim to FUD was Re: action: Santa Clara CA & Montgomery MD
by Gordon Cook 28 Feb '98

28 Feb '98

Dear Nanog list members and Congress people Before you get too excercised about Bill Simpson's allegations in the message below let me provide some context that is missing from Mr. Simpson's message. On Monday in the IETF mail list considerable anger was displayed over the statement in the Green Paper that the IANA Policy Council would "coordinate the development of other technical protocol parameters as needed to maintain universal connectivity on the Internet." It was pointed out that the proper function should be to "coordinate the **assignment** of other technical protocol parameters . . ." On Monday afternoon I interviewed Ira Magaziner and brought up this issue. On Monday evening I posted to the IETF list Ira's statement to me that development was mistaken and assignment should have been used. On Feb 25 Scott Bradner posted the a separate denial from IRA to IETF list: Date: Wed, 25 Feb 1998 08:48:53 -0500 (EST) From: Scott Bradner <sob(a)harvard.edu> To: ietf(a)ns.ietf.org Subject: from Ira Magaziner Re: IETF relationship to new IANA I asked Ira Magaziner about the wording in the Green Paper in the area of the relationship between the IETF and the new IANA. This is his reply which he said I could forward. Scott ---- Mr-Received: by mta EOPMRX; Relayed; Mon, 23 Feb 1998 18:12:16 -0500 Alternate-Recipient: prohibited Disclose-Recipients: prohibited Date: Mon, 23 Feb 1998 18:10:00 -0500 (EST) Subject: Re: this is what I am very worried about To: sob(a)harvard.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Ua-Content-Id: MBLINKAA X400-Mts-Identifier: [;61218132208991/1513276@EOPMRX] Hop-Count: 1 Message Creation Date was at 23-FEB-1998 18:10:00 Thanks for your note. The wording of the green paper is a mistake. We certainly do not intend for the IETF to in any way become subserviant to this new organization. We will correct it in the next draft. Ira ========== In his Feb 23rd interview with me Ira said: Magaziner: Let me make clear then what is going on. I think that the word "development" was not a correct word to represent the function we were trying to indicate and that has been pointed out to us by a number of people. So that is a good criticism. There are mistakes in this report as there would be in any report and when they are pointed out, we acknowledge them and say we will fix them. Whether the word assignment or not is the right one I don't know, but development is clearly the wrong word. I think the process of assigning port numbers is what we are trying to convey. Secondly I think it is accurate to say that we would respond to the sense of the broader community about whether that function which has been performed by Postel historically should be performed by this new organization or whether it should be performed by the IETF itself. I think whatever the community wanted to do on that would be OKAY with us. That is the way I put it. I did not say have power or not have power. What we did in our report was to propose it as a continued IANA function, or if the IETF wished to that it could assume the authority. But let me again make it very clear we don't intend this word development. That was a mistake." ======= Cook: In his interview Ira also made it very clear that the IANA policy Council is to have control of the root servers and not the US government. Consequently it seems to be that Mr. Simpson is feeding the current atmosphere of mistrust and suspicion by moving a problem that quite clearly has been answered on the IETF list to the NANOG list and into Congress where many are unaware of what has transpired on the IETF list. Note also that I have just pulled down both the jan 30th text and the federal register texts of the green paper. I searched both texts for the string policies and standards for those activities and found nothing in either one. I might suggest that Mr. Simpson give us the complete citations of what he is ranting against for, on the basis of my knowledge of the green paper and conversations with Magaziner he is falsely accusing the US government and seeking to stir up dissension that will do none of us any good. It would be far more useful if he would apply his talents to the establishment of an IANA policy council that protected the ability of the net to run its own affairs. There will be an IANA policy council.... Jon postel himself is working on it. The IANA functions must be institutionalized. Jon is not immortal. Why not accept this reality and work toward that institutionalization instead of undermining efforts designed to accomplish it via fear, uncertainty, and doubt? ============================================================== >Gentlefolk, the US proposed rule taking over the Internet root servers has >many issues that may be of concern to network operators. Here are two >congressional offices that have expressed interest in electronic comments. >They want to gauge current levels of interest by the community. > >If you live or have business offices in these areas, or somewhere near, >please take a moment to send a short email to one of these representatives >in the next few days. The congress members are in recess (that means >at home) this week, and go back next Tuesday. > > >Zoe Lofgren > zoegram(a)lofgren.house.gov > Please include a complete U.S. Postel address. > > Local Office: > 635 North 1st Street, Suite B > San Jose, CA 95112 > tel: 408-271-8700 > Washington: > 318 Cannon Building > Washington, D.C. 20515 > tel: 202-225-3072 > >Constance A. Morella > Rep.Morella(a)mail.house.gov. > Be sure to include U.S. Postal address. > > Rockville (301) 424 - 3501 > Office 51 Monroe Street, Suite 507 > Rockville, Maryland 20850 > Washington (202) 225 - 5341 > Office 2228 Rayburn House Office Building > Washington, D.C. 20515 > > >Some issues of particular concern are: > > - the proposed rule allows the US government to control > "... policies and standards for those activities, including ... > interoperability, privacy, security, ...." > > Do we really think it would be a good idea for the US government > to control the standards for interoperability? > > Do we really think it would be a good idea for the US government > to control the standards for privacy and security? > > Especially as operators, do we really think it would be a good idea > for the US government to control the passwords and keys for the root > servers? > > Please think hard about the consequences. Will they let your domain > into the system (sign your NS records) unless you agree to escrow > your server keys with them? > > - Since the announcement last year, we have been looking forward to > the day (March 31) when NSI no longer has monopoly control over > registration. The proposed rule extends the monopoly another 6 > months (minimum), and control of the major domains indefinitely > (at least 2 years). > > Do we really think that is a great idea? After a year has passed, > and no plans for transition have been made by NSI? > > - The root servers are currently run by volunteers. The proposed > rule would take over operation, and give it to a new corporation, > set up by the US government. > > Are we having any real problems with our current servers? > > Do we really think it is a great idea for the US government to be > actively involved at all? *************************************************************************** The COOK Report on Internet New Special Report: Building Internet 431 Greenway Ave, Ewing, NJ 08618 USA Infrastructure ($395) available. See (609) 882-2572 (phone & fax) http://www.cookreport.com/building.html cook(a)cookreport.com Index to 6 years of COOK Report, how to subscribe, exec summaries, special reports, gloss at http://www.cookreport.com ***************************************************************************

4 4

Can you explain why paths to same host diverge?
by Mark Boolootian 28 Feb '98

28 Feb '98

Folks, We've been seeing some large latencies to sites inside of UUNET lately. In trying to figure out where the latency is coming from (UUNET or our provider, Sprint), I observed something which has me baffled. I have two hosts on the same subnet. One of them is 128.114.2.53 and the other is 128.114.2.91. Here are ping results from these machines to www.uu.net: from 128.114.2.91: PING www.uu.net (199.170.0.30): 56 data bytes, 100 packets 100 packets transmitted, 100 packets received, 0% packet loss round-trip (ms) min/avg/max = 362/548/778 (std = 103) from 128.114.2.53: PING www.uu.net (199.170.0.30): 56 data bytes, 100 packets 100 packets transmitted, 100 packets received, 0% packet loss round-trip (ms) min/avg/max = 92.9/107/139 (std = 8.43) The RTT from 128.114.2.91 are always much higher (many times a full order of magnitude) than those of 128.114.2.53. The explanation for the differing RTTs turns out to be that the paths between each of my machines and www.uu.net are different. In the below traceroutes, everything agrees up through hop five. But at hop six, the paths diverge: from 128.114.2.53: traceroute to www.uu.net (199.170.0.30): 1-30 hops, 38 byte packets 1 comm-g.UCSC.EDU (128.114.2.252) 4.52 ms 2 frontdoor.UCSC.EDU (128.114.103.1) 1.15 ms 3 UC-net-dmz.ucsc.edu (208.1.176.6) 1.45 ms 4 bgty-lata01.ucnet.net (192.35.219.2) 7.79 ms 5 sl-gw10-stk-11-0-T3.sprintlink.net (144.228.146.49) 8.70 ms 6 sl-bb10-stk-2-1-155M.sprintlink.net (144.232.4.78) 30.2 ms 7 sl-bb3-stk-0-0-0-155M.sprintlink.net (144.232.4.42) 33.0 ms 8 Hssi8-1-0.BR1.SFO1.ALTER.NET (137.39.166.121) 42.3 ms 9 114.ATM3-0-0.XR1.SCL1.ALTER.NET (146.188.145.222) 76.9 ms 10 100.ATM2-0-0.TR1.SCL1.ALTER.NET (146.188.145.226) 41.3 ms 11 107.ATM8-0-0.TR1.DCA1.ALTER.NET (146.188.136.221) 110 ms (ttl=242!) 12 199.ATM4-0-0.XR1.TCO1.ALTER.NET (146.188.161.161) 223 ms (ttl=243!) 13 193.ATM5-0-0.GW2.FFX1.ALTER.NET (146.188.160.209) 158 ms (ttl=242!) 14 UUNET7-GW.UU.NET (137.39.12.162) 214 ms (ttl=241!) 163 ms (ttl=241!) 15 www.uu.net (199.170.0.30) 155 ms (ttl=240!) from 128.114.2.91: traceroute to www.uu.net (199.170.0.30): 1-30 hops, 38 byte packets 1 comm-g.UCSC.EDU (128.114.2.252) 1.29 ms 2 frontdoor.UCSC.EDU (128.114.103.1) 1.7 ms 3 UC-net-dmz.ucsc.edu (208.1.176.6) 2.82 ms 4 bgty-lata01.ucnet.net (192.35.219.2) 7.75 ms 5 sl-gw10-stk-11-0-T3.sprintlink.net (144.228.146.49) 10.6 ms 6 sl-bb11-stk-1-1-155M.sprintlink.net (144.232.4.98) 11.2 ms 7 sl-bb3-stk-4-0-0.sprintlink.net (144.232.4.14) 9.27 ms 8 Hssi8-1-0.BR1.SFO1.ALTER.NET (137.39.166.121) 609 ms 9 114.ATM3-0-0.XR2.SCL1.ALTER.NET (146.188.145.210) 541 ms 10 100.ATM3-0-0.TR2.SCL1.ALTER.NET (146.188.145.246) 578 ms 11 107.ATM8-0-0.TR2.DCA1.ALTER.NET (146.188.136.225) 633 ms 12 198.ATM8-0-0.XR2.TCO1.ALTER.NET (146.188.161.185) 683 ms (ttl=243!) 13 192.ATM12-0-0.GW2.FFX1.ALTER.NET (146.188.160.221) 622 ms (ttl=242!) 14 UUNET7-GW.UU.NET (137.39.12.162) 569 ms (ttl=241!) 534 ms (ttl=241!) 15 www.uu.net (199.170.0.30) 579 ms (ttl=240!) Can anyone explain to me why paths would diverge in this fashion? These traceroutes aren't aberrations - the packets follow these forward paths consistently. Clues greatly appreciated. thanks, mb --- Mark Boolootian UC Santa Cruz

5 6

Re: Can you explain why paths to same host diverge?
by Tim Salo 28 Feb '98

28 Feb '98

> From: John Hawkinson <jhawk(a)bbnplanet.com> > Subject: Re: Can you explain why paths to same host diverge? > To: booloo(a)cats.ucsc.edu (Mark Boolootian) > Date: Fri, 27 Feb 1998 20:11:48 -0500 (EST) > Cc: nanog(a)merit.edu > [...] > I feel obligated to ask -- is there some reason you didn't > direct your query to Sprint, before asking NANOG? It really seems like > this is the kind of question they should be able to answer for you, > and diagnose the problem to some extent. I can't see a good reason to ask > here without asking the providers in question, first. > [...] I rather suspect that you provided a much more interesting, and much more public, answer than Mark would have received from Sprint. Now, if you hadn't provided such an informative answer, your question might be a better fit. -tjs

2 1

don't fall victim to FUD
by William Allen Simpson 27 Feb '98

27 Feb '98

Gordon, I thought that you claimed to be a reporter? Why are you posting to the North American Network Operators Group? Why are you cross-posting our discussions to congressmembers? And why did you seize upon wording that was not mentioned in the message? I was talking about the privacy and security of our root servers, and the domain zones they point to, not the IETF standards process (although there are also interference problems there). Most root servers are _NOT_ owned or run by the US government, and having the US government try to move ownership of them all to a new corporation is repugnant to many of us. We are doing just fine, thank you very much. Are we supposed to be impressed that you are now having direct talks with Ira Magaziner, when one of our own capable members has been unable to get an appointment for a month? Normally, of course, on this list we talk about actions that we need to take on our own behalf, usually dealing with operations, as opposed to detailed legal analysis. To your message of FUD (Fear Uncertainty and Doubt): > From: Gordon Cook <cook(a)cookreport.com> > Note also that I have just pulled down both the jan 30th text and the > federal register texts of the green paper. I searched both texts for the > string > > policies and standards for those activities > > and found nothing in either one. > Perhaps when you are reporting on legal issues, you might learn to read legal documents. A US Rule implements US statutory authority. In this case, the proposed rule published in the Federal Register cites as authority: 47 U.S.C. 902(b)(2)(H). Try searching there. Now, some of the legal analysts say that the proposed rule abuses the power of that section, that the section only applies to the executive branch, and that there is no legal authority to set up a corporation for international commerce. But that's what the proposed rule says, and until the proposed rule is withdrawn and re-published, that is the wording we have to comment upon. > In his Feb 23rd interview with me Ira said: > > Magaziner: Let me make clear then what is going on. I think that the word > "development" was not a correct word to represent the function we were > trying to indicate and that has been pointed out to us by a number of > people. So that is a good criticism. There are mistakes in this report as > there would be in any report and when they are pointed out, we acknowledge > them and say we will fix them. Whether the word assignment or not is the > right one I don't know, but development is clearly the wrong word. I think > the process of assigning port numbers is what we are trying to convey. But do we even want the US government involved in "assignment"? I am glad that he admits "there are mistakes". The proper action by him is to withdraw the proposed rule. But again, until the proposed rule is withdrawn and re-published, that is the wording we have to comment upon. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

40lb Marshmallow Bags
by Scott Huddle 27 Feb '98

27 Feb '98

FYI. An interesting article on how some others administer a numbering plan. "...We are not out of phone numbers. It turns out there are plenty of unused phone numbers out there, millions of them. After the phone company was decentralized in 1984, competing carriers arose. Some were very small. They needed phone numbers to distribute to their new clients. The North American Numbering Plan gave out the numbers, one exchange at a time. An exchange was a package of 10,000 phone numbers, and you had to take them all, even if you didn't have enough customers. This was necessary, according to [Ronald] Conners [administrator of the NANP], because the phone company's switching equipment required the first six digits -- the area code and the exchange -- to identify the billing and routing of a call. It could not further subdivide the number without causing chaos. Unfortunately, this also resulted in many unused numbers. Millions of unused numbers. Conners talks of this as though it were inevitable. This is like Giant selling marshmallows only in 40-pound bags, and then sadly lamenting that there are a lot of stale marshmallows out there in people's homes. ..." -scott http://www.washingtonpost.com/wp-srv/WPlate/1998-02/22/077l-022298-idx.html

2 1

The Cidr Report
by Tony Bates 27 Feb '98

27 Feb '98

This is an auto-generated mail on Fri Feb 27 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 27Feb98 0) General Status Table History ------------- Date Prefixes 200298 49181 210298 49167 220298 49121 230298 49244 240298 49374 250298 49380 260298 49515 270298 49830 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 64.0.0.0 from AS7777 *** Bogus 65.0.0.0 from AS7777 *** Bogus 66.0.0.0 from AS7777 *** Bogus 67.0.0.0 from AS7777 *** Bogus 68.0.0.0 from AS7777 *** Bogus 69.0.0.0 from AS7777 *** Bogus 70.0.0.0 from AS7777 *** Bogus 71.0.0.0 from AS7777 *** Bogus 72.0.0.0 from AS7777 *** Bogus 73.0.0.0 from AS7777 *** Bogus 74.0.0.0 from AS7777 *** Bogus 75.0.0.0 from AS7777 *** Bogus 76.0.0.0 from AS7777 *** Bogus 77.0.0.0 from AS7777 *** Bogus 78.0.0.0 from AS7777 *** Bogus 79.0.0.0 from AS7777 *** Bogus 80.0.0.0 from AS7777 *** Bogus 81.0.0.0 from AS7777 *** Bogus 82.0.0.0 from AS7777 *** Bogus 83.0.0.0 from AS7777 *** Bogus 84.0.0.0 from AS7777 *** Bogus 85.0.0.0 from AS7777 *** Bogus 86.0.0.0 from AS7777 *** Bogus 87.0.0.0 from AS7777 *** Bogus 88.0.0.0 from AS7777 *** Bogus 89.0.0.0 from AS7777 *** Bogus 90.0.0.0 from AS7777 *** Bogus 91.0.0.0 from AS7777 *** Bogus 92.0.0.0 from AS7777 *** Bogus 93.0.0.0 from AS7777 *** Bogus 94.0.0.0 from AS7777 *** Bogus 95.0.0.0 from AS7777 *** Bogus 96.0.0.0 from AS7777 *** Bogus 97.0.0.0 from AS7777 *** Bogus 98.0.0.0 from AS7777 *** Bogus 99.0.0.0 from AS7777 *** Bogus 100.0.0.0 from AS7777 *** Bogus 101.0.0.0 from AS7777 *** Bogus 102.0.0.0 from AS7777 *** Bogus 103.0.0.0 from AS7777 *** Bogus 104.0.0.0 from AS7777 *** Bogus 105.0.0.0 from AS7777 *** Bogus 106.0.0.0 from AS7777 *** Bogus 107.0.0.0 from AS7777 *** Bogus 108.0.0.0 from AS7777 *** Bogus 109.0.0.0 from AS7777 *** Bogus 110.0.0.0 from AS7777 *** Bogus 111.0.0.0 from AS7777 *** Bogus 112.0.0.0 from AS7777 *** Bogus 113.0.0.0 from AS7777 *** Bogus 114.0.0.0 from AS7777 *** Bogus 115.0.0.0 from AS7777 *** Bogus 116.0.0.0 from AS7777 *** Bogus 117.0.0.0 from AS7777 *** Bogus 118.0.0.0 from AS7777 *** Bogus 119.0.0.0 from AS7777 *** Bogus 120.0.0.0 from AS7777 *** Bogus 121.0.0.0 from AS7777 *** Bogus 122.0.0.0 from AS7777 *** Bogus 123.0.0.0 from AS7777 *** Bogus 124.0.0.0 from AS7777 *** Bogus 125.0.0.0 from AS7777 *** Bogus 126.0.0.0 from AS7777 *** Bogus 213.0.0.0/8 from AS7777 *** Bogus 214.0.0.0/8 from AS7777 *** Bogus 215.0.0.0/8 from AS7777 *** Bogus 216.0.0.0/8 from AS7777 *** Bogus 217.0.0.0/8 from AS7777 *** Bogus 218.0.0.0/8 from AS7777 *** Bogus 219.0.0.0/8 from AS7777 *** Bogus 220.0.0.0/8 from AS7777 *** Bogus 221.0.0.0/8 from AS7777 *** Bogus 222.0.0.0/8 from AS7777 *** Bogus 223.0.0.0/8 from AS7777 AS Summary ---------- Number of ASes in routing system: 3268 Number of ASes announcing only one prefix: 1551 (799 cidr, 752 classful) Largest number of cidr routes: 429 announced by AS3561 Largest number of classful routes: 1125 announced by AS701 1) Gains by aggregating at the origin AS level --- 27Feb98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 575 352 223 38.8% iSTAR Internet, Inc. AS4293 426 223 203 47.7% IMCI AS816 604 432 172 28.5% UUNET Canada (ASN-UUNETCA-AS4) AS701 1125 961 164 14.6% Alternet AS174 798 637 161 20.2% Performance Systems International AS3602 459 306 153 33.3% Sprint Canada Inc. AS3749 198 55 143 72.2% TECNET AS3751 125 48 77 61.6% SNET-AS AS1221 419 342 77 18.4% AARNET-AS AS5668 110 38 72 65.5% Century Telephone Inc. AS3804 203 141 62 30.5% Bell Solutions AS3221 93 33 60 64.5% EENet Autonomous System AS1239 582 523 59 10.1% SprintLink Backbone AS271 112 56 56 50.0% BCnet Backbone AS3464 117 63 54 46.2% Alabama Research and Education Ne AS549 211 162 49 23.2% ONet Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS4763 128 80 48 37.5% Telstra New Zealand AS7046 133 89 44 33.1% UUNET-CUSTOMER AS6181 66 22 44 66.7% FUSE-NET AS4755 76 32 44 57.9% Videsh Sanchar Nigam Ltd. India AS3561 886 844 42 4.7% MCI AS2711 97 55 42 43.3% SUNBELT-AS AS10722 73 31 42 57.5% Aluminum Co. of America AS852 157 117 40 25.5% AGT Advance Communication AS6335 63 23 40 63.5% NTRNET AS4740 345 306 39 11.3% ASN-OZEMAIL (Ozemail Pty Ltd) AS3493 166 127 39 23.5% INTERLINK AS1 782 743 39 5.0% BBNPLANET AS719 437 400 37 8.5% LANLINK autonomous system 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