- Test - lists.nanog.org

Re: Enable BIND cache server to resolve chinese domain name?
by Brad Knowles 04 Jul '05

04 Jul '05

At 1:25 PM +0100 2005-07-04, Michael.Dillon(a)btradianz.com wrote: > They are battling it out in the marketplace and one > of the IDN solutions will evolve to the point where > the market considers it clearly superior. I think that would be the worst possible outcome. > Personally, I think that the Internet is too young > and we have too little experience with multilingual > naming to engineer an Internationalised Domain Naming > solution that solves the problem once and for all. > This means that we should be ready for more than one > iteration to get to the solution. I have no problem with multiple iterations to get this right. I have real problems with those multiple iterations being done via the marketplace. These sorts of things need to be engineered using the correct methods (at least, as known at the time), and they need to go through the correct process. That means the IETF. We don't let Joe Moron invent his own better-cheaper-faster replacement for SS7 and then casually bet-the-businesses/livelihoods of thousands or millions of innocent people that they got their engineering right. We shouldn't be allowing anyone to do the same for DNS. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

1 0

drone armies C&C report - June/2005
by Gadi Evron 04 Jul '05

04 Jul '05

Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish our regular reports, with some additional statistics. We changed our report this month to reflect past data, and try to ascertain from our own experience response rates to botnet reports. This month we would once again like to commend Staminus and Internap, who continually surprise us with their immediate response to our reports. The numbers speak for themselves. A couple of other notable ISP's we rarely mention (because they were never a problem) are AOL and Comcast. Comcast has been with us since the start and has shown nothing but seriousness. AOL are continuously ahead of the curve, which is something I personally am close to adoring. The most impressive turn-about change in behavior though came from ThePlanet, who investigate and eliminate any botnet C&C they encounter in record time up to the point where they no longer appear in our monthly reports - where they used to have a revered seat at the top. The report summary includes a Percent Resolved Column in order to recognize the mitigation efforts of the AS Responsible Parties. The Opens Unresolved column represents the number of unique C&C which reported as open to the survey's connection attempts and which have neither been investigated nor cleared by the Responsible Party (to the extent of our knowledge). The Mapping count may include multiple names mapping to a single IP within an AS. We count each mapping count as a unique C&C. AS responsible Parties ranked by top Opens Unresolved Responsible Party Mapping Opens Percent Count Unresolved Resolved SERVER4YOU - Server4You Inc. 49 37 24 UNITEDCOLO-AS Autonomous Syste 44 36 18 SAGONET-TPA - Sago Networks 80 32 60 MFNX MFN - Metromedia Fiber Ne 61 28 54 NOC - Network Operations Cente 39 27 31 AS13680 Hostway Corporation Ta 22 22 0 FDCSERVERS - FDCservers.net LL 42 19 55 NEBRIX-CA - Nebrix Communicati 33 16 52 ASN-NA-MSG-01 - Managed Soluti 31 14 55 LAMBDANET-AS European Backbone 15 14 7 INFOLINK-MIA-US - Infolink Inf 28 13 54 LYCOS-EUROPE Lycos Europe GmbH 17 13 24 Historical Report ranked by past suspect C&Cs mapping into the AS: Responsible Party Mapping Opens Percent Count Unresolved Resolved SAGONET-TPA - Sago Networks 80 32 60 MFNX MFN - Metromedia Fiber Ne 61 28 54 STAMINUS-COMM - Staminus Commu 56 0 100 INTERNAP-BLOCK-4 - Internap Ne 54 0 100 INTERNAP-BLK - Internap Networ 52 0 100 SERVER4YOU - Server4You Inc. 49 37 24 UNITEDCOLO-AS Autonomous Syste 44 36 18 FDCSERVERS - FDCservers.net LL 42 19 55 NOC - Network Operations Cente 39 27 31 KIXS-AS-KR Korea Telecom 33 8 76 NEBRIX-CA - Nebrix Communicati 33 16 52 ASN-NA-MSG-01 - Managed Soluti 31 14 55 * We would gladly like to establish a trusted relationship with these and any organizations to help them in the future. * By previous requests here is an explanation of what "ASN" is, by Joe St Sauver: http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf The Trojan horses most used in botnets: 1. Korgobot. 2. SpyBot. 3. Optix Pro. 4. rBot. 5. Other SpyBot variants and strains (AgoBot, PhatBot, actual SDbots, etc.). This report is unchanged. Credit for gathering the data and compiling the statistics from our group efforts should go to the Statistics Project lead: Prof. Randal Vaughn <Randy_Vaughn(a)baylor.edu> -- Gadi Evron, Israeli Government CERT Manager, Tehila, Ministry of Finance. gadi(a)CERT.gov.il Office: +972-2-5317890 Fax: +972-2-5317801 The opinions, views, facts or anything else expressed in this email message are not necessarily those of the Israeli Government.

1 0

mobile user strawman argument
by Mike Leber 04 Jul '05

04 Jul '05

Directed at no specific person because I've seen several people use it in their examples recently... I'm seeing alot of arguments in the form of "I have mobile users and they aren't going to be able to send email if you use injection IP mail filtering approach X" (where X is SPF, MX+, or what have you); which take the same form as the arguments people made against closing open relays. For those that don't remember, prior to around 1995 or so most all mail servers would relay may for anybody by default. People that got tired of being abused made it so only their customers could use their mail servers to relay mail by methods such as: POP AUTH, only relaying mail for their customer IPs, only accepting mail to be relayed from domains that were hosted on that server, etc. At that time some people swore up and down it was unworkable because all of their mobile users wouldn't be able to send mail using their mail servers because the remote users use random dynamic IPs from all over the Internet. After a large amount of gnashing of teeth and whining, and the spread of knowhow of the several different methods to close an open server yet still allow your users to send mail, these objections were overcome and the open relays were closed. Ok... fast forward to the present in which we can now assert that service providers don't use open relays to provide service to their customers. So now I'm supposed to believe that its impossible for service providers to coordinate which mail server a user is supposed to use to send their mail through (with the information about authorized sending IPs for a domain communicated to receipient SMTP servers according to the method of your choice) when they already force their users to use only SMTP servers that they have authorized access to relay through. Ya, ya, ya... you are going to say 1) its impossible to get people to use designated servers for outgoing email. Or you will say 2) even if you do this there will still be *spam*! (egads shock horrror!) Ugh please. 1) Getting customers to use designated servers is already done and standard operating procedure. 2) Most people would agree that closing the open relays as they were was worthwhile and a sound security decision. The fact that spam still exists doesn't make the decision wrong, it just means that you should not be so naive or disingenuous as to expect various limited practical precautions to solve all the world's spam problems. So much deja vu I feel like I'm on a merry-go-round. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +-----------------------------------------------------------------------+

7 13

Re: Enable BIND cache server to resolve chinese domain name?
by Frank Coluccio 04 Jul '05

04 Jul '05

Steve, I think that what it boils down to is how many times do you want to split Metcalfe before it becomes self-defeating. Similar arguments have surfaced recently due to the emergence of proprietary vertical voip applications such s Skype. If one is appeased simplmy by communing with a fixed set of users of a given community mind set, then it works and everyone is happy. Beyond that? One could be left sucking wind. Frank ps - I've been advised on several occasions by Randy Bush alone that whenever I post to NANOG I leave microsoft artifacts such as ( ^ } in my wake. I don't see it myself. If this happens to be the case in this writing, then would someone please email me indicating so? Appreash ..

1 0

Re: Fundamental changes to Internet architecture
by Fergie (Paul Ferguson) 04 Jul '05

04 Jul '05

Yeah, I saw that... With all respect to Dave, and not to sound too skeptical, but we're pretty far along in our current architecture to "fundamentally" change, don't you think (emphasis on fundamentally)? - ferg -- Michael.Dillon(a)btradianz.com wrote: I guess I'm not the only one who thinks that we could benefit from some fundamental changes to Internet architecture. http://www.wired.com/news/infostructure/0,1377,68004,00.html?tw=wn_6techhead Dave Clark is proposing that the NSF should fund a new demonstration network that implements a fundamentally new architecture at many levels. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

12 12

Re: OMB: IPv6 by June 2008
by Christopher L. Morrow 03 Jul '05

03 Jul '05

On Fri, 1 Jul 2005, Mohacsi Janos wrote: > On Fri, 1 Jul 2005, Christopher L. Morrow wrote: > > > > On Fri, 1 Jul 2005, Mohacsi Janos wrote: > >> > >> On Fri, 1 Jul 2005, Christopher L. Morrow wrote: > >> > >>> On Fri, 1 Jul 2005, Mohacsi Janos wrote: > >>>>> > >>>>> This keeps coming up in each discussion about v6, 'what security measures' > >>>>> is never really defined in any real sense. As near as I can tell it's > >>>>> level of 'security' is no better (and probably worse at the outset, for > >>>>> the implementations not the protocol itself) than v4. I could be wrong, > >>>>> but I'm just not seeing any 'inherent security' in v6, and selling it that > >>>>> way is just a bad plan. > >>>>> > >>>> > >>>> Just name a few: > >>>> - Possibility to end-to-end IPSec. > >>> > >>> exists in v4 > >> > >> Not exactly. Try to setup IPSec nodes behind NAT boxes. IPSec is speaking > >> about possibility of e2e security. > > > > this changes how in v6+nat? > > > > There is not need for NAT in IPv6. Use instead NAP (i.e. Network > Architecture Protection). you are ignoring the reality... people WILL want v6 and nat :( it might be ugly and distasteful, but the fact remains that people will want and will require nat. > >>>> - Privacy enhanced addresses - not tracking usage based on addresses > >>> > >>> dhcp can do this for you (v4 has mechanisms for this) > >> > >> DHCP does not provide privacy, just address management. Can you > >> communicate on IPv4 the following way?: - different service - different > >> source IP address? > >> > > > > yes. look at bitchx, or ssh ... corner cases to be sure, but still > > feasible. (or simple example: vhosted webserver) As to dhcp, it can > > provide the address privacy you seek, just use very short leases. (yes, > > it's messy, but it'd work mostly) > > Are you speaking about the following? : > What I am talking to x service my source address is a1. x see me as a1. > In the same time when I am talking to y service my source address is a2. y > see me as a2. I am speaking of that yes. with the 2 applications I named above (bitchx and ssh) you can indeed appear to be 2 different ip address to 2 different services/destinations... > > Can I have more than 1 address with DHCP in the same time? > I believe you could do multiple dhcp addresses for multiple interfaces on one box. atleast with a modernish unix that seems quite feasible. > >> > >> Have you tried to find out in a IPv4 NAT environment where the virus/worm > >> flood is coming? - Most of the situation it is coming from the NAT box - > > > > actually that's kind of my daily job... it seems to work fine for me so > > far. > > Because you have all the tools and knowledge. But most of the > users/admins do not have these. perhaps... but tcpdump/snort/<pc-sniffer-of-choice> will make that problem easy for them as well. > > > > >> not because NAT box was infected, but because nodes behind NAT was > >> infected. Most of the cases admins of the networks behind NAT boxes not > >> knowledgeable enough where to look in this cases. So IPv6 can improve e2e > >> accountability that is part of the security. > >> > > > > because it removes the 'requirement' for NAT? or in some other magical > > way? If you look/listen to the users of NAT, a large proportion of them > > will continue to use NAT in v6 (or have stated they will)... I'm not sure > > your above arguement is as valid as you'd like it to be :( > > Probably they will use NAT for IPv4, because they don't have other option, > but they will use IPv6 with proper stateful firewall. Argument that NAT is > providing security is not valid.... > the arguement is that NAT is required because people want it, regardless of your engineering arguement about how ugly nat and v6 is/will-be :(

7 9

NTIA will control the root name servers?
by Deepak Jain 03 Jul '05

03 Jul '05

http://www.infoworld.com/article/05/07/01/HNinternetdirectories_1.html?sour… Is this operational or dross? Basically it sounds like the U.S. Gov't (NTIA)/U.S. Dept of Commerce will take back control of the root name servers from ICANN at some point. I suppose they might just contract operation of them to ICANN, but its unclear to me. I'm hesitant to post because if this were a huge deal I would have expected someone to beat me to the punch. But then again, its a holiday weekend in the U.S. Deepak

11 13

re: NTIA will control the root name servers?
by Frank Coluccio 01 Jul '05

01 Jul '05

I received the following from a fellow forum member who happens to be living in Germany after I posted the same story, elsewhere: http://www.siliconinvestor.com/readmsg.aspx?msgid=21469219 ORSN (European Open Root Server Network) http://www.orsn.net/ The Open Root Server Network (ORSN) is working on the task of guaranteeing the internet supply in form of an additional DNS server network with a legacy root zone for ISP networks in Europe. The network coordinated by the ICANN, consisting of 13 root servers distributed among almost the entire world, is as far as we are concerned a high-quality and sure solution. However, the locations of the separate Root server systems are (on the basis of the development history of the Internet) very dependent on the U.S.A. Thus, everybody living in Europe depends on the fact that the connections to the Root servers are available and reachable for the name resolution. The failure of one or more systems in the U.S.A already shows problems with the name resolution: DNS inquiries are substantially delayed and the still attainable Root servers have to process these inquiries as well. The operators (ISC) of f.root-servers.net describe on their web page the servers load with the following words: F answers more than 272 million DNS queries per day, making it one of the busiest DNS servers in the world. A complete blackout of this network is virtually impossible but completely different problems appear as well: for example in the case of political conflicts in the Near East or in Europe. The U.S.A (under the current or any future administration) are theoretically and practically able to control "our" access to contents of the Internet and are also able to limit them. A manipulation of the Root zone could cause that the whole name space .DE is not attainable any more for the remaining world - outside from Germany. We are convinced that such a power is not acceptable in any way even if there has not been such a case (at least not officially). This project does not represent an isolation from the "American" Internet, however, it is supposed to limit the influence and control of the U.S.A substantially. Further a weight distribution on the ORSN network would have positive effects (speed) for everyone in the Internet. Right now the ORSN root servers are attainable in the German Internet area and therefore localized closer to the common Internet user in Germany and Europe than a DNS inquiry to the U.S.A or Japan etc. http://european.de.orsn.net/about.php Network http://european.de.orsn.net/network.php Operators http://european.de.orsn.net/members.php ------ Frank ---------Deepak wrote: Is this operational or dross? Basically it sounds like the U.S. Gov't (NTIA)/U.S. Dept of Commerce will take back control of the root name servers from ICANN at some point. I suppose they might just contract operation of them to ICANN, but its unclear to me. I'm hesitant to post because if this were a huge deal I would have expected someone to beat me to the punch. But then again, its a holiday weekend in the U.S. Deepak Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile

1 0

Re: OMB: IPv6 by June 2008
by Christopher L. Morrow 01 Jul '05

01 Jul '05

On Fri, 1 Jul 2005, Mohacsi Janos wrote: > > > > This keeps coming up in each discussion about v6, 'what security measures' > > is never really defined in any real sense. As near as I can tell it's > > level of 'security' is no better (and probably worse at the outset, for > > the implementations not the protocol itself) than v4. I could be wrong, > > but I'm just not seeing any 'inherent security' in v6, and selling it that > > way is just a bad plan. > > > > Just name a few: > - Possibility to end-to-end IPSec. exists in v4 > - Not feasible scanning of subnets remotely eh... maybe, I'm not convinced this matters anyway. > - Privacy enhanced addresses - not tracking usage based on addresses dhcp can do this for you (v4 has mechanisms for this) > - Better ingress filtering > right... because gear that filters so well in v4-land will filter so much better in v6-land? you == crazy. All those objections aside, I'd love to see v6 more fully deployed. I'm not sure I see how it's going to get beyond 'research' or 'play' land, except for some small cases, for quite some time. It's interesting that the flood gates on ip space are openning at IANA though, that should hasten the v6 takeup/deployment :)

6 5

Weekly Routing Table Report
by Routing Table Analysis 01 Jul '05

01 Jul '05

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 02 Jul, 2005 Analysis Summary ---------------- BGP routing table entries examined: 165847 Prefixes after maximum aggregation: 95922 Unique aggregates announced to Internet: 80434 Total ASes present in the Internet Routing Table: 19971 Origin-only ASes present in the Internet Routing Table: 17403 Origin ASes announcing only one prefix: 8195 Transit ASes present in the Internet Routing Table: 2568 Transit-only ASes present in the Internet Routing Table: 73 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 30 Prefixes from unregistered ASNs in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 15 Number of addresses announced to Internet: 1389927648 Equivalent to 82 /8s, 216 /16s and 156 /24s Percentage of available address space announced: 37.5 Percentage of allocated address space announced: 56.5 Percentage of available address space allocated: 66.4 Total number of prefixes smaller than registry allocations: 78553 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 34455 Total APNIC prefixes after maximum aggregation: 16088 Prefixes being announced from the APNIC address blocks: 32278 Unique aggregates announced from the APNIC address blocks: 16386 APNIC Region origin ASes present in the Internet Routing Table: 2298 APNIC Region origin ASes announcing only one prefix: 673 APNIC Region transit ASes present in the Internet Routing Table: 351 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 188395392 Equivalent to 11 /8s, 58 /16s and 175 /24s Percentage of available APNIC address space announced: 69.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 89015 Total ARIN prefixes after maximum aggregation: 54188 Prefixes being announced from the ARIN address blocks: 69548 Unique aggregates announced from the ARIN address blocks: 25639 ARIN Region origin ASes present in the Internet Routing Table: 10038 ARIN Region origin ASes announcing only one prefix: 3696 ARIN Region transit ASes present in the Internet Routing Table: 942 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 251615744 Equivalent to 14 /8s, 255 /16s and 90 /24s Percentage of available ARIN address space announced: 62.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks 24/8, 63/8, 64/6, 68/7, 70/6, 74/7, 76/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 31643 Total RIPE prefixes after maximum aggregation: 21750 Prefixes being announced from the RIPE address blocks: 28788 Unique aggregates announced from the RIPE address blocks: 19330 RIPE Region origin ASes present in the Internet Routing Table: 6816 RIPE Region origin ASes announcing only one prefix: 3596 RIPE Region transit ASes present in the Internet Routing Table: 1112 Average RIPE Region AS path length visible: 5.2 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 210742848 Equivalent to 12 /8s, 143 /16s and 174 /24s Percentage of available RIPE address space announced: 62.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839 RIPE Address Blocks 62/8, 80/5, 88/6, 188/8, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 9047 Total LACNIC prefixes after maximum aggregation: 3125 Prefixes being announced from the LACNIC address blocks: 7430 Unique aggregates announced from the LACNIC address blocks: 4343 LACNIC Region origin ASes present in the Internet Routing Table: 621 LACNIC Region origin ASes announcing only one prefix: 191 LACNIC Region transit ASes present in the Internet Routing Table: 114 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 20414752 Equivalent to 1 /8s, 55 /16s and 129 /24s Percentage of available LACNIC address space announced: 30.4 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 189/8, 190/8, 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 1666 Total AfriNIC prefixes after maximum aggregation: 771 Prefixes being announced from the AfriNIC address blocks: 1020 Unique aggregates announced from the AfriNIC address blocks: 782 AfriNIC Region origin ASes present in the Internet Routing Table: 131 AfriNIC Region origin ASes announcing only one prefix: 39 AfriNIC Region transit ASes present in the Internet Routing Table: 17 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 12 Number of AfriNIC addresses announced to Internet: 2306560 Equivalent to 0 /8s, 35 /16s and 50 /24s Percentage of available AfriNIC address space announced: 6.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 922 5150 193 CHINANET-BACKBONE 1221 759 1454 535 Telstra Pty Ltd 9583 756 55 81 Sify Limited 4755 647 248 146 Videsh Sanchar Nigam Ltd. Aut 4766 591 3413 279 Korea Telecom (KIX) 7545 501 104 72 TPG Internet Pty Ltd 17676 436 6589 75 Softbank BB Corp. 9929 378 223 49 China Netcom Corp. 9443 374 77 76 Primus Telecommunications 10036 346 65 310 C&M Communication Co. Ltd. 2907 338 1805 315 SINET Japan 9498 323 83 60 BHARTI BT INTERNET LTD. 17557 320 23 162 Pakistan Telecom 7474 312 272 215 SingTel Optus Pty Ltd 4802 287 50 164 Wantree Development 4808 282 243 159 CNCGROUP IP network: China169 9837 280 80 184 Powertel Ltd 18302 271 109 155 SK Global co., Ltd 17974 267 65 14 PT TELEKOMUNIKASI INDONESIA 17488 258 15 18 Hathway IP Over Cable Interne ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1491 6430 966 AT&T WorldNet Services 174 1136 5788 1060 Cogent Communications 4323 1128 632 218 Time Warner Telecom 721 1109 21787 313 DLA Systems Automation Center 701 1013 8168 855 UUNET Technologies, Inc. 6197 933 519 434 BellSouth Network Solutions, 1239 882 2899 635 Sprint 2386 882 526 649 AT&T Data Communications Serv 18566 825 224 7 Covad Communications 20115 650 498 321 Charter Communications 209 627 3506 495 Qwest 3356 557 10775 426 Level 3 Communications, LLC 27364 555 44 18 Armstrong Cable Services 3602 542 123 104 Sprint Canada, Inc. 852 540 1093 387 Telus Advanced Communications 3561 539 2385 423 Savvis 22773 498 1188 23 Cox Communications, Inc. 7725 497 60 15 MediaOne 5668 488 114 25 CenturyTel Internet Holdings, 6198 464 425 220 BellSouth Network Solutions, RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 592 1999 483 UUNET - Commercial IP service 3320 305 3232 242 Deutsche Telekom AG 3301 299 1081 286 TeliaNet Sweden 8220 268 469 263 COLT Telecommunications 680 244 2041 240 DFN-IP service G-WiN 8708 231 254 213 Romania Data Systems S.A. 3246 225 488 220 Song Networks 1257 194 712 172 SWIPnet Swedish IP Network 5515 180 778 127 Sonera Solution Autonomous Sy 786 175 1794 175 The JANET IP Service 5400 171 286 146 BT Ignite European Backbone 6746 171 48 149 Dynamic Network Technologies, 3269 169 1520 72 TELECOM ITALIA 719 168 340 100 LANLINK autonomous system 8866 159 21 11 Bulgarian Telecommunication C 3300 154 184 87 AUCS Communications Services 6830 149 537 31 UPC Distribution Services 9121 145 274 41 TTnet Autonomous System 25186 140 145 97 France Telecom Transpac's Tra 3352 138 1272 35 Ibernet, Internet Access Netw LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 377 600 162 UniNet S.A. de C.V. 16814 264 16 12 NSS, S.A. 11172 226 99 57 Servicios Alestra S.A de C.V 11664 203 19 23 Keytech SA 6147 197 110 21 Telefonica Del Peru 14117 152 9 5 Telefonica del Sur S.A. 7303 150 69 18 Telecom Argentina Stet-France 19632 140 14 5 Metropolis Intercom S.A. 22047 133 112 7 VTR PUNTO NET S.A. 6505 131 90 88 Global One Communicaoes Ltda 11556 131 64 3 Cable-Wireless Panama 19169 114 7 21 Telconet 18822 110 7 14 TELEFONICA MANQUEHUE 13999 107 52 9 Mega Cable S.A. de C.V. 6503 101 146 72 AVANTEL, S.A. 10481 101 40 7 Prima S.A. 23216 98 24 23 RAMtelecom Telecomunicaciones 5639 96 12 9 Telecommunications Services o 22927 96 73 25 TELEFONICA DE ARGENTINA 21826 95 13 20 INTERCABLE AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 266 637 223 The Internet Solution 5536 120 15 17 Internet Egypt Network 8452 93 28 6 TEDATA 2018 91 295 86 Tertiary Education Network 20928 82 16 2 Noor Advanced Technologies AS 2905 75 266 67 The Internetworking Company o 6713 59 54 8 Itissalat Al-MAGHRIB 24835 57 34 6 RAYA Telecom - Egypt 9129 45 3 3 UUNET Kenya 12455 40 6 3 Jambonet Autonomous system 5713 36 142 29 Telkom SA Ltd 15475 36 84 4 Nile Online 15706 31 8 3 Sudatel Internet Exchange Aut 8524 25 1 4 AUCEGYPT Autonomous System 16637 22 10 19 Johnnic e-Ventures 10798 19 1 11 Standard Bank of South Africa 23889 19 5 8 MAURITIUS TELECOM 21491 18 1 1 UTL On-line is RF broadband I 12258 17 3 11 Vodacom Internet Company 15808 17 2 2 Communication Solutions Ltd i Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 1128 910 Time Warner Telecom 18566 825 818 Covad Communications 721 1109 796 DLA Systems Automation Center 4134 922 729 CHINANET-BACKBONE 9583 756 675 Sify Limited 27364 555 537 Armstrong Cable Services 4755 647 501 Videsh Sanchar Nigam Ltd. Aut 6197 933 499 BellSouth Network Solutions, 7725 497 482 MediaOne 22773 498 475 Cox Communications, Inc. 5668 488 463 CenturyTel Internet Holdings, 3602 542 438 Sprint Canada, Inc. 7545 501 429 TPG Internet Pty Ltd 17676 436 361 Softbank BB Corp. 6467 384 350 E.Spire Communications, Inc. 20115 650 329 Charter Communications 9929 378 329 China Netcom Corp. 6140 394 319 ImpSat 4766 591 312 Korea Telecom (KIX) 19262 419 306 Verizon Global Networks List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65050 PRIVATE 168.96.148.0/24 6140 ImpSat 65507 PRIVATE 200.0.64.0/24 27750 Cooperación Latino A 65004 PRIVATE 200.0.113.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.0.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.1.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.2.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.3.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.4.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.5.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.6.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.7.0/24 28477 Universidad Autonoma 64512 PRIVATE 200.61.32.0/23 11664 Keytech SA 65201 PRIVATE 201.30.243.0/24 4230 Embratel 65005 PRIVATE 203.200.197.0/24 4755 Videsh Sanchar Nigam 65444 PRIVATE 212.25.125.0/24 8551 Bezeq International Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 50.160.0.0/13 1221 Telstra Pty Ltd 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 172.32.0.0/24 7011 Citizens Utilities 192.43.230.0/24 7575 Australian Academic and Rease 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.84.205.0/24 719 LANLINK autonomous system 192.119.135.0/24 270 NASA 192.135.50.0/24 7018 AT&T WorldNet Services 192.169.0.0/23 3970 RGnet, Inc. 192.172.0.0/19 721 DLA Systems Automation Center 192.200.100.0/24 7018 AT&T WorldNet Services Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:3 /10:8 /11:15 /12:74 /13:161 /14:312 /15:595 /16:8434 /17:2611 /18:4467 /19:10472 /20:11361 /21:9377 /22:12790 /23:13798 /24:90360 /25:345 /26:304 /27:168 /28:44 /29:29 /30:69 /31:0 /32:33 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 809 825 Covad Communications 6197 761 933 BellSouth Network Solutions, 7018 695 1491 AT&T WorldNet Services 2386 597 882 AT&T Data Communications Serv 9583 574 756 Sify Limited 27364 546 555 Armstrong Cable Services 4323 538 1128 Time Warner Telecom 7725 468 497 MediaOne 4766 409 591 Korea Telecom (KIX) 5668 401 488 CenturyTel Internet Holdings, 1239 368 882 Sprint 702 365 592 UUNET - Commercial IP service 6198 339 464 BellSouth Network Solutions, 10036 336 346 C&M Communication Co. Ltd. 7011 320 371 Citizens Utilities 9929 293 378 China Netcom Corp. 15270 290 315 PaeTec.net -a division of Pae 6517 284 306 Yipes Communications, Inc. 20115 281 650 Charter Communications 11456 274 312 Carolina Online, Inc. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 8:21 9:1 12:1545 13:1 15:9 16:2 17:3 18:3 20:4 24:1177 30:2 32:69 33:4 38:132 40:53 44:3 47:2 52:4 55:2 56:3 57:24 58:119 59:51 60:66 61:790 62:635 63:1886 64:2772 65:2089 66:2891 67:602 68:539 69:1086 70:123 71:11 72:250 80:592 81:574 82:427 83:280 84:207 85:272 86:37 87:8 128:175 129:172 130:87 131:296 132:38 133:1 134:144 135:43 136:135 137:74 138:168 139:59 140:267 141:104 142:149 143:145 144:192 145:32 146:280 147:107 148:303 149:171 150:108 151:65 152:107 153:88 154:4 155:143 156:74 157:96 158:161 159:167 160:77 161:68 162:211 163:100 164:209 165:179 166:153 167:242 168:435 169:140 170:319 171:8 172:1 190:1 192:5695 193:3195 194:2414 195:1582 196:665 198:3906 199:3289 200:4049 201:187 202:5806 203:6360 204:3776 205:2008 206:2449 207:2815 208:2049 209:3319 210:1718 211:858 212:1231 213:1321 214:266 215:31 216:3455 217:1150 218:207 219:138 220:394 221:235 222:117 End of report

1 0