- Test - lists.nanog.org

First Post! Annoying Debate at Work.
by Christopher Aldridge 29 Feb '04

29 Feb '04

NOTE: I have been a nanog observer for nearly a year. The following may be slightly off topic, but it seems as though nanog is my last hope. Recently at work, I've been battling fellow coworkers on a very simple debate. The fact that I will not "give in" on my argument really makes me look arrogant, but I absolutely refuse to let this one go without logical reason! The argument non-persuasively put is as follows: Is a USB Ethernet Adapter a "converter"? Personally, I say "no". My coworkers seem to say "yes". My argument: 1) Ethernet isnt "converted" to USB. The adapted information from the ethernet segment may traverse the USB segment if the NIC adapts it to the CPU, but is never "converted" to USB. You can use USB for many things, thus making it an underlying "serial bus" in which other technologies can traverse. Whatis.com definition: USB (Universal Serial Bus) is a plug-and-play interface between a computer and add-on devices (such as audio players, joysticks, keyboards, telephones, scanners, and printers). With USB, a new device can be added to your computer without having to add an adapter card or even having to turn the computer off. USB in this scenario would be synonymous with PCI, in regards to the type of technology that interfaces with the cpu. 2) I cant seem to place "converter" above layer 1. Yet a Network adapter ( both PCI or USB ) have layer 2 mac addresses that are stored into the PROM from the manufactor. From my understanding, if an ethernet frame comes in via cat5, and is destined for the wrong MAC address, the traffic will not move up the OSI model and to the PC; It will be dropped right there and then. Only frames destined for the correct MAC or broadcast will traverse the USB portion. If this is true, then aparantly our "converter" is doing a lot more than "converting" ethernet to "USB"! - Filtering, forwarding, encapsulating, de-encapsulating, etc. 3) Just because a device has two physical mediums of connectivity, dosent make it a "converter". My coworkers argue that a USB Ethernet adapter is an "Ethernet to USB Converter". If this is true, then the following could be said: a. A PCI Ethernet Adapter is a "converter" because it "converts" Ethernet to PCI. b. An Alcatel switch w/ a T1 and a DS3 controller card would be a "converter" because it "converts" cat5 from the T1 card to coax on the DS3 card. c. Lastly ( I love this one ), An integrated Ethernet adapter on a motherboard is a "converter" because it "converts" ethernet to uhh ?? processor? Riiiiight" My co-workers arguments are basically that because Ethernet is plugged into one side, and usb is plugged into the other, it's a converter. I strongly that's an understament if not an incorrect statement. Whats your take and why? Input from ANY of you would be GREATLY appreciated. Otherwise, a simple "I aggree with you" will be fine also! Thanks in advance! Christopher Aldridge Network Analyst CCNA/MCP/MCSA

6 7

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 29 Feb '04

29 Feb '04

>[1] Should VoIP include 911/999 service, and how does one resolve the >various geographic location issues associated with this. Anyone who claims to answer this one should consider the how to handle the case of a British subscriber to a VoIP service who travels to the USA, Canada, all over Europe and Australia. What would happen if a native of one of those countries picked up the VoIP device and dialled for emergency services. In Canada and the USA they would dial 911 In the UK they would dial 999 In Europe they would dial 112 or possibly one of the various legacy national numbers for emergency service. And in Australia they would dial 000. Do you route all these calls to Britain? Do you use some sort of geographical locator database for IP addresses to route the call? Do you route the call based on the actual number dialed, i.e. all 000 calls go to Australia? Or do we pass legislation requiring the RIRs and all ISPs to maintain a database with the current physical location of every device with an IP address? Personally I don't think the regulators have a clear enough grasp of the technical issues to be prescribing solutions for this issue. --Michael Dillon P.S. I think a solution lies in the general direction of converting the entire world to use 112 for emergency services and having the VoIP services set up an automated system that rings back whenever your phone connects using a different IP address and asks you where you are.

12 19

Re: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefinder)
by neil＠DOMINO.ORG 28 Feb '04

28 Feb '04

> http://biz.yahoo.com/rc/040226/tech_verisign_2.html can't say I'm surprised. Another nail in the Verisign coffin.

9 9

RE: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Pendergrass, Greg 28 Feb '04

28 Feb '04

I think how reliable the internet needs to be depends on what you want to use it for: if you want to call an ambulance you DON'T use the internet, if you want to transfer money from one account to another you DO use the internet. In other words right now it's good for things that are important but not critical from an immediate action standpoint. If it can wait until tomorrow use the internet otherwise pick up the phone and dial. I can count on one hand the number of times I've had problems with my landline in my entire life but I can count on two hands the number of problems I've had with my internet connection in one year. If we ever want the internet to grow from being a handy medium for exchanging data to the converged, all-encompassing communications medium then it needs to go from "Mom, the internet's down again!" to "Dude, my internet connection went down yesterday, that ever happen to you before?". For that to happen there has to be more accountability in the industry. -GP -----Original Message----- From: Steve Gibbard [mailto:scg@gibbard.org] Sent: 26 February 2004 00:30 To: nanog(a)merit.edu Subject: How relable does the Internet need to be? (Was: Re: Converged Network Threat) Having woken up this morning and realized it was raining in my bedroom (last night was the biggest storm the Bay Area has had since my house got its new roof last summer), and then having moved from cleaning up that mess to vacuuming water out of the basement after the city's storm sewer overflowed (which seems to happen to everybody in my neighborhood a couple of times a year), I've spent lots of time today thinking about general expectations of reliability. In the telecommunications industry, where we tend to treat reliability as very important and any outage as a disaster, hopefully the questions I've been coming up with aren't career ending. ;) With that in mind, how much in the way of reliability problems is it reasonable to expect our users to accept? If the Internet is a utility, or more generally infrastructure our society depends on, it seems there are a bunch of different systems to compare it to. In general, if I pick up my landline phone, I expect to get a dialtone, and I expect to be able to make a call. If somebody calls my landline, I expect the phone to ring, and if I'm near the phone I expect to be able to answer. Yet, if I want somebody to actually get through to me reliably, I'll probably give them my cell phone number instead. If it rings, I'm far more likely to able to answer it easily than I am my landline, since the landline phone is in a fixed location. Yet some significant portion of calls to or from my cell phone come in when I'm in areas with bad reception, and the conversation becomes barely understandable. In many cases, the signal is too weak to make a call at all, and those who call me get sent straight to voicemail. Most of us put up with this, because we judge mobility to be more important than reliability. I don't think I've ever had a natural gas outage that I've noticed, but most of my gas appliances won't work without electric power. I seem to lose electric power at home for a few hours once a year or so, and after the interuption life tends to resume as it was before. When power outages were significantly more frequent, and due to rationing rather than to accidents, it caused major political problems for the California government. There must be some threshold for what people are willing to accept in terms of residential power outages, that's somewhere above 2-3 hours per year. In Ann Arbor, Michigan, where I grew up, the whole town tended to pretty much grind to a halt two or three days a year, when more snow fell than the city had the resources to deal with. That quantity of snow necessary to cause that was probably four or five inches. My understanding is that Minneapolis and Washington DC both grind to a halt due to snow with somewhat similar frequency, but the amount of snow requred is significantly more in Minneapolis and significantly less in DC. Again, there must be some threshold of interruptions due to exceptionally bad weather that are tolerated, which nobody wants to do worse than and nobody wants to spend the money to do better than. So, it appears that among general infrastructure we depend on, there are probably the following reliability thresholds: Employees not being able to get to work due to snow: two to three days per year. Berkeley storm sewers: overflow two to three days per year. Residential Electricity: out two to three hours per year. Cell phone service: Somewhat better than nine fives of reliability ;) Landline phone service: I haven't noticed an outage on my home lines in a few years. Natural gas: I've never noticed an outage. How Internet service fits into that of course depends on how you're accessing the Net. The T-Mobile GPRS card I got recently seems significantly less reliable than my cell phone. My SBC DSL line is almost to the reliability level of my landline phone or natural gas service, except that the DSL router in my basement doesn't work when electric power is out. I'm probably poorly qualified to talk about the end-user experience on the networks I actually work on, even if I had permission to. Like pretty much everybody else here, I'm always interested in doing better on reliability. And, like many of my neighbors, I'd like to be able to store stuff on my basement floor. In comparison to a lot of other infrastructure we depend on, it seems to me the Internet is already doing pretty well. -Steve On Wed, 25 Feb 2004, Jared Mauch wrote: > > Ok. > > I can't sit by here while people speculate about the possible > problems of a network outage. > > I think that most everyone here reading NANOG realizes that > the Internet is becoming more and more central to daily life even > for those that are not connected to the internet. > > From where i'm sitting, I see a number of potentially dangerous > trends that could result in some quite catastrophic failures of networks. > No, i'm not predicting that the internet will end in 8^H7 days or anything > like that. I think the Level3 outage as seen from the outside is a clear > case that single providers will continue to have their own network failures > for time to come. (I just hope daily it's not my employers network ;-) ) > > So, We're sitting here at the crossroads, where VoIP is > "coming of age". Vonage, 8x8 and others are blazing a path that > the rest of the providers are now beginning to gun for. We've already > read in press releases and articles in the past year how providers > in Canada and the US are moving to VoIP transport within their long-distance > networks. > > I keep hear of Frame-Relay and ATM signaling that is going > to happen in large providers MPLS cores. That's right, your "safe" TDM > based services, will be transported over someones IP backbone first. > This means if they don't protect their IP network, the TDM services could > fail. These types of CES services are not just limited to Frame and ATM. > (Did anyone with frame/atm/vpn services from Level3 experience the > same outage?) > > Now the question of Emergency Services is being posed here but also > in parallel by a number of other people at the FCC. We've seen the E911 > recommendation come out regarding VoIP calls. How long until a simple > power failure results in the inability to place calls? > > Now, i'm not trying to pick on Level3 at all. The trend I > outline here is very real. The reliance on the Internet for critical > communications is a trend that continues. Look at how it was used > on 9/11 for communications when cell and land based telephony networks > were crippled. > > The internet has become a very critical part of all of our lives > (some more than others) with banks using VPNs to link their ATMs back into > their corporate network as well as the number of people that use it for > just plain "just in time" bill payment and other things. I can literally > cancel my home phone line, cell phone and communicate soley with my > internet connection, performing all my bill payments without any paperwork. > I can even file my taxes online. > > We're at (or already past) the dangerous point of network > convergence. While I suspect that nobody directly died as a result of > the recent outage, the trend to link together hospitals, doctors > and other agencies via the Internet and a series of VPN clients continues > to grow. (I say this knowing how important the internet is to > the medical community, reading x-rays and other data scans at home for the > oncall is quite common). > > While my friends that are local VFD do still have the traditional > pager service with towers, etc... how long until the T1's that are > used for dial-in or speaking to the towers are moved to some sort of > IP based system? The global economy seems to be going this direction with > varying degrees of caution. > > I'm concerned, but not worried.. the network will survive.. > > - Jared > > > On Wed, Feb 25, 2004 at 09:17:30AM -0600, Pete Templin wrote: > > If an IP-based system lets you see the status of the 23 hospitals in San > > Antonio graphically, perhaps overlaid with near-real-time traffic > > conditions, I'd rather use it as primary and telephone as secondary. > > > > Counting on it? No. Gaining usability from it? You betcha. > > > > Brian Knoblauch wrote: > > > > > If you're counting on IP (a "best attempt" protocol) for critical > > >data, you've got a serious design flaw in your system... > > > > > >-----Original Message----- > > >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > > >Pete > > >Templin > > >Sent: Wednesday, February 25, 2004 9:10 > > >To: Colin Neeson > > >Cc: nanog(a)merit.edu > > >Subject: Re: Level 3 statement concerning 2/23 events (nothing to see, move > > >along) > > > > > > > > > > > > > > >Are you sure no one died as a result? My hobby is volunteering as a > > >firefighter and EMT. If Level3's network sits between a dispatch center > > >or mobile data terminal and a key resource, it could be a factor > > >(hospital status website, hazardous materials action guide, VoIP link > > >that didn't reroute because the control plane was happy but the > > >forwarding plane was sad, etc.). > > > > > >And if the problem could happen to another network tomorrow but could be > > >prevented or patched, wouldn't inquiring minds want to know? Your life > > >might be more interesting when the fit hits the shan if you have the > > >same vulnerability. > > > > > >Colin Neeson wrote: > > > > > > > > >>Because, in the the grand scale scheme of things, it's really not that > > >>important. > > >> > > >>No one died because of it, the normal, everyday events of the world > > >>went > > >>on, > > >>unaffected by a Level 3 outage... > > >> > > >>Might be nice to know what happened, but my life will certainly not be > > >>less interesting by not having that knowledge... > > -- > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > ---------------------------------------------------------------------------- ---- Steve Gibbard scg(a)gibbard.org +1 415 717-7842 (cell) http://www.gibbard.org/~scg +1 510 528-1035 (home) Vodafone Global Content Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No. 4064873 This e-mail is for the addressee(s) only. If you are not an addressee, you must not distribute, disclose, copy, use or rely on this e-mail or its contents, and you must immediately notify the sender and delete this e-mail and all copies from your system. Any unauthorised use may be unlawful. The information contained in this e-mail is confidential and may also be legally privileged.

7 8

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 28 Feb '04

28 Feb '04

>> I think the Internet is doing pretty well save some IOS code problems >> from time to time, and the typical root server hicups. >I'm interested to know what you mean by "typical root server hicups". >I'm trying to think of an incident which left the Internet generally >unable to receive answers to queries on the root zone, but I can't >think of one. There have been several incidents in which some root servers have hiccuped, sometimes being down for several days. But since the service they provide has N+12 resiliency, the service itself has never been unavailable. Similarly, the Internet has always had N+1 or better vendor resiliency so IOS can have problems while the non-IOS vendor (or vendors) keep on running. In fact, I would argue that N+1 vendor resiliency is a good thing for you to implement in your network and N+2 vendor resiliency is a good thing for the Internet as a whole. Let's hope that vendor P manages to get some critical mass in the market along with J and C. --Michael Dillon

3 2

Sail Ho! (was Re: Lawsuit on ICANN ...)
by Eric Brunner-Williams in Portland Maine 27 Feb '04

27 Feb '04

http://fightwls.com/

1 0

RE: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Wesley Vaux 27 Feb '04

27 Feb '04

Mobile IP phones will be the same as everything else. For different roaming areas you'll get a different IP address and the services will be handled that way. I think someone will come out with it as soon as they figure out how to put together a worldwide network that will support it. I don't think the internet is fast enough nor robust enough to handle a phone network on top of it. This is just my oppinion. -----Original Message----- From: Jeff Shultz [mailto:jeffshultz@wvi.com] Sent: Friday, February 27, 2004 2:50 PM To: nanog(a)merit.edu Subject: Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat) ** Reply to message from Petri Helenius <pete(a)he.iki.fi> on Fri, 27 Feb 2004 21:19:48 +0200 > Valdis.Kletnieks(a)vt.edu wrote: > > >20 years ago, 911 was able to say "unless you're the rare beast with > >a cell phone, basing it on the physical service address that the > >copper runs to would probably work alright in 99% of the cases". > > > >Let's not make the same mistake again. > > > > > > > So all IP phones should be outside of buildings and equipped with GPS > or Galileo receivers? > > Pete Does anyone actually offer a mobile IP phone service yet? Does anyone plan to? With Vonage you have to tell them where you are located so they can set your 911 service up to the proper 911 center. With cell phones it's based on the cell it comes into. If some sort of truly mobile IP based phone comes in, I'd guess that the provider is going to have to set it up to where the local router (or associated VOIP device) "listens" to the VOIP traffic for a 911 call, intercepts it and sends it to the local 911 center - my presumption is that they'll have to have a router of some sort in the local area to handle the mobile IP traffic. The GPS idea isn't a bad one either - since I think most new cell phones are coming out with this (it's been mandated, right?) it's a cheap addition and can be used by whatever the router redirects the call to for a better determination of the call center if the phone has the info. The easier solution would probably be for the "mobile IP phone service" to set it up as a dynamic address thing, where the phone number is assigned to the MAC address and the system updates a central index of what IP address is currently serving what phone number. And by whatever "DHCP" server assigned the address, that would be used to determine the 911 center most appropriate. As for the varied emergency numbers used throughout the world and such... if you are visiting a foreign country, take the time to figure out what the local (national) emergency numbers are. Much easier than an overly complex technological solution. Or add an "emergency" button on the phone that will send a signal that the switch will read as whatever the national emergency number is. Experience here: last summer I was at Ft. Campbell, KY, and a friend and I drove on the local interstate down to Nashville - when you get on the Interstate there you are in Tennesse, then you are in Kentucky for a short period (a few miles) and then back to Tennesse. I had to call 911on my cell for an accident and was connectted to a 911 center in Tennesee... but since I was on the Kentucky stretch of freeway they had to transfer me over to the local Kentucky 911 center. No problem. I suspect that as long as the VOIP 911 thing can get you "close" to the correct 911 center, they'll be able to handle the rest of the switching needed. And realistically - that's probably a better solution than trying to come up with an overly complex technological solution. These are supposed to be phones after all, not "dumb" ELT devices. Let the OT rants begin.... -- Jeff Shultz Loose nut behind the wheel.

1 0

Best Common Practice - Listening to local routes from peers?
by Michael Smith 27 Feb '04

27 Feb '04

Hello: We have a customer of a customer who is attempting to send traffic from IP space we control, through the Internet and back into us via one of our transit connections. I have filters in place that block all inbound traffic from the blocks I announce coming in over my transit and peering connections. This is breaking the downstream customer ability to route from them, through UUNet, and back to me. I'm curious what the Best Common Practice is for this type of scenario. I have always used this type of filtering as a way to bury source-spoofed traffic in a DDOS situation but I'm not sure if it's appropriate, generally speaking. If other operators would like to reply directly to me I would be more than happy to summarize to the list. Thank you for any assistance you can provide. Michael Smith mksmith(a)noanet.net

5 6

RE: IPv6 reverse lookup - lame delegation?
by Jeroen Massar 27 Feb '04

27 Feb '04

-----BEGIN PGP SIGNED MESSAGE----- Nico Schottelius [mailto:nico-nanog@schottelius.org] wrote: > Hello! > > I am more or less new to nanog (reading it about half a year), > so please correct me, if I do something wrong. > > Jeroen Massar [Tue, Feb 10, 2004 at 02:07:27PM +0100]: > > Jun-ichiro itojun Hagino wrote: > > > if i try to log into my machines back in tokyo by IPv6 > SSH, it takes > > > very long time. i guess i found the reason - > (possible) lame delegation > > > of blah.ip6.int. ip6.arpa. query returns instantly. > > > how could we fix it? > > > > By fixing the software as ip6.int was deprecated 2 years+++ > > ago as you should already know. > > I've read the RFC and also talked to some people using IPv6 adresses, > especially some using 6to4 (2002:/16). > > As far as I know the reverse mapping for 2002 is only > available through ip6.int, or am I wrong? Not wrong but correct. Delegations for that block can be requested by emailing hostmaster(a)ep.net But Geoff Huston has already published this draft: http://www.ietf.org/internet-drafts/draft-huston-6to4-reverse-dns-01.txt Which should solve the 6to4 problem. Personally I would say that 6to4 shouldn't be given reverse though, if people require that they are better off getting either native or tunneled IPv6 instead of this transition method especially because of the low deployment of 6to4 relays. > I think this is because 2002: is a test zone. But for me using > it almost always the only way to have reverse mapping is ip6.int. Get yourself a tunneled or native prefix from a LIR closeby. 6to4 is not testing, it is transition and it works(tm). Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQD8r8CmqKFIzPnwjEQKKHgCgqUR7Pj9cTamJlNBTEknTyF7k4BcAoKQP mum12QVg91rWgM2R2sqNDjU8 =6MzS -----END PGP SIGNATURE-----

1 0

The Cidr Report
by cidr-report＠potaroo.net 27 Feb '04

27 Feb '04

This report has been generated at Fri Feb 27 21:48:07 2004 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 20-02-04 131753 91870 21-02-04 131854 91847 22-02-04 131784 91848 23-02-04 131722 91867 24-02-04 131767 91928 25-02-04 131802 91999 26-02-04 131901 92037 27-02-04 132022 92097 AS Summary 16629 Number of ASes in routing system 6685 Number of ASes announcing only one prefix 1383 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 73468672 Largest address span announced by an AS (/32s) AS568 : DISOUN DISO-UNRRA 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'). --- 27Feb04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 131958 92173 39785 30.1% All ASes AS4323 689 203 486 70.5% TWC-34 Time Warner Communications, Inc. AS6197 734 300 434 59.1% BNS-14 BellSouth Network Solutions, Inc AS7018 1383 965 418 30.2% ATTW AT&T WorldNet Services AS701 1323 949 374 28.3% UU UUNET Technologies, Inc. AS27364 382 33 349 91.4% ARMC Armstrong Cable Services AS6198 545 215 330 60.6% BNS-14 BellSouth Network Solutions, Inc AS4134 652 329 323 49.5% CHINANET-BACKBONE No.31,Jin-rong Street AS22909 344 29 315 91.6% CMCS Comcast Cable Communications, Inc. AS22773 347 37 310 89.3% CXAB Cox Communications Inc. Atlanta AS9583 350 43 307 87.7% SATYAMNET-AS Satyam Infoway Ltd., AS1239 947 663 284 30.0% SPRN Sprint AS4355 385 101 284 73.8% ERSD EARTHLINK, INC AS6347 365 87 278 76.2% SAVV SAVVIS Communications Corporation AS1221 901 647 254 28.2% ASN-TELSTRA Telstra Pty Ltd AS17676 294 41 253 86.1% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS6478 270 40 230 85.2% ATTW AT&T WorldNet Services AS6140 360 131 229 63.6% IMPSA ImpSat AS25844 243 16 227 93.4% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS209 714 500 214 30.0% QWEST-4 Qwest AS14654 216 4 212 98.1% WAYPOR-3 Wayport AS11305 242 41 201 83.1% INTERL-80 Interland Incorporated AS7843 411 212 199 48.4% ADELPH-13 Adelphia Corp. AS2386 431 239 192 44.5% ADCS-1 AT&T Data Communications Services AS5668 346 159 187 54.0% CIH-12 CenturyTel Internet Holdings, Inc. AS20115 610 425 185 30.3% CHARTE-72 Charter Communications AS4766 422 238 184 43.6% KIX Korea Internet Exchange for "96 World Internet Exposition AS4519 203 20 183 90.1% MAASCO Maas Communications AS9929 209 30 179 85.6% CNCNET-CN China Netcom Corp. AS6327 207 29 178 86.0% SHAWC-2 Shaw Communications Inc. AS15270 213 40 173 81.2% PDP-14 PaeTec.net -a division of PaeTecCommunications, Inc. Total 14738 6766 7972 54.1% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc. 64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS 64.46.12.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.46.34.0/24 AS3408 64.46.60.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.63.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.62.126.0/23 AS25700 SWIFTD SWIFTDESK VENTURE 66.114.0.0/19 AS16526 BIRCHT Birch Telecom, Inc. 66.114.28.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.29.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.30.0/24 AS15083 INMM Infolink Communication Services, Inc. 66.114.31.0/24 AS15083 INMM Infolink Communication Services, Inc. 69.8.128.0/17 AS7260 NORL Norlight Telecommunications 132.0.0.0/10 AS568 DISOUN DISO-UNRRA 137.0.0.0/13 AS568 DISOUN DISO-UNRRA 138.136.0.0/13 AS568 DISOUN DISO-UNRRA 158.0.0.0/13 AS568 DISOUN DISO-UNRRA 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 LANLINK Elisa Oyj 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.81.182.0/24 AS719 LANLINK Elisa Oyj 192.81.183.0/24 AS719 LANLINK Elisa Oyj 192.81.184.0/24 AS719 LANLINK Elisa Oyj 192.83.16.0/20 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.32.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.64.0/19 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.96.0/22 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.83.100.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 DISOUN DISO-UNRRA 192.172.0.0/19 AS568 DISOUN DISO-UNRRA 192.188.208.0/20 AS568 DISOUN DISO-UNRRA 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS568 DISOUN DISO-UNRRA 198.97.80.0/20 AS568 DISOUN DISO-UNRRA 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.192.0/20 AS568 DISOUN DISO-UNRRA 198.97.240.0/20 AS568 DISOUN DISO-UNRRA 198.101.4.0/22 AS568 DISOUN DISO-UNRRA 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.161.165.0/24 AS852 AGTA Telus Advanced Communications 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS568 DISOUN DISO-UNRRA 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.84.0.0/16 AS701 UU UUNET Technologies, Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS568 DISOUN DISO-UNRRA 199.114.128.0/18 AS568 DISOUN DISO-UNRRA 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.136.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 DISOUN DISO-UNRRA 199.123.0.0/18 AS568 DISOUN DISO-UNRRA 199.123.16.0/20 AS568 DISOUN DISO-UNRRA 199.123.80.0/21 AS568 DISOUN DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.2.64.0/20 AS9729 IS-AP iAdvantage Limited 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.24.0/24 AS17888 SINGTEL-HK SingTel Hong Kong Limited 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HAWAI-1 Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 LOXLEY-TH Loxley Information Co., Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.143.56.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/20 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.248.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 202.170.128.0/22 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.133.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.134.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 203.32.4.0/23 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.86.2.0/23 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 203.87.224.0/19 AS4799 CHINA169-JT CNCGROUP old Jitong IP network 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 204.69.144.0/22 AS5668 CIH-12 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 206.41.32.0/19 AS14824 NCC-105 NewSouth Communications Corp. 206.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 206.108.34.0/24 AS852 AGTA Telus Advanced Communications 206.108.35.0/24 AS852 AGTA Telus Advanced Communications 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL-33 Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 209.169.219.0/24 AS189 GNTY Genuity 209.169.223.0/24 AS189 GNTY Genuity 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.205.95.0/24 AS6347 SAVV SAVVIS Communications Corporation 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.51.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.55.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.56.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL-33 Telesat International Ltd. 209.240.96.0/19 AS10815 KCNETI-1 KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 209.251.64.0/19 AS10266 MDCN MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.36.46.0/24 AS7176 GTEIEUROPE-AS Genuity European AS 216.36.47.0/24 AS7176 GTEIEUROPE-AS Genuity European AS 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services 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)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0