- Test - lists.nanog.org

NASA (and e.root-servers.net) off the air
by Chris Adams 15 Sep '00

15 Sep '00

It appears that all of NASA, including e.root-servers.net at Ames, is off the net (and has been most of the day). I've heard something about them having some kind of trouble at MAE-EAST and MAE-WEST; does anybody know anything more than that? -- Chris Adams <cmadams(a)hiwaay.net> Systems and Network Administrator - HiWAAY Information Services I don't speak for anybody but myself - that's enough trouble.

3 2

The Cidr Report
by Tony Bates 15 Sep '00

15 Sep '00

This is an auto-generated mail on Fri Sep 15 12:00:00 PDT 2000 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 15Sep00 0) General Status Table History ------------- Date Prefixes 080900 85860 090900 85892 100900 85759 110900 86110 120900 86221 130900 87010 140900 86417 150900 87093 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 *** Bogus 65.128.0.0/14 from AS209 *** Bogus 65.132.0.0/15 from AS209 *** Bogus 65.134.0.0/17 from AS209 *** Bogus 65.134.128.0/19 from AS209 *** Bogus 65.228.9.0/24 from AS577 *** Bogus 66.1.16.0/20 from AS3847 *** Bogus 66.4.0.0/17 from AS11686 *** Bogus 66.4.0.0/15 from AS11686 *** Bogus 66.4.128.0/17 from AS11686 *** Bogus 66.6.32.0/20 from AS701 *** Bogus 66.6.64.0/20 from AS14480 *** Bogus 66.6.96.0/20 from AS10970 *** Bogus 66.6.128.0/20 from AS3561 *** Bogus 66.6.192.0/20 from AS11282 *** Bogus 66.7.0.0/19 from AS16484 *** Bogus 66.7.64.0/19 from AS14618 *** Bogus 66.9.0.0/19 from AS6221 *** Bogus 66.16.0.0/17 from AS14914 *** Bogus 108.122.0.0/24 from AS9847 *** Bogus 217.0.0.0/13 from AS3320 *** Bogus 217.8.0.0/20 from AS1299 *** Bogus 217.8.32.0/20 from AS3220 *** Bogus 217.8.160.0/20 from AS8246 *** Bogus 217.8.224.0/20 from AS15560 *** Bogus 217.9.32.0/20 from AS15563 *** Bogus 217.9.36.0/22 from AS15563 *** Bogus 217.9.64.0/20 from AS3269 *** Bogus 217.9.64.0/20 from AS15671 *** Bogus 217.9.128.0/20 from AS12969 *** Bogus 217.9.160.0 from AS8308 *** Bogus 217.9.224.0/20 from AS13124 *** Bogus 217.10.0.0/20 from AS1270 *** Bogus 217.10.64.0/20 from AS15594 *** Bogus 217.10.96.0/20 from AS5556 *** Bogus 217.10.128.0/20 from AS5378 *** Bogus 217.10.160.0/23 from AS15641 *** Bogus 217.10.162.0 from AS15641 *** Bogus 217.10.192.0 from AS12302 *** Bogus 217.11.0.0/20 from AS9034 *** Bogus 217.11.64.0/20 from AS702 *** Bogus 217.11.160.0/20 from AS3259 *** Bogus 217.12.0.0/20 from AS15635 *** Bogus 217.12.192.0/20 from AS15626 *** Bogus 217.12.224.0/20 from AS15438 *** Bogus 217.13.0.0/20 from AS15659 *** Bogus 217.13.32.0 from AS15629 *** Bogus 217.13.33.0 from AS15629 *** Bogus 217.13.34.0 from AS15629 *** Bogus 217.13.192.0/20 from AS9126 *** Bogus 217.13.224.0/20 from AS3220 *** Bogus 217.14.64.0/20 from AS3303 *** Bogus 217.14.96.0/23 from AS13099 *** Bogus 217.14.128.0/20 from AS8851 *** Bogus 217.14.192.0/20 from AS3226 *** Bogus 217.15.0.0/20 from AS13064 *** Bogus 217.15.128.0/20 from AS13118 *** Bogus 217.16.96.0/20 from AS15687 *** Bogus 217.117.117.0 from AS2007 *** Bogus 220.10.56.0 from AS3215 AS Summary ---------- Number of ASes in routing system: 8464 Number of ASes announcing only one prefix: 4814 (2667 cidr, 2147 classful) Largest number of cidr routes: 898 announced by AS701 Largest number of classful routes: 1070 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 433 153 280 64.7% BCNET-AS AS9706 258 96 162 62.8% Pusan Metropolitan City Office of AS1221 609 448 161 26.4% TELSTRA-AS AS816 575 435 140 24.3% UUNET Canada (ASN-UUNETCA-AS4) AS9269 173 47 126 72.8% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS7657 318 207 111 34.9% The Internet Group Limited AS7046 370 265 105 28.4% COQUI-NET PRTC Internet AS7545 158 55 103 65.2% TPG Internet Pty Ltd AS705 365 263 102 27.9% ALTERNET-AS AS9304 117 21 96 82.1% Hutchcity AS6429 208 114 94 45.2% FirstCom Internet AS7496 126 35 91 72.2% Power Up AS4755 209 119 90 43.1% Videsh Sanchar Nigam Ltd. India AS174 533 450 83 15.6% Performance Systems International AS4293 329 249 80 24.3% Internal ASN for C&W AS3908 257 177 80 31.1% Supernet, Inc. AS6595 133 56 77 57.9% DODDSEUR AS1727 167 91 76 45.5% MRMS-WEST AS1785 386 311 75 19.4% AppliedTheory Communications AS577 251 178 73 29.1% CA-NET-AS AS3352 253 180 73 28.9% Ibernet, Internet Access Network AS724 225 154 71 31.6% DLA-ASNBLOCK-AS AS7018 582 513 69 11.9% AT&T WorldNet Service Backbone AS4792 77 11 66 85.7% SK Telecom Co., Ltd. AS5106 99 36 63 63.6% AADS-COLUMBUS AS3749 120 58 62 51.7% TECNET AS226 169 107 62 36.7% USC/Information Sciences Institut AS701 1070 1010 60 5.6% Alternet AS3602 296 240 56 18.9% Sprint Canada Inc. 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

Increase in DDOS activity
by Kevin Houle 15 Sep '00

15 Sep '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The CERT/CC has published an Incident Note, IN-2000-10, discussing widespread exploitation of vulnerabilities in rpc.statd and wu-ftpd. This activity is significant to network operators because we have seen an increase in DDoS tool deployment related to this activity. The Incident Note can be found at: http://www.cert.org/incident_notes/IN-2000-10.html Regards, Kevin -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBOcJQJ7vzUwvl02xJEQIBnACgoB5zxHv+LSmW4gc6SxqKz9J5wigAoNjX 6n85dqYLlXIya99pJwosleIF =m765 -----END PGP SIGNATURE-----

1 0

NANOG 20 & DNSSEC workshop
by Edward Lewis 15 Sep '00

15 Sep '00

For planning purposes... A while back I asked if there was interest in holding a DNSSEC workshop in conjunction with the NANOG 20 meeting. There was enough of a response to begin the planning process and we now have a room reserved. Here are the logistics for those needing to make travel arrangements. Where: Washington Marriott, 1221 22nd Street, N.W., Washington, DC 20037 (that's not the NANOG hotel - we were unable to get a room reserved there) When: Wednesday, October 25, 9am-5:30pm (more or less) Signing up: there will be a web page next week. Registration will be required, even if you have already sent me email. I will send reminders to those who have contacted be separately. Cost: $0 US What to bring: A computer (laptop) capable of running the latest BIND 9 code (see ftp://ftp.isc.org/isc/bind9/) with that code installed. Also, bring a cat 5 cable. (Wireless hasn't been decided upon yet.) As far as external Internet connectivity, nothing is promised, although we will try to provide this. ...I'd like to thank Net Soln's for arranging for the facilities. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis(a)tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer.

1 0

Re: Confussion over multi-homing
by Sean Donelan 15 Sep '00

15 Sep '00

On Thu, 14 September 2000, Brantley Jones wrote: > The problem is GETTING a /20 from anybody. We recently tried and could > only get a /23 (being a small start-up). BUT, that /23 is (apparently) > globally routable because of peering agreements with L3 and UUNET. Our /23 > prefix has yet to be filtered by anybody. It could be filtered now. You just won't find out about it until you try to reach a particular site, or they try to reach you. There is no practical way to test if an address is being "globally routed." You could try testing every address in your route table, but there is no assurance your route table is complete.

3 3

HR 4445 Reciprocal Compensation
by William Allen Simpson 15 Sep '00

15 Sep '00

"To exempt from reciprocal compensation requirements telecommunications traffic to the Internet. " Anybody know about this? Seems like it kills payments by ILECS to CLECs for dialups, when the calls are to an ISP. Note, only _TO_ an ISP; folks wanting to provide voice are still required to pay ILECs for traffic _from_ an ISP. Is this the "ILECs put ISPs out of business" act? `(A) IN GENERAL- Notwithstanding subsection (b)(5), after the date of enactment of this paragraph, no local exchange carrier shall be required to make any payment for the transport or termination of telecommunications to the Internet or any provider of Internet access service. `(B) JURISDICTION- Such transport or termination shall be considered interstate communications and subject to the exclusive jurisdiction of the Commission. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

8 8

RE: Confussion over multi-homing
by Roeland M.J. Meyer 15 Sep '00

15 Sep '00

David Lott: Thursday, September 14, 2000 10:34 AM wrote: > First, allow me to state the assumptions that I'm under. I understand > the policy to state that if a business needs to multi-home > and requires > less space than a /20, then they should request this space from their > ISP. I also understand that there are filters at the /20 > boundaries in > order to minimize the size of the routing table. > > Question: Doesn't this break multi-homing for end users that > need less > than a /20? Yep, this has been a topic here before...no real resolution. You didn't really need to prove the case, it has already been proven. The only way that you can do it is to justify a /20 or larger, get portable IP space from ARIN, and make your own peering arrangements with your upstreams. Considering that you will probably burn the best part of the /20 with distributed services, this increases your internal administration costs substantially. What you will have is a very low-density use net-block, but at least you can now multi-home and even have some geographical independence, for multiple-site use. If you have good admins, the whole thing can be folded/collapsed into about 20 physical servers, or less (Lintel boxen keep the costs low too, see: VA-Linux, about two racks). Is this wasteful of IP space? ...absolut! Is this necessary? ...sometimes. If you are building a H-Rel/Hi-Avail/Hi-Secure site(s), you ain't getting there without multi-homing with at least three providers. If you have multiple sites, you can't get there without multi-homing on an ASN that will be advertised (at least a /20, probably a /19). Do I tell clients this? ... absolut! Have I done this for clients? ... Yep, and I ain't saying who for either. --- R O E L A N D M . J . M E Y E R CEO, Morgan Hill Software Company, Inc. Managing Architect Tel: (925)373-3954 Fax: (925)373-9781 http://staff.mhsc.com/rmeyer

3 2

Confussion over multi-homing
by David Lott 15 Sep '00

15 Sep '00

I've read the current policy on ARIN's allocation of space and I must admit that I'm still confused. First, allow me to state the assumptions that I'm under. I understand the policy to state that if a business needs to multi-home and requires less space than a /20, then they should request this space from their ISP. I also understand that there are filters at the /20 boundaries in order to minimize the size of the routing table. Question: Doesn't this break multi-homing for end users that need less than a /20? For example, assume that the end user is connected to two regional ISPs (ISP-A and ISP-B). Neither of which have agreements with each other. However, they do share a common backbone with a national provider we will call ISP-Z. If ISP-Z has filters at /20 for both of the ISPs that it is connected to, then ISP-A address space will be the only space listened to on the ISP-A to ISP-Z link. The same would be true for the ISP-B address space only being listed on the ISP-B to ISP-Z link. This creates a situation where address space from ISP-B would not be advertised through ISP-A and in effect, breaks multi-homing. Consider a remote site attempting to reach the web server at the end user. DNS resolves the address to ISP-B address space. Also assume that the link between the end user and ISP-B is down. As the packet enters the national carrier ISP-Z's network, at some point the router will have to decide to send the pack on. If ISP-B is still advertising the remaining portion of their network (say at the /20 boundary) then ISP-Z will forward the packet to ISP-B. This is normal and proper for a single homed address space. However, if the end user had their own micro allocation, their address space would be advertised to both ISP-A and to ISP-B and in turn to the national carrier. As such, the destination network route would be dropped from the advertisement coming out of ISP-B and the only remaining route would be via ISP-A and the packet would still get there - if the end user had a micro allocation as per previous policy. Also, let us further look a situation where ISP-B is down. When the national carrier detects ISP-B is down it will remove that particular route from it's table. In the old way of doing things with micro allocation to multi-homed end users, ISP-A would advertise the address space from the end user. It is my understanding that under the current policy, ISP-A would have to advertise the address space allocated to the end user from ISP-B. If the address is less than a /20 and if the national carrier is filtering on a /20, wouldn't that cause the update to be dropped and thus not added to the routing table for the national carrier? I guess my confusion could be cleared up if someone could describe how, under the /20 policy, an end user requiring multi-homing and less than a /20 allocation would be able to survive one of their two ISPs going down (remember the AT&T and MCI outages?). Thanks, PS. I have sent this email to the ARIN policy list but have not received any useful responses. -- David Lott VP of Operations MSN Communications (303) 347-8303

3 2

Why did we do CIDR? (RE: Confussion over multi-homing)
by Sean Donelan 15 Sep '00

15 Sep '00

On Thu, 14 September 2000, Paul Froutan wrote: > What you can do is get permission from the ISP that provides you the IPs > (say ISP A) so you can have other ISPs announce your blocks. You also need > to get ISP A to deaggregate your block and announce it separately into the > global BGP table. We did this back in the day and it works fine if the ISP > giving you IPs is somewhat reasonable and helpful. If folks are going to deaggregate the addresses and announce multiple routes anyway, why are we going through the pain of ARIN policies. Wouldn't it be better to allocate the appropriately sized address in the first place?

4 3

2260 Multihoming
by Chandrasekar Ramachandran 15 Sep '00

15 Sep '00

What exactly is/are the reason(s) the mult-homed (to different ISPs) routing strategies suggested by RFC 2260 is not widely deployed (or not deployed at all)? I think there may be some commercial reasons too for this. thanks, Chandra.

1 0