- routing-wg - mailman.ripe.net

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, It seems multihoming discussion is an example of vicious circle (sp): More specific routes result in larger routing table but we want those routes and small table... Let me suggest a blasphemy: CIDR being advertised from two ASes. They say it should be only one, but why? In my opinion there is nothing wrong in advertising CIDR from two ASes as long as you can guarantee each border router advertises CIDR only if it can reach it. Imagine the following construction: AS-A--\ +(OSPF) --(CIDR) AS-B--/ Each BGP speaker advertises CIDR if and only if it learned about it from OSPF. It can be done, if you don't know how I'll forward you a working example. Each border router generates a default router and injects it into OSPF. From technical point of view I see no reasons why it should not work. What you need is: * An agreement between ISPs * Change in procedure making such a union of ASes an officially blessed solution so nobody would dare to hinder cooperation with filters. * Optionally you may need a separate CIDR, since both ASes have to advertise same prefix. You need it if each ISP wants to have private customers in addition to shared ones. The customer has "an independent connection to two ISPs" which is the quest item. I see more commercial than technical problems with such a solution. However my expertise is limited and somebody can point drawbacks I cannot see. Feel free to burn me on a stake, that's the right way of treating a blasphemy ;-) Regards, Jacek

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 10 Oct '01

10 Oct '01

> -----Original Message----- > From: Steven Bakker [mailto:steven@icoe.att.com] > Sent: Wednesday, October 10, 2001 11:08 AM > To: Nipper, Arnold > Cc: Stephen Burley; Gert Doering; Dave Pratt; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > > Of course another prefix and another AS is added to the > routing table > > but thereby you are witdrawing at least more than two (both > prefs as well as > > AS). ==> table gets smaller. > > Your math is confusing... or maybe I'm misunderstanding the obvious. > Yes, multihoming adds another AS and (at least one) (longish) > prefix to > the routing table. But in your reasoning, which two prefixes > and one AS > are being withdrawn? If I resiliently multi-home to one ISP, > and I get > my address space from its block, I do not add any prefix or AS to the > (global) routing table. Even if I multi-home to two ISPs and > selectively NAT depending on the outgoing connection, I'll be NAT-ing > into the respective ISP's address space (which I presume is properly > aggregated), adding no prefix or AS. Your prefixes (let's say /24) has to be announced by two ISPs so the packets will come back to you. If ISP A's link failed then that /24 with ISP A in the ASPATH will be withdrawn. And ISP B's /24 will become active. So in the global routing table there will be TWO /24 with different ASPATH. If this /24 is in ISP A's PA space then it saves one but the one from ISP B's one NEEDs to be in the global routing table. The worse case: ISP A only announces aggregate block even if the link failed then the traffic will still go thru ISP A then get dropped. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, Decisions are based on both science and superstition. In my opinion requests to connect to "two independent ISPs" result mostly from superstition. BGP routing is not particularly good at servicing resilient links. If an access link to ISP fails it takes some time before routing reconfigures, we don't like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of single ISP would do the you much better. I wonder why virtually nobody offers such a service? From my perspective an entity running LIR is responsible for both IP addressing and IP traffic shaping. An entity may wish to become a LIR for number of business reasons. RIR should not verify validity of those reasons, however RIR should verify if to-be LIR understand what he applies for. This may mean technical consultancy for free, but since RIPE is a non-profit organization raised membership fees have to be spent anyway ;-) Regards, Jacek

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > >> > >> Great! Now we have to collect routing policies from > thousands of small LIRs > >> while still have to deal with thousands of small prefixes. > > > So? There is no difference between thousands of PI prefixes and > > "thousands of small LIRs", except that the latter actually have to > > *pay* for what they cause. > > Right. Strong ACK on this. > So what do the small LIRs solve ? > >> And if the major ISPs stop listening to the more specfic > routes then even > >> using the address from PI space won't work (unless you are > big enough). > > > Yes. This is what it's all about. Small PI space really > hurts people. > > Yep. And therefore these "small" PI stuff should be cleaned > up. The User itself > can use it internally and could get a /24 routed from PA space. > > But it is really not the optimum solution, as it waste's ip > address space. And > we have enough RFC1918 space... > This is not enough but I am going to go with this solution. Then we will ask you to assign only aggregatable address( to a /20 of course) to your customer if they are going to use CW as a backup ISP. You will happily reassign their addresses once they got a link from CW, right ? If you don't then what ? CW will have to leak your /24 to the world but it is you causing it. On the other hand, if our customer ask you to be the backup ISP, we will ask them to change all their DNS records, all their host tables, all their static IP configs to change to the new aggregatable block. If they think this is too much hassle, we will advice them not to use your service because you don't accept /24 multi-homed customer. This sounds realistic enough ? > > Letting "the whole world" see a /16 (from the upstream) and > the direct > > peers a /24 (or whatever) means global routing will just > work fine (over > > the upstream's PA block) and and IX routing will also work just fine > > (using the more specific). > > right, but is it generally used ? > I see a lot of /24 out of the same block from a /16 announced > space globally > (AS5511 for example) > > Because it is not the solution to the real world, that's why people can only talk about it but not really to enforce it. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > > > Great! Now we have to collect routing policies from > thousands of small LIRs > > while still have to deal with thousands of small prefixes. > > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. To syncronize between the major RIRs is already dufficult enough, to make sure thousands of small LIRs all have correct info is not worth the problem it is trying to solve. > > > > Now more and more major ISPs are filtering out routes from > other ISPs ( > > becuase we don't have > > transit agreements) so the multi-homed customer have to > have their own AS. > > No. This is an interesting arguments, but the fact that C&W > has problems > with some of their peers doesn't mean "the whole world has to drown in > multihomed ASes". Get your contracts right. > Maybe you will carry other ISP's transit routes and they can dump about several GB of traffic for you to pass thru. And you are asking ISP to spend tons of money to carry the traffic that other ISPs are making money of ? Compared to this solution I think multihomed ASes is more acceptable. > > And if the major ISPs stop listening to the more specfic > routes then even > > using the address from PI space won't work (unless you are > big enough). > > Yes. This is what it's all about. Small PI space really > hurts people. > The thing is any ISP can decide to only accept /20 and above and claim any routes beyond those are not important. The truth is the INTERNET is bandwidth oriented and business like IX and webhosting are high bandwidth but not prefixes hungry. But they are hurting because someone think they are not wasting IP addresses enough. So the advice is if for any reason you need a backup link from different ISPs you better claim a /20 even a /24 is enough. > > All these solutions kind of imply that if you can't have > /20 prefix then you > > can't be multi-homed. What happen if a customer want to > have an OC-48 > > multi-homed link but only use prefix < /20 (that happens to > the Internet > > Exchange people a lot ) ? > > So announce it to the internet exchange. Why does it have to > be visible > in the whole world? > > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work > fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). > > Bad example. > So if a end-user uses one ISP's /24 from their PA space and he want to divide 50-50 traffic with a second ISP then what ? The second ISP will say no /24 allowed so can you ask the first ISP to assign a /20 ? (Don't worry CW will happily accept your /24) Even worse example. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

Comments followed. > > Hi, > > On Tue, Oct 09, 2001 at 09:13:05PM +0200, Jan-Ahrent-Czmok wrote: > > Some providers are multihomed > > but cannot cover the costs, even for a small lir. > > If you want to be multihomed, the costs for routers & co. are > far higher > than for being LIR. If you can't afford being LIR, be single-homed. > Great! Now we have to collect routing policies from thousands of small LIRs while still have to deal with thousands of small prefixes. > > Nonsense. Nobody is announcing 192.0.0.0/8, or supernets of other's > networks - and what is in the RIPE database doesn't affect routing. > > To show the first few things from 192/8: > > *>i192.0.32.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > *>i192.0.34.0 195.158.244.133 100 0 > 1755 1239 5676 226 > i > * i192.0.36.0 195.206.66.61 3 100 0 > 3300 701 2914 20144 > i > *>i 195.158.244.133 100 0 > 1755 1239 2914 2014 > 4 i > * i192.1.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > * i192.2.0.0/16 195.206.66.61 3 100 0 > 3300 701 1 i > *>i 195.158.244.133 100 0 > 1755 1239 1 i > > so if I filter those, why should the traffic go to XLink? > Why should > *any* traffic go to RIPE? It will be just blackholed (or > default-routed > to one of my upstreams, if I happen to have a default-route). > > Please do your homework about routing and BGP before selling people > consulting about multihoming. > Now more and more major ISPs are filtering out routes from other ISPs ( becuase we don't have transit agreements) so the multi-homed customer have to have their own AS. And if the major ISPs stop listening to the more specfic routes then even using the address from PI space won't work (unless you are big enough). All these solutions kind of imply that if you can't have /20 prefix then you can't be multi-homed. What happen if a customer want to have an OC-48 multi-homed link but only use prefix < /20 (that happens to the Internet Exchange people a lot ) ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 3

Reminder: RIPE-181 to RPSL Migration; Phase 3.
by Andrei Robachevsky 09 Oct '01

09 Oct '01

Dear Colleagues, [Apologies for multiple messages] On and from Monday, 15th October, 2001, the RIPE Database will no longer accept updates in RIPE-181 format. Mail robot at <auto-181(a)ripe.net> will be shutdown. The update path for the TEST database will also be changed. We plan to discontinue <test-181(a)ripe.net> service on 11th October, 2001. If you are still sending updates in RIPE-181 format, we advise you to switch to RPSL before 15th October. Please send your objects in RPSL format to <auto-dbm(a)ripe.net>. You may use ripe2rpsl utility to convert your RIPE-181 objects to RPSL format before sending them to the RIPE Database. The utility can be found at ftp://ftp.ripe.net/tools/ripe2rpsl-3.0.2.tar.gz. As part of this final step we will also make some cleanup of the ftp.ripe.net site. - The top directory for the RIPE Database software and flat object files is ftp://ftp.ripe.net/ripe/dbase. - "Short" versions of flat object files [*] will not be supported. [*]Version of a flat object file where attribute names are abbreviated to 2 letter code starting with '*'. The name of the object file also contains the object type in abbreviated form. For example ripe.db.in is the "short" version of the flat file for inetnum objects, while ripe.db.inetnum is the "long " version that is RPSL compliant. For more information please visit http://www.ripe.net/rpsl If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

RE: more specific routes in today reality
by Boyan Krosnov 09 Oct '01

09 Oct '01

Hi, There are other solutions for multihoming with NAT but I think we are again hitting that NAT against no NAT issue. I think that I should say it now to avoid further flamewars. NAT is not always a possible solution. It may be good to use it in some cases but it is not in others. Those other cases are the ones that this discussion is about. Or at least I think so :) CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Mirta Matic [mailto:mirta.matic@hinet.hr] > Sent: Tuesday, October 09, 2001 4:55 PM > To: Sascha E. Pollok > Cc: Gert Doering; Vladimir A. Jakovenko; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: more specific routes in today reality > > > Hello, > > have you ever heard for RADWARE solution for that problem? > Some RADWARE box can check distance to destination via both > ISP's and makes > decision from what IP address range have to get address for > NAT (of course, > customer have to have two ranges of addresses). If connection > via one ISP > failed, all traffic will be rerouted via another using IP > address from IP > address range of that ISP. > > Mirta Matic > mirta.matic(a)hinet.hr > > tel: +385 1 4914 207 > fax: +385 1 4914 222

1 0

The Cidr Report
by CIDR Report 06 Oct '01

06 Oct '01

This is an auto-generated mail on Fri Oct 5 23:00:01 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 05Oct01 0) General Status Table History ------------- Date Prefixes 280901 104483 290901 104988 300901 104943 011001 105036 021001 105301 031001 104637 041001 104254 051001 104449 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11739 Number of ASes announcing only one prefix: 6989 (3974 cidr, 3015 classful) Largest number of cidr routes: 844 announced by AS701 Largest number of classful routes: 1394 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1258 958 300 23.8% Telstra Pty Ltd AS4151 302 170 132 43.7% USDA AS16473 201 76 125 62.2% Bell South AS577 307 187 120 39.1% Bell Advanced Communications Inc. AS13999 131 20 111 84.7% Mega Cable S.A. de C.V. AS4293 375 267 108 28.8% Cable & Wireless USA AS2048 215 116 99 46.0% State of Louisiana AS4755 208 131 77 37.0% Videsh Sanchar Nigam Ltd. Autonom AS1239 481 410 71 14.8% Sprint AS3464 163 95 68 41.7% Alabama SuperComputer Network AS12302 98 32 66 67.3% MobiFon S.A. AS11686 192 126 66 34.4% Education Networks of America AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS4200 137 72 65 47.4% Apex Global Information Services, AS17557 124 65 59 47.6% Pakistan Telecom AS16758 63 6 57 90.5% IKON Office Solutions AS209 309 254 55 17.8% Qwest AS306 60 6 54 90.0% National Guard Bureau AS3908 291 238 53 18.2% Supernet, Inc. AS400 137 85 52 38.0% Headquarters Standard Systems Cen AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 537 486 51 9.5% BBN Planet AS637 106 58 48 45.3% Department of Navy AS4323 246 198 48 19.5% Time Warner Communications, Inc. AS1913 152 104 48 31.6% Defense Logistics Agency AS10620 68 21 47 69.1% TVCABLE BOGOTA AS15290 246 200 46 18.7% AT&T Canada IES AS376 120 76 44 36.7% Reseau Interordinateurs Scientiqu AS5416 51 9 42 82.4% BATELCO-BH For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Weekly Routing Table Report
by Routing Analysis 04 Oct '01

04 Oct '01

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 For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 05 Oct, 2001 Analysis Summary ---------------- BGP routing table entries examined: 109173 Origin ASes present in the Internet Routing Table: 11828 Origin ASes announcing only one prefix: 4342 Transit ASes present in the Internet Routing Table: 1528 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 70 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 14 Number of addresses announced to Internet: 1258644271 Equivalent to 75 /8s, 5 /16s and 99 /24s Percentage of available address space announced: 34.0 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 51.9 Total number of prefixes smaller than registry allocations: 73973 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 16423 Prefixes being announced from the APNIC address blocks: 14867 APNIC Region origin ASes present in the Internet Routing Table: 1381 APNIC Region origin ASes announcing only one prefix: 459 APNIC Region transit ASes present in the Internet Routing Table: 234 Average APNIC Region AS path length visible: 5.1 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 81201752 Equivalent to 4 /8s, 215 /16s and 10 /24s Percentage of available APNIC address space announced: 79.8 APNIC AS Blocks 4608 - 4864, 7467 - 7722, 9216 - 10239, 17408 - 18431 APNIC Address Blocks 61/8, 202/7, 210/7 and 218/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 75127 Prefixes being announced from the ARIN address blocks: 53630 ARIN Region origin ASes present in the Internet Routing Table: 7110 ARIN Region origin ASes announcing only one prefix: 2114 ARIN Region transit ASes present in the Internet Routing Table: 710 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 232748348 Equivalent to 13 /8s, 223 /16s and 117 /24s Percentage of available ARIN address space announced: 86.7 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 - 22527 ARIN Address Blocks 24/8, 63/8, 64/6, 68/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 17617 Prefixes being announced from the RIPE address blocks: 14020 RIPE Region origin ASes present in the Internet Routing Table: 3345 RIPE Region origin ASes announcing only one prefix: 1769 RIPE Region transit ASes present in the Internet Routing Table: 586 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 15 Number of RIPE addresses announced to Internet: 108070239 Equivalent to 6 /8s, 113 /16s and 5 /24s Percentage of available RIPE address space announced: 71.6 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 RIPE Address Blocks 62/8, 80/7, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv Description 1221 1616 1313 Telstra Pty Ltd 2764 412 374 connect.com.au pty ltd 703 398 372 UUNET Technologies, Inc. 2907 369 1847 SINET Japan 4755 292 160 Videsh Sanchar Nigam Ltd. Aut 7474 246 274 Optus Communications Pty Ltd 4134 235 1805 Data Communications Bureau 4740 186 23 OzEmail ISP 4766 182 1466 Korea Internet Exchange for " 7539 180 186 TANet2, sponsored by NSC, TAI 9443 158 53 Primus Telecommunications 4786 127 17 NetConnect Communications Pty 7545 125 23 TPG Internet Pty Ltd 9768 123 378 Korea Telecom 4763 122 69 Telstra New Zealand 17557 122 8 Pakistan Telecom 2521 119 170 PSINet Japan 9583 118 60 Satyam Infoway Ltd., 4713 117 885 NTT Communications Corporatio 17561 116 167 Internet service provision to RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 702 890 1988 UUNET Technologies, Inc. 3301 440 937 TeliaNet Sweden 1257 273 512 SWIPnet Swedish IP Network 680 242 2340 DFN-IP service G-WiN 3215 232 515 France Telecom / &Equant 5515 193 687 Sonera Finland Autonomous Sys 3320 188 1942 Deutsche Telekom AG 786 185 1890 The JANET IP Service 8708 155 16 Romania Data Systems S.A. 15870 144 10 Global Center Frankfurt 5400 141 65 Concert European Core Network 719 137 288 LANLINK autonomous system 1270 137 717 UUNET Germany 3303 129 560 Swisscom Ltd 2856 127 776 BTnet UK Regional network 5549 127 67 Nextra Deutschland GmbH + Co. 15878 123 9 Global Center Paris 517 113 253 KPNQwest Germany GmbH 1267 103 1988 Infostrada S.p.A. 12302 101 6 MobiFon S.A. ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv Description 701 2256 9112 UUNET Technologies, Inc. 3908 1143 1545 Supernet, Inc. 7018 1065 7232 AT&T 1 877 8623 BBN Planet 7046 810 1005 UUNET Technologies, Inc. 1239 757 3373 Sprint 3967 616 470 Exodus Communication 209 562 2235 Qwest 690 514 80 Merit Network 2914 496 2287 Verio, Inc. 4293 457 112 Cable & Wireless USA 3561 410 2373 Cable & Wireless USA 705 399 82 UUNET Technologies, Inc. 721 394 4407 DLA Systems Automation Center 2548 389 1007 Business Internet, Inc. 3549 372 835 Global Crossing 2149 361 263 Performance Systems, Inc. 4323 352 355 Time Warner Communications, I 577 351 620 Bell Advanced Communications 3741 347 773 The Internet Solution Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv Description 701 2256 9112 UUNET Technologies, Inc. 1221 1616 1313 Telstra Pty Ltd 3908 1143 1545 Supernet, Inc. 7018 1065 7232 AT&T 702 890 1988 UUNET Technologies, Inc. 1 877 8623 BBN Planet 7046 810 1005 UUNET Technologies, Inc. 1239 757 3373 Sprint 3967 616 470 Exodus Communication 209 562 2235 Qwest 690 514 80 Merit Network 2914 496 2287 Verio, Inc. 4293 457 112 Cable & Wireless USA 3301 440 937 TeliaNet Sweden 2764 412 374 connect.com.au pty ltd 3561 410 2373 Cable & Wireless USA 705 399 82 UUNET Technologies, Inc. 703 398 372 UUNET Technologies, Inc. 721 394 4407 DLA Systems Automation Center 2548 389 1007 Business Internet, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 22153 UNALLOCATED 63.167.108.0/24 1239 Sprint 6971 UNALLOCATED 64.42.0.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.0.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 64.42.16.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.42.32.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.40.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.48.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.56.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.60.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.64.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.72.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.80.0/21 2914 Verio, Inc. 6971 UNALLOCATED 64.42.104.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.108.0/22 2914 Verio, Inc. 6971 UNALLOCATED 64.42.112.0/20 2914 Verio, Inc. 6971 UNALLOCATED 64.87.64.0/19 2516 Kokusai Denshin Denw 22153 UNALLOCATED 65.161.192.0/24 1239 Sprint 22153 UNALLOCATED 65.165.127.0/24 1239 Sprint 65000 PRIVATE 138.163.4.0/24 665 Department of Navy 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 64512 PRIVATE 161.132.234.0/24 8143 Publicom Corp. 22153 UNALLOCATED 168.215.234.0/23 22026 Time Warner Telecom 22153 UNALLOCATED 168.215.236.0/23 22026 Time Warner Telecom 6971 UNALLOCATED 192.103.229.0/24 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.230.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.232.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.236.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 192.103.237.0/24 2516 Kokusai Denshin Denw 1877 UNALLOCATED 192.108.201.0/24 1880 Stupi, house man's p 5555 UNALLOCATED 192.156.8.0/24 721 DLA Systems Automati 5555 UNALLOCATED 192.156.41.0/24 721 DLA Systems Automati 65460 PRIVATE 192.231.11.0/24 7018 AT&T 22290 UNALLOCATED 198.140.161.0/24 2914 Verio, Inc. 5555 UNALLOCATED 199.10.190.0/24 721 DLA Systems Automati 22290 UNALLOCATED 199.217.152.0/24 2914 Verio, Inc. 22290 UNALLOCATED 199.217.187.0/24 2914 Verio, Inc. 6971 UNALLOCATED 199.249.223.0/24 2516 Kokusai Denshin Denw 22290 UNALLOCATED 205.159.194.0/24 2914 Verio, Inc. 6971 UNALLOCATED 206.58.248.0/22 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.248.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 206.58.252.0/23 2914 Verio, Inc. 6971 UNALLOCATED 206.58.254.0/23 2914 Verio, Inc. 64803 PRIVATE 206.81.213.0/24 6225 US West Communicatio 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 22290 UNALLOCATED 207.150.139.0/24 2914 Verio, Inc. 22075 UNALLOCATED 209.39.134.0/24 2914 Verio, Inc. 65515 PRIVATE 212.110.142.0/24 5593 CRIS-AS 6971 UNALLOCATED 216.105.192.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.121.224.0/19 2516 Kokusai Denshin Denw 64803 PRIVATE 216.160.71.0/24 6225 US West Communicatio 6971 UNALLOCATED 216.174.192.0/21 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.192.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/23 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.200.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.202.0/24 2914 Verio, Inc. 6971 UNALLOCATED 216.174.208.0/20 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.174.232.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.174.240.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.128.0/18 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.128.0/17 2516 Kokusai Denshin Denw 6971 UNALLOCATED 216.210.140.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.144.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.160.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.176.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.184.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.200.0/22 2914 Verio, Inc. 6971 UNALLOCATED 216.210.216.0/21 2914 Verio, Inc. 6971 UNALLOCATED 216.210.224.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.210.240.0/20 2914 Verio, Inc. 6971 UNALLOCATED 216.229.96.0/20 2516 Kokusai Denshin Denw Advertised Unregistered Addresses --------------------------------- Network Origin AS Description 128.65.0.0/16 3463 ACES Research Inc 132.0.0.0/10 568 DISO-UNRRA 134.137.0.0/16 400 Headquarters Standard Systems 135.0.0.0/13 10455 Lucent Technologies 137.0.0.0/13 568 DISO-UNRRA 138.94.0.0/16 1 BBN Planet 144.7.0.0/16 701 UUNET Technologies, Inc. 153.34.0.0/15 701 UUNET Technologies, Inc. 153.36.0.0/14 701 UUNET Technologies, Inc. 154.150.0.0/16 6494 IDCI 158.0.0.0/13 568 DISO-UNRRA 164.233.0.0/16 6020 DISA NETWORK SERVICES 164.235.0.0/16 6025 US DOD NIC Unregistered 201.115.100.0/24 7018 AT&T Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:5 /10:8 /11:12 /12:33 /13:87 /14:226 /15:387 /16:7114 /17:1269 /18:2372 /19:6986 /20:5899 /21:4800 /22:7078 /23:9078 /24:62286 /25:306 /26:326 /27:251 /28:251 /29:150 /30:173 /31:1 /32:57 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 1221 1469 1616 Telstra Pty Ltd 701 1434 2256 UUNET Technologies, Inc. 3908 868 1143 Supernet, Inc. 7046 634 810 UUNET Technologies, Inc. 702 603 890 UUNET Technologies, Inc. 7018 561 1065 AT&T 690 511 514 Merit Network 4293 443 457 Cable & Wireless USA 3967 436 616 Exodus Communication 1 422 877 BBN Planet 1239 421 757 Sprint 209 400 562 Qwest 2764 366 412 connect.com.au pty ltd 705 348 399 UUNET Technologies, Inc. 703 327 398 UUNET Technologies, Inc. 5106 319 338 Ameritech Advanced Data Servi 4151 300 342 USDA 11371 299 310 Rhythms NetConnections 4323 294 352 Time Warner Communications, I 2548 280 389 Business Internet, Inc. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:6 9:1 12:417 13:10 15:1 17:5 20:1 24:800 25:1 26:1 32:74 38:14 43:4 44:2 53:2 57:15 61:100 62:145 63:1936 64:1306 65:810 66:468 67:32 80:65 128:52 129:111 130:19 131:44 132:39 133:2 134:127 135:12 136:92 137:92 138:153 139:49 140:176 141:195 142:57 143:39 144:152 145:30 146:146 147:129 148:83 149:87 150:38 151:179 152:396 153:48 154:18 155:83 156:96 157:111 158:74 159:69 160:48 161:61 162:71 163:146 164:101 165:98 166:195 167:154 168:129 169:38 170:270 171:2 192:5615 193:1967 194:2060 195:848 196:452 198:4114 199:3892 200:2374 201:1 202:2838 203:4577 204:3386 205:2214 206:2920 207:2623 208:3126 209:3164 210:572 211:137 212:864 213:518 214:9 215:14 216:3084 217:388 218:2 End of report

1 0