- Test - lists.nanog.org

The use of .0/.255 addresses.
by Jonathan McDowell 28 Jun '04

28 Jun '04

Have just spent some time trying to track down what seemed to be an elusive problem, I thought I'd mention it here. I've had problems accessing www.level3.net, www.ebay.co.uk and www.dabs.com (and a few others I don't recall). As I'm the first user of a reasonably new netblock I thought it might be something to do with filters on our upstreams or similar. Trying an IP from our older netblock worked without problems, which seemed to back this up. However eventually I tracked it down to the use of the .0 address from the new netblock; changing to use the .1 address meant I could access the above sites without any difficulty. Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them. J. -- /-\ | This is not a daffodil! This is |@/ Debian GNU/Linux Developer | not a daffodil! \- |

12 15

Re: The use of .0/.255 addresses.
by sthaug＠nethelp.no 27 Jun '04

27 Jun '04

> This is what happens when your educational system continues to teach > classful routing as anything other than a HISTORICAL FOOTNOTE > *coughCiscocough*. Yes, it sure would be nice if Cisco would revise some of their CCNA course material and exams. Plenty of classful stuff still left there, I'm afraid. It's kind of stupid when you have to tell fellow workers trying to get a certification "This isn't real life, you just have to learn it for the exam. In real life we use CIDR." Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: The use of .0/.255 addresses.
by Fergie (Paul Ferguson) 27 Jun '04

27 Jun '04

Amen, brother. - ferg -- Richard A Steenbergen <ras(a)e-gerbil.net> wrote: Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

3 2

Teaching/developing troubleshooting skills
by Pete Kruckenberg 26 Jun '04

26 Jun '04

I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc). It's been so long since I learned network troubleshooting techniques I can't remember how I learned them or even how I used to do it (so poorly). Does anyone have experience with developing a skills-improvement program on this topic? If you've tried such a thing, what worked/didn't work for you? Outside training? Books? Mentoring? Motivational posters? I'm particularly sensitive to the "I got my CCNA, therefore I know everything there is to know about troubleshooting" perspective, and how to encourage improving troubleshooting skills without making it insultingly basic. Thanks for your help. Pete.

5 4

RE: Unplugging spamming PCs
by Larry Pingree 26 Jun '04

26 Jun '04

Authentication and Authorization are two separate and distinct issues. TLS and Authentication have been around for quite a while, but without centralized authorization it will never be deployed by disparate corporations for inter-domain mail! This will not stop spam. Unless of course you want to manage user accounts or certificates with every single customer that you want to have conversations with. Authorization must still be authorized by a third party agency which verifies validity between everyone involved in communications. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, June 25, 2004 12:14 PM To: Larry Pingree Cc: jshen(a)spymac.com; nanog(a)merit.edu Subject: Re: Unplugging spamming PCs On Fri, 25 Jun 2004 09:11:36 PDT, Larry Pingree said: > > What I am proposing is have a registry that you must register > with before other mail servers will accept mail from you. Similar to how > MAPS RBL works, but the mail server itself, enforces it, rather than a > firewall or a ancillary device ACL. This could be made a standard of > SMTP. Yet another "it won't do any good till everybody deploys it". http://www.rhyolite.com/anti-spam/you-might-be.html

3 2

Question from NETCONF working group
by Rob Enns 25 Jun '04

25 Jun '04

Hi, The IETF's NETCONF WG is trying to select a retrieval filter mechanism for use with <get-config> and <get> operations. The fundamental issue is whether to use a subset of the XPath language or whether to define a mechanism based on XML subtree matching. Your comments can help us decide which propsal to choose. Here's the basic NETCONF <get> protocol operation exchange: <rpc message-id="101" xmlns="netconf-uri"> <get> <filter filter-type="filter-uri"> ... filter data ... </filter> </get> </rpc> <rpc-reply message-id="101" xmlns="netconf-uri"> <data> ... XML selected by the filter criteria ... </data> </rpc-reply> There are two options under consideration for the mandatory filter mechanism (i.e., standard values for the 'filter-type' attribute). If we can't get consensus on the mandatory to implement filter, then we will probably make both optional. A) XML sub-tree filtering A mechanism that allows exact match of element and attribute content, as well as the selection of specific subtrees. (This is implemented in Junoscript.) B) Xpath subset A small subset of the Xpath standard that provides essentially the same (or more) filtering functions as the subtree filter. (Note that full implementation of the Xpath 1.0 standard will be optional, and identified by the #xpath capability.) Operator and application programmer preference is really the deciding factor here. Approach (A) uses XML encoding that looks like the data model XML that will be returned in the response. Approach (B) uses an Xpath string encoding in the request, and the corresponding XML is returned in the response. Here are some example requests in both formats, followed by the response that would be returned in both cases. ------------------------------------------------------------------------ - E1) Select the entire <users> sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"/> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"/> t://users </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> <user> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> <company-info> <dept>2</dept> <id>3</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E2) Select all 'name' elements within the 'users' sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"> <user> <name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user/name </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> </user> <user> <name>fred</name> </user> <user> <name>barney</name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E3) One specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E4) Specific elements from a specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type/> <full-name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"]/name | t://users/user[name="fred"]/type | t://users/user[name="fred"]/full-name </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.7) Multiple sub-trees Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info/> </user> <user> <name>fred</name> <company-info> <id/> </company-info> </user> <user> <name>barney</name> <type>superuser</type> <company-info> <dept/> </company-info> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="root"]/company-info | t://users/user[name="fred"]/company-info/id | t://users/user[name="barney" and type="superuser"]/company-info </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <company-info> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.8) Table with attribute naming Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <t:interfaces xmlns:t="http://example.com/schema-2"/> <t:interface t:ifName="eth0"/> </t:interfaces> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-2"> t://interfaces/interface/[@ifName="eth0"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <t:interfaces xmlns:t="http://example.com/schema-2"> <t:interface t:ifName="eth0"> <t:ifInOctets>45621</t:ifInOctets> <t:ifOutOctets>774344</t:ifOutOctets> </t:interface> </t:interfaces> </data> </rpc-reply>

1 0

Can a customer take IP's with them?
by Alex Rubenstein 25 Jun '04

25 Jun '04

Should a customer be allowed to force a carrier to allow them to announce non-portable IP space as they see fit to any other carriers of their choosing when they are no longer buying service from the original carrier [that the space is assigned to]? According to ARIN regulations, the space does not "belong" to us but we have the right to assign or revoke the space to our customers as we see fit. In addition ARIN regulations specifically prohibit us from transferring or selling the IP space to another customer (even if we want to). NAC has a customer who is leaving NAC. As part of normal procedure (and also because the space provided to us by ARIN is non portable), the customer has been informed that the IP space used by the customer will not be available to be used by the customer subsequent to them leaving us. It should be mentioned that the following facts exist, and cannot be disputed: a) customer has obtained space directly from ARIN over a year ago, but has chosen not to renumber from space allocated from us. This was solely their choice, and we did not restrict this in any way. b) customer is exercising the right not to renew the business agreement, and is leaving NAC voluntarily. Thus, they are attempting to file for and obtain a temporary restraining order (TRO), and ask for the following: -- start -- "NAC shall permit CUSTOMER to continue utilization through any carrier or carriers of CUSTOMER's choice of any IP addresses that were utilized by, through or on behalf of CUSTOMER under the current agreement during the term thereof (the "Prior CUSTOMER Addresses") and shall not interfere in any way with the use of the Prior CUSTOMER Addresses, including, but not limited to: (i) by reassignment of IP address space to any customer; aggregation and/or BGP announcement modifications (ii) by directly or indirectly causing the occurrence of superseding or conflicting BGP Global Routing Table entries; filters and/or access lists, and/or (iii) by directly or indirectly causing reduced prioritization of access to and/or from the Prior CUSTOMER Addresses. NAC shall provide CUSTOMER with a LOA within 7 days of CUSTOMERS's written request for sale, NAC shall permit announcement of the Prior CUSTOMER Address to ANY carrier, IP transit, or IP peering network." -- end -- In other words, customer is asking a court to rule whether or not IP space should be portable, when an industry-supported organization (ARIN) has made policy that the space is in fact not portable. It can be further argued that the court could impose a TRO that would potentially negatively affect the operation of my network. NAC does not want to be forced to rely on a customer's ability to properly make complex routing updates that if done improperly could disrupt the entire NAC network. We believe there is a great danger to NAC that their routing mistakes could take down some or all of our network infrastructure. Another VERY important issue to bring up: If customer is granted the legal right to continue to use IP space that is registered to NAC by ARIN, NAC runs into the very serious problem of being liable for all of the Spam that could be generated by the customer and all of the RBLs that the carrier may be added to [that of course will effect all of NAC's customers] with no ability to revoke the IP space to protect itself. This has to potential to effect the NAC network in a catastrophic manner. I'd love any comments from anyone.

19 27

Re: Attn MCI/UUNet - Massive abuse from your network
by Jeff Shultz 25 Jun '04

25 Jun '04

** Reply to message from Brad Knowles <brad.knowles(a)skynet.be> on Fri, 25 Jun 2004 18:14:43 +0200 > At 8:44 AM -0700 2004-06-25, Jeff Shultz wrote: > > > At least if someone in this "clearing house" sells it to the > > terrorists, they will have had to work for it a bit, instead of having > > us hand it to them on a silver platter, as the FCC seems to want. > > Not true. If the information is forced to be completely in the > open, then everyone knows it's not insecure and no one depends on the > fact that it was supposed to be kept secret. This is a case where > you are more secure the more open the information is -- indeed, as we > are in most cases, which is why we have the age-old security mantra > of "security through obscurity is not secure". > Do you realize that the basic element of security, the password, is based on the entire premise you just dismissed? And yet we still use them - and depend on the fact that they are supposed to be kept secret. The problem with being totally open about infrastructure is that there are some vulnerabilities that simply cannot or will not be fixed - wires sometimes have to run across bridges, redundant pumping stations are too expensive... in these cases is it not better to hide where these vulnerabilities are? The problem with your point is that even if the information is forced to be completely in the open, that is no guarantee that it will be fixed, and people _do_ depend on this stuff, regardless of its reliability or security. Do you really think that if we publish all the insecurities of the Internet infrastructure that anyone is gonna stop using it, or business, government, and private citizens are going to quit depending on it? Security through obscurity is not secure - but sometimes it's all you have. -- Jeff Shultz A railfan pulls up to a RR crossing hoping that there will be a train.

4 3

RE: Unplugging spamming PCs
by Larry Pingree 25 Jun '04

25 Jun '04

What I am proposing is have a registry that you must register with before other mail servers will accept mail from you. Similar to how MAPS RBL works, but the mail server itself, enforces it, rather than a firewall or a ancillary device ACL. This could be made a standard of SMTP. LP Best Regards, Larry Larry Pingree 408-543-2190 "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Joe Shen [mailto:jshen@spymac.com] Sent: Thursday, June 24, 2004 6:36 PM To: Larry Pingree Cc: nanog(a)merit.edu Subject: RE: Unplugging spamming PCs Hi, >Mail servers should be registered just like domains and shutdown by a >registrar if they are misusing their registered services. This really >needs to be handled by a multi-lateral legal solution, industry will not >fix it alone. No, I don't think this is good solution First of all, we could not ask customers to register everything they planned with leased line without legal reasons. Second, if I hire DSL/leased_line service from ISP and set up domain name for myself, ISP could not ask me to tell them which port should be opened as I'm not taking a firewalling service, I'm not a member of my service provider. I should be able to do anything that are not perhibited by law or affact someothers. Blocking_port_25 indicates ISP pre-assume that customers will SPAM their network. But, SPAMmer is just a very small group of people. Maybe most of them comes from other countries ( what happens in China). To me, the proper way of anti-spam may ask cooperation between ISPs and Email service providers. Anyway, strengthening anti-spam ability in Email server is a must. regards Joe > >LP > >Best Regards, > >Larry Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com

3 3

Weekly Routing Table Report
by Routing Table Analysis 25 Jun '04

25 Jun '04

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 26 Jun, 2004 Analysis Summary ---------------- BGP routing table entries examined: 142373 Prefixes after maximum aggregation: 85321 Unique aggregates announced to Internet: 68213 Total ASes present in the Internet Routing Table: 17497 Origin-only ASes present in the Internet Routing Table: 15162 Origin ASes announcing only one prefix: 7068 Transit ASes present in the Internet Routing Table: 2335 Transit-only ASes present in the Internet Routing Table: 73 Average AS path length visible in the Internet Routing Table: 4.9 Max AS path length visible: 26 Illegal AS announcements present in the Routing Table: 8 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 19 Number of addresses announced to Internet: 1314051868 Equivalent to 78 /8s, 82 /16s and 215 /24s Percentage of available address space announced: 35.5 Percentage of allocated address space announced: 58.2 Percentage of available address space allocated: 60.9 Total number of prefixes smaller than registry allocations: 65586 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 27046 Total APNIC prefixes after maximum aggregation: 14017 Prefixes being announced from the APNIC address blocks: 25273 Unique aggregates announced from the APNIC address blocks: 13910 APNIC Region origin ASes present in the Internet Routing Table: 2069 APNIC Region origin ASes announcing only one prefix: 614 APNIC Region transit ASes present in the Internet Routing Table: 335 Average APNIC Region AS path length visible: 4.9 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 150449920 Equivalent to 8 /8s, 247 /16s and 175 /24s Percentage of available APNIC address space announced: 68.7 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239 17408 - 18431, 23552 - 24575 APNIC Address Blocks 58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 81982 Total ARIN prefixes after maximum aggregation: 49940 Prefixes being announced from the ARIN address blocks: 63077 Unique aggregates announced from the ARIN address blocks: 21940 ARIN Region origin ASes present in the Internet Routing Table: 9279 ARIN Region origin ASes announcing only one prefix: 3303 ARIN Region transit ASes present in the Internet Routing Table: 909 Average ARIN Region AS path length visible: 4.7 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 225859360 Equivalent to 13 /8s, 118 /16s and 87 /24s Percentage of available ARIN address space announced: 74.8 ARIN AS Blocks 1 - 1876, 1902 - 2042, 2044 - 2046, 2048 - 2106 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, 29695 - 30719 31744 - 33791 ARIN Address Blocks 24/8, 63/8, 64/6, 68/7, 70/8, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 26020 Total RIPE prefixes after maximum aggregation: 18441 Prefixes being announced from the RIPE address blocks: 22802 Unique aggregates announced from the RIPE address blocks: 15175 RIPE Region origin ASes present in the Internet Routing Table: 5606 RIPE Region origin ASes announcing only one prefix: 3018 RIPE Region transit ASes present in the Internet Routing Table: 973 Average RIPE Region AS path length visible: 5.5 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 165059392 Equivalent to 9 /8s, 214 /16s and 155 /24s Percentage of available RIPE address space announced: 57.9 RIPE AS Blocks 1877 - 1901, 2043, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 20480 - 21503, 24576 - 25599, 28672 - 29695 30720 - 31743 RIPE Address Blocks 62/8, 80/5, 88/8, 188/8, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 6167 Total LACNIC prefixes after maximum aggregation: 2247 Prefixes being announced from the LACNIC address blocks: 5797 Unique aggregates announced from the LACNIC address blocks: 3556 LACNIC Region origin ASes present in the Internet Routing Table: 379 LACNIC Region origin ASes announcing only one prefix: 110 LACNIC Region transit ASes present in the Internet Routing Table: 75 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 16 Number of LACNIC addresses announced to Internet: 15110656 Equivalent to 0 /8s, 230 /16s and 146 /24s Percentage of available LACNIC address space announced: 45.0 LACNIC AS Blocks 26592 - 26623, 27648 - 28671 LACNIC Address Blocks 200/7 Emerging AfriNIC Region Analysis Summary ---------------------------------------- Prefixes being announced by AfriNIC Region ASes: 1155 Total AfriNIC prefixes after maximum aggregation: 676 Prefixes being announced from the AfriNIC address blocks: 782 Unique aggregates announced from the AfriNIC address blocks: 584 AfriNIC Region origin ASes present in the Internet Routing Table: 91 AfriNIC Region origin ASes announcing only one prefix: 23 AfriNIC Region transit ASes present in the Internet Routing Table: 12 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 1886720 Equivalent to 0 /8s, 28 /16s and 202 /24s Percentage of available AfriNIC address space announced: 11.2 AfriNIC AS Blocks <none> AfriNIC Address Blocks 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 1221 846 1075 614 Telstra Pty Ltd 4134 792 3664 146 Data Communications Bureau 4766 494 2896 264 Korea Internet Exchange for " 9583 460 38 98 Satyam Infoway Ltd., 4755 374 134 55 Videsh Sanchar Nigam Ltd. Aut 9443 353 69 78 Primus Telecommunications 2907 349 1840 327 SINET Japan 17676 341 5084 33 XTAGE CORPORATION 17557 337 23 165 Pakistan Telecom 703 327 359 256 UUNET 9929 322 156 33 China Netcom Corp. 2764 294 259 241 connect.com.au pty ltd 7474 263 268 206 Optus Communications Pty Ltd 9942 230 71 127 COMindico Australia 9800 224 369 62 CHINA UNICOM 9498 216 48 48 BHARTI BT INTERNET LTD. 10036 198 18 179 C&M Communication Co. Ltd. 4837 186 2019 105 chinanet IDC center beijing n 17974 184 51 99 PT TELEKOMUNIKASI INDONESIA 9304 174 161 25 Hutchison Telecom (HK) ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1448 6892 1002 AT&T 701 1297 8485 924 UUNET Technologies, Inc. 1239 939 2981 633 Sprint 6347 926 400 100 SAVVIS Communications Corpora 3356 899 10935 681 Level 3 Communications, LLC 557 769 63 15 University of Maine System Co 4323 740 555 204 Time Warner Communications, I 18566 724 192 8 Covad Communications 6197 707 525 276 BellSouth Network Solutions, 209 616 3469 508 Qwest 6198 575 439 221 BellSouth Network Solutions, 20115 562 373 288 Charter Communications 852 514 1142 402 Telus Advanced Communications 7843 511 661 128 Adelphia Corp. 7132 455 7872 341 Southwestern Bell Internet Se 2386 425 565 227 AT&T Data Communications Serv 721 393 13171 289 DLA Systems Automation Center 22909 393 825 26 Comcast Cable Corporation 4355 391 323 101 EarthLink, Inc. 705 390 128 266 UUNET Technologies, Inc. RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 647 2039 540 UUNET - Commercial IP service 3320 298 2468 236 Deutsche Telekom AG 3301 295 1098 268 TeliaNet Sweden 8220 271 428 259 COLT Internet - International 1257 247 497 195 SWIPnet Swedish IP Network 680 244 2025 239 DFN-IP service G-WiN 13083 216 51 8 Mannesmann Datenverarbeitung 3246 211 477 208 Song Networks 5515 199 843 144 Sonera Solution Autonomous Sy 8708 186 112 173 Romania Data Systems S.A. 3215 182 895 69 France Telecom Transpac 719 180 288 102 LANLINK autonomous system 25186 174 156 115 France Telecom Transpac's Tra 786 173 1778 173 The JANET IP Service 6746 156 29 127 Dynamic Network Technologies, 5400 144 205 120 BT Ignite European Backbone 3269 134 1099 64 TELECOM ITALIA 3303 133 611 132 Swisscom Ltd 12302 128 18 32 MobiFon S.A. 8866 126 14 11 Bulgarian Telecommunication C LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11172 356 96 58 Servicios Alestra S.A de C.V 6140 343 140 67 ImpSat 8151 270 373 128 UniNet S.A. de C.V. 16814 203 13 7 NSS, S.A. 6147 181 82 21 Telefonica Del Peru 7303 146 53 30 Telecom Argentina Stet-France 6505 134 90 92 Global One Communicaoes Ltda 6503 131 202 89 AVANTEL, S.A. 11992 89 9 29 Integrated Systems 11556 87 57 24 Cable-Wireless Panama 6535 80 5 17 Chilesat Servicios Empresari 14420 77 5 27 ANDINATEL S.A. 14535 76 6 5 Techtel S.A. 15311 75 19 37 Telefonica Empresas 11311 73 7 20 Sinectis S.A. 5639 72 8 8 Telecommunications Services o 4270 71 18 9 Red de Interconexion Universi 14117 69 5 4 Telefonica del Sur S.A. 14259 67 4 5 GTD Internet S.A. 10292 66 6 25 TELECOMMUNICATIONS OF JAMAICA AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 253 632 220 The Internet Solution 5536 111 16 4 Internet Egypt Network 2018 94 297 92 Tertiary Education Network 2905 90 276 80 The Internetworking Company o 11845 38 9 11 Data Pro Business Online 24835 31 18 6 RAYA Telecom - Egypt 9129 28 3 4 UUNET Kenya 8524 25 2 4 AUCEGYPT Autonomous System 12455 25 4 2 Jambonet Autonomous system 16637 25 9 18 Johnnic e-Ventures 5713 24 125 23 Telkom SA Ltd 6713 24 38 9 Itissalat Al-MAGHRIB 14988 24 16 1 Botswana Telecommunications C 10798 18 1 12 Standard Bank of South Africa 15706 16 2 3 Sudatel Internet Exchange Aut 12258 15 3 10 Vodacom Internet Company 8346 13 6 12 SONATEL-AS Autonomous System 17148 13 1 7 First National Bank 21280 13 2 3 Swift Global Kenya Ltd.Is an 2609 12 26 4 Tunisia BackBone AS Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6347 926 826 SAVVIS Communications Corpora 557 769 754 University of Maine System Co 18566 724 716 Covad Communications 4134 792 646 Data Communications Bureau 4323 740 536 Time Warner Communications, I 6197 707 431 BellSouth Network Solutions, 7843 511 383 Adelphia Corp. 701 1297 373 UUNET Technologies, Inc. 22909 393 367 Comcast Cable Corporation 5668 384 367 Century Telephone 9583 460 362 Satyam Infoway Ltd., 27364 376 357 Armstrong Cable Services 6198 575 354 BellSouth Network Solutions, 22773 388 332 Cox Communications, Inc. Atla 4755 374 319 Videsh Sanchar Nigam Ltd. Aut 17676 341 308 XTAGE CORPORATION 1239 939 306 Sprint 11172 356 298 Servicios Alestra S.A de C.V 4355 391 290 EarthLink, Inc. 9929 322 289 China Netcom Corp. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 18416 UNALLOCATED 61.56.96.0/24 9919 New Century InfoComm 18416 UNALLOCATED 61.56.96.0/20 9919 New Century InfoComm 18416 UNALLOCATED 61.56.97.0/24 9919 New Century InfoComm 18416 UNALLOCATED 61.56.98.0/24 9919 New Century InfoComm 65501 PRIVATE 66.60.187.0/24 14051 Roseville Telephone 65501 PRIVATE 66.60.188.0/22 14051 Roseville Telephone 1877 UNALLOCATED 192.108.199.0/24 1876 Southern Methodist U 18412 UNALLOCATED 211.77.0.0/19 9674 Far EastTone Telecom Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 568 DISO-UNRRA 137.0.0.0/13 721 DLA Systems Automation Center 156.154.16.0/22 7786 Lockheed Martin IMS 158.0.0.0/13 721 DLA Systems Automation Center 164.234.0.0/18 721 DLA Systems Automation Center 164.234.0.0/16 721 DLA Systems Automation Center 192.43.230.0/24 4738 South Australian Academic Res 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.83.16.0/20 5515 Sonera Solution Autonomous Sy 192.83.32.0/19 5515 Sonera Solution Autonomous Sy 192.83.96.0/22 5515 Sonera Solution Autonomous Sy 192.83.100.0/24 5515 Sonera Solution Autonomous Sy 192.84.205.0/24 719 LANLINK autonomous system 192.119.135.0/24 270 NASA 192.135.50.0/24 7018 AT&T 192.136.79.0/24 719 LANLINK autonomous system 192.172.0.0/19 568 DISO-UNRRA 192.172.11.0/24 721 DLA Systems Automation Center Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:3 /10:6 /11:15 /12:59 /13:124 /14:301 /15:519 /16:7884 /17:2073 /18:3639 /19:9480 /20:9958 /21:7314 /22:10367 /23:11886 /24:77349 /25:373 /26:387 /27:347 /28:173 /29:15 /30:68 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 557 736 769 University of Maine System Co 18566 707 724 Covad Communications 6347 702 926 SAVVIS Communications Corpora 7018 563 1448 AT&T 6197 536 707 BellSouth Network Solutions, 3356 504 899 Level 3 Communications, LLC 6198 405 575 BellSouth Network Solutions, 702 395 647 UUNET - Commercial IP service 1239 372 939 Sprint 701 366 1297 UUNET Technologies, Inc. 27364 364 376 Armstrong Cable Services 5668 335 384 Century Telephone 4766 313 494 Korea Internet Exchange for " 9583 309 460 Satyam Infoway Ltd., 20115 297 562 Charter Communications 9929 255 322 China Netcom Corp. 14824 254 278 NewSouth Communications Corp. 3320 247 298 Deutsche Telekom AG 690 246 282 Merit Network 25844 244 244 Skadden, Arps, Slate, Meagher Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:3 12:826 13:1 15:5 16:2 17:3 20:8 24:750 32:65 33:1 38:72 40:53 44:4 55:1 56:3 57:15 61:451 62:507 63:1858 64:2028 65:2046 66:2595 67:326 68:500 69:584 70:64 80:531 81:323 82:181 83:92 84:3 128:148 129:176 130:77 131:187 132:21 133:1 134:182 135:17 136:182 137:54 138:167 139:37 140:215 141:124 142:118 143:57 144:100 145:41 146:308 147:77 148:410 149:119 150:96 151:71 152:165 153:64 154:2 155:122 156:60 157:60 158:145 159:147 160:52 161:64 162:383 163:76 164:180 165:159 166:100 167:217 168:228 169:161 170:286 171:8 192:5563 193:2781 194:2046 195:1371 196:555 198:3694 199:3105 200:3552 201:8 202:4675 203:5639 204:3110 205:2098 206:2308 207:2536 208:2218 209:3019 210:1425 211:557 212:993 213:1175 214:66 215:30 216:3734 217:943 218:169 219:112 220:232 221:30 222:40 End of report

1 0