December 2002 - Test - lists.nanog.org

RE: Operational Issues with 69.0.0.0/8...
by Randy Bush 06 Dec '02

06 Dec '02

> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP there already has been a canadian ip address registry. there no longer is. learn from history. randy

1 0

RE: Operational Issues with 69.0.0.0/8...
by Kris Foster 06 Dec '02

06 Dec '02

> > How would more registries help? It would just add more > voices, not the > > number of ears listening.. > > Canadians have a lot more influence on CIRA than on ARIN. Without the pressure from operators assigned out of new space no action would take place. If it was possible to return a block for a new one, there's only so much address space that a RIR could possibly hand out, we'll still come back to the problem of routing new blocks. Kris

1 0

RE: Operational Issues with 69.0.0.0/8...
by Kris Foster 06 Dec '02

06 Dec '02

> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP How would more registries help? It would just add more voices, not the number of ears listening.. Kris

2 1

Microsoft DNS Outage?
by william＠elan.net 06 Dec '02

06 Dec '02

Looks like microsoft is having dns outage.. Anybody else seeing this or is it only me? [william@sokol william]$ whois microsoft.com(a)completewhois.com | more [whois.crsnic.net] Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: MICROSOFT.COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server[with whois ip]: DNS1.CP.MSFT.NET 207.46.138.20 Name Server[with whois ip]: DNS1.TK.MSFT.NET 207.46.245.230 Name Server[with whois ip]: DNS3.UK.MSFT.NET 213.199.144.151 Name Server[with whois ip]: DNS3.JP.MSFT.NET 207.46.72.123 Name Server[with whois ip]: DNS1.DC.MSFT.NET 207.68.128.151 Name Server[with whois ip]: DNS1.SJ.MSFT.NET 65.54.248.222 Updated Date: 07-jun-2002 .... [william@sokol william]$ nslookup Default Server: dns1.elan.net Address: 216.151.192.1 > server 207.46.138.20 Default Server: [207.46.138.20] Address: 207.46.138.20 > www.microsoft.com Server: [207.46.138.20] Address: 207.46.138.20 *** [207.46.138.20] can't find www.microsoft.com: Server failed > server 207.46.245.230 Default Server: dns1.tk.msft.net Address: 207.46.245.230 > www.microsoft.com Server: dns1.tk.msft.net Address: 207.46.245.230 *** dns1.tk.msft.net can't find www.microsoft.com: Server failed > server 213.199.144.151 Default Server: dns3.uk.msft.net Address: 213.199.144.151 > www.microsoft.com Server: dns3.uk.msft.net Address: 213.199.144.151 *** dns3.uk.msft.net can't find www.microsoft.com: Server failed > exit [william@sokol william] date [Fri Dec 6 01:18:00 PST 2002 [william@sokol william]$ nslookup Default Server: dns1.elan.net Address: 216.151.192.1 > server 207.46.72.123 Default Server: dns3jp.msft.net Address: 207.46.72.123 > www.microsoft.com Server: dns3jp.msft.net Address: 207.46.72.123 *** dns3jp.msft.net can't find www.microsoft.com: Server failed > server 207.68.128.151 Default Server: dns1.dc.msft.net Address: 207.68.128.151 > www.microsoft.com Server: dns1.dc.msft.net Address: 207.68.128.151 *** dns1.dc.msft.net can't find www.microsoft.com: Server failed > server 65.54.248.222 > server 65.54.248.222 Authoritative answers can be found from: 248.54.65.in-addr.arpa nameserver = ns1.hotmail.com 248.54.65.in-addr.arpa nameserver = ns2.hotmail.com 248.54.65.in-addr.arpa nameserver = ns3.hotmail.com 248.54.65.in-addr.arpa nameserver = ns4.hotmail.com 248.54.65.in-addr.arpa nameserver = tuk1-dns-1.sea.msnglobal.net 248.54.65.in-addr.arpa nameserver = tuk2-dns-1.sea.msnglobal.net Default Server: [65.54.248.222] Address: 65.54.248.222 > www.microsoft.com Server: [65.54.248.222] Address: 65.54.248.222 *** [65.54.248.222] can't find www.microsoft.com: Server failed > exit

1 1

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 06 Dec '02

06 Dec '02

>> My question is as follows - We are losing customers because of this >> problem. It is costing us reputation and money. It is out of our >> control. If you were us, what would you do? We have already asked >> ARIN >> to reassign us to a "friendlier" CIDR, and they refuse. >ARIN don't guarantee routability of the blocks they allocate, and it's >difficult to see how they ever could. If you want to discuss what ARIN could or could not do, then please join the ARIN ppml list. > Perhaps this is an issue of community education, or one of needing > better tools or methods for managing martian filters. Those issues are > arguably both technical and operational. The original poster doesn't have a problem with the community. He has a problem with network operators who are not part of the community and that is a reality of today's Internet that cannot be dealt with by technical tools or operational methods. But there are non-technical and non-operational actions actions that ARIN could take to help. The details of those actions and whether or not ARIN members want to act are matters for the ppml list. --Michael Dillon

5 4

RE: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 06 Dec '02

06 Dec '02

Thanks for all of the suggestions we have received. If I had only known that talking about ARIN on NANOG was the hot button, I would have pressed it a long time ago :-) I do have some operational factoids to add - my prior post was incomplete. We are multi-homed in a carrier neutral data center. It is imperative that we have our own IP. I do have some small bits of CIDR from other ISPs and have already migrated some of the problem customers to other blocks, but I am not meeting my SLAs with those customers, because we guarantee multiple paths. On IP that belongs to an upstream of ours, traffic only comes inbound through that upstream. That is a problem. Sorry if talking about ARIN is off the topic of this list, but the 69/8 CIDR is "broken" (in customer terms) in lots of places on the internet. ARIN is the one assigning it. If they keep assigning it before everyone's access policies recognize it as valid, this "non-operational" issue is going to cost a lot of people a lot of money in wasted time, effort and resources. I know it has been very painful for us. -----Original Message----- From: Todd A. Blank Sent: Friday, December 06, 2002 10:23 AM To: nanog(a)merit.edu Subject: Re: Operational Issues with 69.0.0.0/8... The list of inaccessible sites continues to grow: Add to the list www.oandp.com - that looks like someone's firewall filtering in front of their DNS server, because we can't even resolve the DNS. We still can't get to www.ocas.com, www.lavalife.com, and www.indofilms.com even after calling and posting repeatedly. There are undoubtedly others out there. Repeated problems posted by myself and others show the extent of the problem with the 69.0.0.0/8 CIDR, and its lack of dependability - it's a human thing. It used to be restricted, so there are a lot of access lists out there - with all the stuff going on in the last year or so, half the people blocking it probably don't even know how to unblock it - i.e. that person no longer works here... If you look at the address space on IANA, http://www.iana.org/assignments/ipv4-address-space you will see that the last CIDR ARIN took before 69/8 was over a year prior to the 69/8 assignment. A lot happened in our industry in that year. Somewhere, this process is broken since the last CIDR was assigned to ARIN. My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. Suggestions are welcome. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853

1 0

Re: Operational Issues with 69.0.0.0/8...
by Todd A. Blank 06 Dec '02

06 Dec '02

The list of inaccessible sites continues to grow: Add to the list www.oandp.com - that looks like someone's firewall filtering in front of their DNS server, because we can't even resolve the DNS. We still can't get to www.ocas.com, www.lavalife.com, and www.indofilms.com even after calling and posting repeatedly. There are undoubtedly others out there. Repeated problems posted by myself and others show the extent of the problem with the 69.0.0.0/8 CIDR, and its lack of dependability - it's a human thing. It used to be restricted, so there are a lot of access lists out there - with all the stuff going on in the last year or so, half the people blocking it probably don't even know how to unblock it - i.e. that person no longer works here... If you look at the address space on IANA, http://www.iana.org/assignments/ipv4-address-space you will see that the last CIDR ARIN took before 69/8 was over a year prior to the 69/8 assignment. A lot happened in our industry in that year. Somewhere, this process is broken since the last CIDR was assigned to ARIN. My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. Suggestions are welcome. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853

1 0

The Cidr Report
by cidr-report＠potaroo.net 06 Dec '02

06 Dec '02

This report has been generated at Fri Dec 6 21:44:40 2002 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 29-11-02 117628 84925 30-11-02 117500 84864 01-12-02 117450 84897 02-12-02 117617 84818 03-12-02 117623 84175 04-12-02 116419 84197 05-12-02 116693 84459 06-12-02 116870 84561 AS Summary 14128 Number of ASes in routing system 5562 Number of ASes announcing only one prefix 1716 Largest number of prefixes announced by an AS AS3908 : SUPERNETASBLK SuperNet, Inc. 72949248 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Possible Bogus AS AS63000 Announced by: AS14522 EC-SASA-LACNIC SatNet S.A. Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Dec02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 116820 84482 32338 27.7% All ASes AS3908 1716 975 741 43.2% SUPERNETASBLK SuperNet, Inc. AS701 1712 1227 485 28.3% ALTERNET-AS UUNET Technologies, Inc. AS18566 395 5 390 98.7% COVAD Covad Communications AS7018 1389 1034 355 25.6% ATT-INTERNET4 AT&T WorldNet Services AS4323 522 185 337 64.6% TW-COMM Time Warner Communications, Inc. AS7843 644 307 337 52.3% ADELPHIA-AS Adelphia Corp. AS6197 458 124 334 72.9% BATI-ATL BellSouth Network Solutions, Inc AS1221 1162 843 319 27.5% ASN-TELSTRA Telstra Pty Ltd AS4355 404 136 268 66.3% ERMS-EARTHLNK EARTHLINK, INC AS6347 351 83 268 76.4% DIAMOND SAVVIS Communications Corporation AS22927 289 22 267 92.4% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS1239 924 663 261 28.2% SPRINTLINK Sprint AS7046 584 323 261 44.7% UUNET-CUSTOMER UUNET Technologies, Inc. AS705 434 195 239 55.1% ASN-ALTERNET UUNET Technologies, Inc. AS4814 248 15 233 94.0% CHINANET-BEIJING-AP China Telecom (Group) AS1 663 439 224 33.8% GNTY-1 Genuity AS6198 417 198 219 52.5% BATI-MIA BellSouth Network Solutions, Inc AS4151 351 135 216 61.5% USDA-1 USDA AS17676 232 28 204 87.9% GIGAINFRA XTAGE CORPORATION AS852 653 464 189 28.9% ASN852 Telus Advanced Communications AS690 508 321 187 36.8% MERIT-AS-27 Merit Network Inc. AS4134 299 115 184 61.5% ERX-CHINALINK Data Communications Bureau AS6595 243 59 184 75.7% DODDSEUR DoD Education Activity Network Assistance Center AS209 520 338 182 35.0% ASN-QWEST Qwest AS2048 262 88 174 66.4% LANET-1 State of Louisiana AS6140 279 127 152 54.5% IMPSAT-USA ImpSat AS6327 183 34 149 81.4% SHAWFIBER Shaw Fiberlink Limited AS2386 374 229 145 38.8% INS-AS AT&T Data Communications Services AS17557 314 172 142 45.2% PKTELECOM-AS-AP Pakistan Telecom AS3215 309 169 140 45.3% AS3215 France Telecom Transpac Total 16839 9053 7786 46.2% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: Bin Laden Associate Warns of Cyberattack
by Michael.Dillon＠radianz.com 06 Dec '02

06 Dec '02

>It is a great example of how well Al-Quedah manipulates the media. >There are more ways to wreak havoc than script kiddies and DOS attacks. When was the last time you took a sample and tested for the presence of fertilizer *BEFORE* you let the truck driver put that diesel into your generator tanks? And did anyone else notice how the NY Times article gave some clear instructions on how to identify the building in Tribeca even though they didn't include the street address? The best defence against all of these potential terrorist attacks is to do what the military does, i.e. spread out. Never put more than a fraction of your eggs in one basket. Use the network to connect diverse and widespread assets so that they can function as a unit even though they are physically separated. This philosophy works whether your assets are combat soldiers or network PoPs. And again, there is a role for government here. How about tax reductions for companies who harden their networks by removing single points of failure that are vulnerable to terrorist attack? --Michael Dillon

13 18

OT The origin of the Internet
by Kevin Oberman 05 Dec '02

05 Dec '02

O.K. This is less off-topic than half the posts this week. For the REAL origin of the Internet, see http://www.uclick.com/client/byr/nq/ (Make sure that you see the entry for 12/5/02.)

2 1