February 2001 - routing-wg - mailman.ripe.net

The Cidr Report
by Tony Bates 24 Feb '01

24 Feb '01

This is an auto-generated mail on Fri Feb 23 23:00:02 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 23Feb01 0) General Status Table History ------------- Date Prefixes 110201 96509 120201 96907 200201 96086 200201 96219 200201 96217 210201 96188 220201 96107 230201 96158 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 10023 Number of ASes announcing only one prefix: 5876 (3327 cidr, 2549 classful) Largest number of cidr routes: 959 announced by AS701 Largest number of classful routes: 1714 announced by AS701 1) Gains by aggregating at the origin AS level --- 23Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1714 1502 212 12.4% UUNET Technologies, Inc. AS1221 640 487 153 23.9% Telstra Pty Ltd AS8006 145 19 126 86.9% Systems & Software Consortium, In AS7545 193 73 120 62.2% TPG Internet Pty Ltd AS9269 163 52 111 68.1% Internet service Provider in Hong AS13999 109 7 102 93.6% Mega Cable S.A. de C.V. AS6595 161 62 99 61.5% DoD Education Activity Network As AS4293 380 287 93 24.5% Cable & Wireless USA AS6429 192 101 91 47.4% RdC Internet AS271 197 107 90 45.7% University of British Columbia AS8013 330 244 86 26.1% PSINet Ltd. Canada AS705 329 243 86 26.1% UUNET Technologies, Inc. AS7496 103 22 81 78.6% Power Up AS4755 207 127 80 38.6% Videsh Sanchar Nigam Ltd. Autonom AS4151 242 166 76 31.4% USDA AS1942 136 64 72 52.9% FR-CICG-GRENOBLE AS7018 631 560 71 11.3% AT&T AS577 235 166 69 29.4% Bell Advanced Communications Inc. AS7046 322 254 68 21.1% UUNET Technologies, Inc. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS724 220 157 63 28.6% DLA Systems Automation Center AS1727 156 93 63 40.4% Commander Naval Surface force US AS11170 64 1 63 98.4% Bewell Net AS3464 154 92 62 40.3% Alabama SuperComputer Network AS174 483 421 62 12.8% PSINet Inc. AS3749 118 59 59 50.0% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 132 76 56 42.4% Reseau Interordinateurs Scientiqu AS226 148 92 56 37.8% Los Nettos 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 22 Feb '01

22 Feb '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 23 Feb, 2001 Analysis Summary ---------------- BGP routing table entries examined: 101198 Origin ASes present in the Internet Routing Table: 10071 Origin ASes announcing only one prefix: 3584 Transit ASes present in the Internet Routing Table: 1348 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 16 Illegal AS announcements present in the Routing Table: 14 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 3 Number of addresses announced to Internet: 1243790830 Equivalent to 74 /8s, 34 /16s and 189 /24s Percentage of available address space announced: 33.6 Percentage of allocated address space announced: 65.8 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15712 Prefixes being announced from the APNIC address blocks: 14048 APNIC Region origin ASes present in the Internet Routing Table: 1162 APNIC Region origin ASes announcing only one prefix: 420 APNIC Region transit ASes present in the Internet Routing Table: 193 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 69937651 Equivalent to 4 /8s, 43 /16s and 41 /24s Percentage of available APNIC address space announced: 68.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: 69818 Prefixes being announced from the ARIN address blocks: 47624 ARIN Region origin ASes present in the Internet Routing Table: 6144 ARIN Region origin ASes announcing only one prefix: 1786 ARIN Region transit ASes present in the Internet Routing Table: 637 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 13 Number of ARIN addresses announced to Internet: 194202724 Equivalent to 11 /8s, 147 /16s and 76 /24s Percentage of available ARIN address space announced: 89.0 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 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15654 Prefixes being announced from the RIPE address blocks: 12384 RIPE Region origin ASes present in the Internet Routing Table: 2764 RIPE Region origin ASes announcing only one prefix: 1378 RIPE Region transit ASes present in the Internet Routing Table: 516 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 16 Number of RIPE addresses announced to Internet: 107480842 Equivalent to 6 /8s, 104 /16s and 7 /24s Percentage of available RIPE address space announced: 91.5 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2394 1189 Telstra 2764 427 140 connect.com.au pty ltd 703 391 253 UUNET Technologies, Inc. 2907 376 909 SINET Japan 4755 305 111 VSNL India 4618 212 56 Internet Thailand 4740 209 13 Ozemail 9269 206 24 Hong Kong CTI 4538 205 948 China Education and Research 7545 203 7 TPG Internet Pty Ltd 7474 199 89 Optus Communications 7657 198 12 The Internet Group Limited 4763 187 43 Telstra New Zealand 4766 174 619 KORnet Powered BY Korea Telec 4134 173 557 Data Communications Bureau 3462 137 205 Data Communications Institute 4786 131 8 NetConnect Communications Pty 7539 131 86 Delegated to TWNIC for subseq 7586 131 10 Paradox Digital Pty. Ltd 7496 128 9 Power Up RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 413 607 UUNET Technologies, Inc. 3301 402 330 TeliaNet Sweden 1257 311 248 Swipnet AB 3215 273 183 RAIN 1270 271 450 UUNET Germany 680 203 889 Deutschef Forschurgsnetz 719 190 146 LANLINK 786 184 960 JANET IP Service 5515 168 318 Sonera Finland 3320 167 462 Deutsche Telekom AG 1849 154 271 UUNET UK (formerly PIPEX) 1942 139 53 GIP Renater 517 135 137 Xlink 2856 130 388 BTnet UK Regional network 3303 129 277 Swisscom 5400 113 31 Concert Internet Plus Europea 1901 104 77 EUnet Austria 1267 99 986 IUnet S.p.A 3269 86 275 TELECOM ITALIA 2830 85 30 UUNET UK (formerly PIPEX) ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2666 3571 UUNET Technologies, Inc. 1 1006 4565 BBN Planet 7018 932 3017 AT&T 705 739 41 UUNET Technologies, Inc. 7046 715 524 UUNET Technologies, Inc. 1239 641 1551 Sprint ICM-Inria 2914 626 1271 Verio, Inc. 174 583 2799 PSINet Inc. 3561 573 1276 Cable & Wireless USA 3549 533 473 Frontier GlobalCenter 2551 498 345 NETCOM On-Line Communication 4293 471 57 Cable & Wireless USA 209 470 658 Qwest 2548 394 515 Digital Express Group, Inc. 3908 389 280 Supernet, Inc. 8151 364 204 UniNet S.A. de C.V. 271 349 270 BCnet Backbone 8013 339 63 PSINet Ltd. Canada 690 328 34 Merit Network 11371 325 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2666 3571 UUNET Technologies, Inc. 1221 2394 1189 Telstra 1 1006 4565 BBN Planet 7018 932 3017 AT&T 705 739 41 UUNET Technologies, Inc. 7046 715 524 UUNET Technologies, Inc. 1239 641 1551 Sprint ICM-Inria 2914 626 1271 Verio, Inc. 174 583 2799 PSINet Inc. 3561 573 1276 Cable & Wireless USA 3549 533 473 Frontier GlobalCenter 2551 498 345 NETCOM On-Line Communication 4293 471 57 Cable & Wireless USA 209 470 658 Qwest 2764 427 140 connect.com.au pty ltd 702 413 607 UUNET Technologies, Inc. 3301 402 330 TeliaNet Sweden 2548 394 515 Digital Express Group, Inc. 703 391 253 UUNET Technologies, Inc. 3908 389 280 Supernet, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65535 PRIVATE 62.4.68.96/27 6461 AboveNet Communicati 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 91.16.23.0/24 11770 Net56 103.22.7.0/24 9768 PubNet (Korea Telecom) Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:23 /9:4 /10:5 /11:10 /12:32 /13:62 /14:196 /15:306 /16:6866 /17:1062 /18:2040 /19:6379 /20:4714 /21:4339 /22:6578 /23:8567 /24:58739 /25:271 /26:345 /27:147 /28:110 /29:83 /30:178 /31:0 /32:142 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:316 13:10 15:1 17:1 24:660 26:1 32:7 38:8 44:3 53:2 55:1 57:8 61:42 62:121 63:1763 64:1361 65:112 66:120 91:1 103:1 128:38 129:115 130:20 131:31 132:10 133:3 134:108 135:8 136:16 137:112 138:288 139:54 140:105 141:45 142:56 143:42 144:193 145:9 146:133 147:92 148:122 149:117 150:25 151:334 152:974 153:35 154:12 155:73 156:18 157:106 158:55 159:78 160:16 161:56 162:60 163:131 164:132 165:113 166:173 167:87 168:81 169:31 170:201 171:2 192:5370 193:1841 194:2019 195:793 196:389 198:3711 199:3424 200:1835 202:2425 203:5183 204:3672 205:2450 206:2735 207:2984 208:2934 209:3295 210:394 211:146 212:835 213:308 214:9 215:11 216:2811 217:113 End of report

1 0

The Cidr Report
by Tony Bates 18 Feb '01

18 Feb '01

This is an auto-generated mail on Fri Feb 16 23:00:00 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 16Feb01 0) General Status Table History ------------- Date Prefixes 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 100201 96880 110201 96509 120201 96907 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: 6307 Number of ASes announcing only one prefix: 2489 (0 cidr, 2489 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1648 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1623 1207 416 25.6% Telstra Pty Ltd AS701 1648 1453 195 11.8% UUNET Technologies, Inc. AS271 283 130 153 54.1% University of British Columbia AS8006 146 13 133 91.1% Systems & Software Consortium, In AS7545 196 71 125 63.8% ASNBLK-APNIC-AS-2-BLOCK AS9269 168 46 122 72.6% ASNBLK-APNIC-AS-3-BLOCK AS6429 218 110 108 49.5% RdC Internet AS6595 163 62 101 62.0% DoD Education Activity Network As AS8013 435 338 97 22.3% PSINet Ltd. Canada AS13999 107 10 97 90.7% Mega Cable S.A. de C.V. AS4293 375 282 93 24.8% Cable & Wireless USA AS7496 104 23 81 77.9% ASNBLK-APNIC-AS-2-BLOCK AS4151 251 170 81 32.3% USDA AS705 314 235 79 25.2% UUNET Technologies, Inc. AS4755 206 134 72 35.0% ASN-APNIC-AS-BLOCK-ASNBLOCK AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS7046 325 255 70 21.5% UUNET Technologies, Inc. AS7018 611 541 70 11.5% AT&T AS577 236 167 69 29.2% Bell Advanced Communications Inc. AS174 500 432 68 13.6% PSINet Inc. AS1727 161 93 68 42.2% Commander Naval Surface force US AS9498 88 21 67 76.1% BHARTI BT INTERNET LTD. AS724 219 152 67 30.6% DLA Systems Automation Center AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS3464 153 92 61 39.9% Alabama SuperComputer Network AS226 155 95 60 38.7% Los Nettos AS7657 184 126 58 31.5% ASNBLK-APNIC-AS-2-BLOCK AS3749 115 57 58 50.4% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. 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

2 1

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 17 Feb '01

17 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 1

Weekly Routing Table Report
by Routing Analysis 15 Feb '01

15 Feb '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 16 Feb, 2001 Analysis Summary ---------------- BGP routing table entries examined: 101368 Origin ASes present in the Internet Routing Table: 9972 Origin ASes announcing only one prefix: 3547 Transit ASes present in the Internet Routing Table: 1315 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 18 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 3 Number of addresses announced to Internet: 1226430539 Equivalent to 73 /8s, 25 /16s and 216 /24s Percentage of available address space announced: 33.1 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15764 Prefixes being announced from the APNIC address blocks: 14074 APNIC Region origin ASes present in the Internet Routing Table: 1151 APNIC Region origin ASes announcing only one prefix: 416 APNIC Region transit ASes present in the Internet Routing Table: 189 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 70018996 Equivalent to 4 /8s, 44 /16s and 103 /24s Percentage of available APNIC address space announced: 68.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: 70049 Prefixes being announced from the ARIN address blocks: 47710 ARIN Region origin ASes present in the Internet Routing Table: 6078 ARIN Region origin ASes announcing only one prefix: 1760 ARIN Region transit ASes present in the Internet Routing Table: 626 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 13 Number of ARIN addresses announced to Internet: 177616408 Equivalent to 10 /8s, 150 /16s and 54 /24s Percentage of available ARIN address space announced: 81.4 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 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15537 Prefixes being announced from the RIPE address blocks: 12279 RIPE Region origin ASes present in the Internet Routing Table: 2739 RIPE Region origin ASes announcing only one prefix: 1367 RIPE Region transit ASes present in the Internet Routing Table: 498 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 106915490 Equivalent to 6 /8s, 95 /16s and 102 /24s Percentage of available RIPE address space announced: 91.0 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2423 1190 Telstra 2764 422 139 connect.com.au pty ltd 2907 376 909 SINET Japan 703 370 244 UUNET Technologies, Inc. 4755 303 108 VSNL India 4740 255 16 Ozemail 4618 211 56 Internet Thailand 9269 209 24 Hong Kong CTI 7545 204 7 TPG Internet Pty Ltd 4538 203 973 China Education and Research 7657 203 12 The Internet Group Limited 7474 194 87 Optus Communications 4763 187 43 Telstra New Zealand 4134 173 547 Data Communications Bureau 4766 171 619 KORnet Powered BY Korea Telec 3462 137 205 Data Communications Institute 4786 134 8 NetConnect Communications Pty 7586 132 10 Paradox Digital Pty. Ltd 7539 129 86 Delegated to TWNIC for subseq 7496 128 9 Power Up RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 702 417 606 UUNET Technologies, Inc. 3301 401 322 TeliaNet Sweden 1257 317 240 Swipnet AB 1270 270 433 UUNET Germany 3215 268 183 RAIN 680 200 888 Deutschef Forschurgsnetz 719 191 146 LANLINK 786 184 960 JANET IP Service 5515 168 318 Sonera Finland 3320 167 462 Deutsche Telekom AG 1849 152 271 UUNET UK (formerly PIPEX) 1942 140 53 GIP Renater 517 135 137 Xlink 2856 133 390 BTnet UK Regional network 3303 129 277 Swisscom 5400 111 31 Concert Internet Plus Europea 1901 104 77 EUnet Austria 1267 99 986 IUnet S.p.A 2830 87 30 UUNET UK (formerly PIPEX) 3269 86 275 TELECOM ITALIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2691 3652 UUNET Technologies, Inc. 1 1020 4583 BBN Planet 7018 924 3025 AT&T 7046 742 551 UUNET Technologies, Inc. 705 692 40 UUNET Technologies, Inc. 1239 685 1580 Sprint ICM-Inria 8013 618 71 PSINet Ltd. Canada 2914 613 1272 Verio, Inc. 174 603 2810 PSINet Inc. 3561 570 1299 Cable & Wireless USA 3549 542 506 Frontier GlobalCenter 2551 500 345 NETCOM On-Line Communication 4293 475 58 Cable & Wireless USA 209 463 656 Qwest 271 437 273 BCnet Backbone 2548 395 523 Digital Express Group, Inc. 3908 393 280 Supernet, Inc. 8151 361 193 UniNet S.A. de C.V. 6082 359 63 Management Analysis, Incorpor 11371 324 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2691 3652 UUNET Technologies, Inc. 1221 2423 1190 Telstra 1 1020 4583 BBN Planet 7018 924 3025 AT&T 7046 742 551 UUNET Technologies, Inc. 705 692 40 UUNET Technologies, Inc. 1239 685 1580 Sprint ICM-Inria 8013 618 71 PSINet Ltd. Canada 2914 613 1272 Verio, Inc. 174 603 2810 PSINet Inc. 3561 570 1299 Cable & Wireless USA 3549 542 506 Frontier GlobalCenter 2551 500 345 NETCOM On-Line Communication 4293 475 58 Cable & Wireless USA 209 463 656 Qwest 271 437 273 BCnet Backbone 2764 422 139 connect.com.au pty ltd 702 417 606 UUNET Technologies, Inc. 3301 401 322 TeliaNet Sweden 2548 395 523 Digital Express Group, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 5429 UNALLOCATED 195.178.208.0/21 12690 MKS Autonomous Syste 17408 UNALLOCATED 202.133.224.0/19 3462 Data Communications 17411 UNALLOCATED 202.137.32.0/21 703 UUNET Technologies, 17408 UNALLOCATED 203.163.192.0/19 3462 Data Communications 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, 65400 PRIVATE 213.161.78.0/24 6461 AboveNet Communicati Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 91.16.23.0/24 11770 Net56 103.22.7.0/24 9768 PubNet (Korea Telecom) Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:5 /11:10 /12:32 /13:62 /14:196 /15:308 /16:6865 /17:1047 /18:2047 /19:6352 /20:4667 /21:4339 /22:6531 /23:8537 /24:59027 /25:273 /26:346 /27:149 /28:108 /29:103 /30:203 /31:0 /32:135 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:313 13:10 15:1 17:1 24:661 26:1 32:7 38:8 44:3 53:2 55:1 57:9 61:44 62:121 63:1749 64:1307 65:84 66:118 91:1 103:1 128:42 129:173 130:20 131:31 132:10 133:3 134:104 135:8 136:117 137:144 138:189 139:55 140:110 141:44 142:55 143:39 144:189 145:9 146:133 147:55 148:121 149:117 150:25 151:333 152:973 153:35 154:77 155:73 156:15 157:109 158:56 159:61 160:16 161:56 162:60 163:130 164:131 165:107 166:174 167:87 168:72 169:31 170:203 171:2 192:5403 193:1831 194:2016 195:779 196:391 198:3750 199:3432 200:1817 202:2402 203:5236 204:3728 205:2496 206:2765 207:3071 208:2948 209:3395 210:395 211:141 212:829 213:300 214:7 215:11 216:2731 217:114 End of report

1 0

RE: Migration issues: route creation
by Lu, Ping 15 Feb '01

15 Feb '01

Comment followed. > > You can configure the software to resolve these references internally > (by creating "dummy" objects). However, you cannot request "selective > mirroring" for a particular types of objects. > What happen if you don't want to share some of the person objects ? At least, I believe APNIC has a policy to guard private information so they may not want to mirror the maintainer and person objects. > Referential integrity needs to be satisfied only within a > single source. > That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are > in fact different objects. > How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS ( assigned by ARIN but need to be present in RIPE and APNIC as well ) And this will be a route creation problem, we will need to register some route objects in RIPE that originates from AS3561 very soon. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

PAM2001 registration opens (reminder)
by Henk Uijterwaal (RIPE-NCC) 14 Feb '01

14 Feb '01

---------- Forwarded message ---------- Date: Wed, 3 Jan 2001 14:53:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" <henk(a)ripe.net> To: Undisclosed recipients: ; Subject: PAM2001 registration opens Passive & Active Measurement: PAM-2001 Registration Opens A workshop on passive and active measurement techniques for high speed computer networks and the Internet Amsterdam, the Netherlands, April 23-24, 2001 As the Internet has grown over the last decade the need for precise measurement of network traffic has become steadily more apparent; most of today's Internet Service Providers and many of their large network customers are collecting and analysing traffic data for the purposes of performance monitoring, network engineering and cost recovery, but the engineering quality of these measurements vary. A steadily growing number of research groups have been working in the areas of: - Active Measurements, i.e. sending test packets and observing their progress through the Internet, - Passive Measurements, i.e. observing actual traffic on 'live' networks, - Performance Metrics, i.e. developing measures or indicators which can be used to characterise traffic behavior, - Traffic Statistics, i.e. attempting to understand and develop models of 'real' Internet traffic, and - Visualisation, i.e. finding effective ways to display what's happening in a network. After the successful workshop PAM2000 in Hamilton, New Zealand, in April 2000, the RIPE NCC will be organising another workshop on this topic in Amsterdam in April 2001. Registration for this workshop has now been opened. To register online, go to: http://www.ripe.net/cgi-bin/pamreg Also available on the web-site are the preliminary program: http://www.ripe.net/pam2001/program.html as well as general information on the workshop: http://www.ripe.net/pam2001/ and hotel information: http://www.ripe.net/pam2001/hotels.html Rooms are available at the conference hotel. The rate is 285 Euro/night (including taxes, approximately 255 US$). To reserve a room, call, fax or email the hotel. Contact details can be found on the web page. If you prefer to stay in another hotel, then there are rooms available in all price classes between 35 Euro/night and 1500 Euro/night within a 5 km radius of the conference site. A selection of hotels and links to reservation sites can be found on the webpage. There are still opportunities for participants to present measurement equipment and software. Proposals for demonstrations (about 500 words, plain ASCII) should be sent by email to the conference chair at pam2001(a)ripe.net by 5 March 2001. Contact information: * PAM 2001 c/o RIPE-NCC Singel 258 1016 AB Amsterdam The Netherlands * Phone: +31.20.5354444 * Fax: +31.20.5354445 * Email: pam2001(a)ripe.net * Webpage: http://www.ripe.net/pam2001 ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous)

1 0

RE: Migration issues: route creation
by Lu, Ping 14 Feb '01

14 Feb '01

Further into the subject. About the new RIPE-DB software V3.X, is that a requirement when mirroring we have to import ALL the objects in order to satisfy the database referencial integerity ? For example, when we mirror with RIPE, if the route object point to a mntner object (thru mnt-by ) do we have to have that mntner object imported also ? If the answer is YES then does a mirroring agreement mean we have to share all the objects ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Lu, Ping [mailto:plu@cw.net] > Sent: Monday, February 12, 2001 10:27 PM > To: 'SchmitzJo(a)aol.com'; andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; > db-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Migration issues: route creation > > > I think that's me :) Let's talk about the GLOBAL issues and > the practical > use of RR. > > For all RIRs like RIPE, ARIN, APNIC and so on. They are in a > regulartory > position so they OWN all the objects (AN, PN, MT) and they > seldom need to > CROSS-REFERENCE with other RIRs. So the self-contained assumption (all > references should be resloved locally ) is fine with RIR. > > But for the LIRs (especially the ISPs) RR has a more > practical use, like > auto-generated access-lists and as-path filters. Almost all > the major ISPs > have their own tools or use the public tool like RAToolSet to > pull data from > RR then auto-generate the configiuration for their routers. > > Now here is the fun part. > > As a global player we have to create a list of objects ( AN, > RT ) from all > the RIRs and with any public peer (registered in one of the > RIRs ) we have > to create a list of rather private objects ( MT, PN, RO ). > But it becomes > too difficult to duplicate those private objects with up-to-date > information, so the best way is to REFERENCE their LEGAL > objects in any one > of the RIRs ( of course if the AS itself agree us to do so ). > This is where > the GLOBALLY UNIQUE nic-hdl comes in and in a more generic > sense, how about > GLOBALLY UNIQUE maintainer name ? > > Does this sound like domain name system ? Sooner or later RR > has to face the > GLOBAL issue like DNS, IP address and E-MAIL did. > > We have already seen some of the global issues showed up in > the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? > > Here is my favorite quote from RFC2622 > ----------------------------------------------------- > <nic-handle> is a uniquely assigned identifier word used > by routing, > address allocation, and other registries to > unambiguously refer to > contact information. Person and role classes map NIC handles to > actual person names, and contact information. > ----------------------------------------------------- > > Hmmm! So RPSL already specify the need to use information from OTHER > REGISTRIES. > > I rest my case. > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu(a)cw.net > > > > -----Original Message----- > > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > > Sent: Monday, February 12, 2001 7:32 PM > > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > > routing-wg(a)ripe.net > > Subject: Re: Migration issues: route creation > > > > > > Dear Andrei, > > > > you wrote that there will be problems creating duplicates of > > aut-nums and > > routes in other registries if they do not formally belong > > there due to the > > authorization rules introduced with the RPSL transition at > RIPE. You > > suggested two solutions: > > > > > Possible solutions to this problem are: > > > > > > 1. Send such registration requests to the Database Administration > > > (ripe-dbm) who will perform registration by overriding > > security (and > > > performing necessary checks before). This puts additional load on > > > ripe-dbm and creates duplicate objects in the RIPE database and > > > "foreign" IRR. > > > > > > 2. Do not allow such registrations. In this case some ISPs > > will need to > > > change their peering policy and accept routing information from a > > > "foreign" IRR. > > > > > > Your comments and suggestions are highly appreciated. > > > > > I did not yet see an answer to your question. However, I > > believe that your > > first suggestion should *not* be followed. I definitely would > > want to avoid > > opening "side" paths to enter data into the RIPE database. > > Using ripe-dbm > > should be the exception for special requirements. For > > everything else, the > > robots should be used. > > > > Regarding duplication: this had originally been introduced to > > help people > > along while mirroring was not working. With RIPE having > > transitioned to RPSL, > > we will have compatible formats again, and do not need > > duplication anymore - > > under the prerequisite that you are properly coordinating > > with RADB and any > > other major IRR. I am inclined to say, that avoiding > > duplication is the > > purpose of the effort! > > > > Looking at your second proposal, I believe that you are > > saying the right > > thing, but phrased it a little different. Peering policy is > > probably a term > > which may be confused with routing policy - and nobody needs > > to change its > > routing policy by looking at several IRRs now. Actually, I > > believe that there > > is not much of an issue: Smaller ISPs have always registered > > in only one IRR; > > only bigger providers with international reach have entered > > their information > > into several IRRs and duplicated data, but then also using > > data from all IRRs > > they registered into. It should not be too much of a pain > to use this > > information to continue with this practice after the RPSL > transition. > > > > Those parties who do not agree, speak up loudly now! > > Thanks > > Joachim > > > > --- JS395-RIPE -- standard disclaimer --- > > >

2 1

Re: Migration issues: route creation
by Andrew Hilborne 13 Feb '01

13 Feb '01

"Lu, Ping" <plu(a)cw.net> writes: > ... > We have already seen some of the global issues showed up in the RR domain ( > referral, globally unique nic-hdl ) and there will be more and more > name-collision in the future. > > So why not adopt a naming system like DNS or E-MAIL ? Or SNMP? Andrew Hilborne

1 0

1. draft minutes of joint Routing/DB wg session RIPE38
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-a… ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl(a)ripe.net RIPE-181 updates are still possible and still go to auto-dbm(a)ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm(a)ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf(a)ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001

3 3

RE: Migration issues: route creation
by Lu, Ping 13 Feb '01

13 Feb '01

I think that's me :) Let's talk about the GLOBAL issues and the practical use of RR. For all RIRs like RIPE, ARIN, APNIC and so on. They are in a regulartory position so they OWN all the objects (AN, PN, MT) and they seldom need to CROSS-REFERENCE with other RIRs. So the self-contained assumption (all references should be resloved locally ) is fine with RIR. But for the LIRs (especially the ISPs) RR has a more practical use, like auto-generated access-lists and as-path filters. Almost all the major ISPs have their own tools or use the public tool like RAToolSet to pull data from RR then auto-generate the configiuration for their routers. Now here is the fun part. As a global player we have to create a list of objects ( AN, RT ) from all the RIRs and with any public peer (registered in one of the RIRs ) we have to create a list of rather private objects ( MT, PN, RO ). But it becomes too difficult to duplicate those private objects with up-to-date information, so the best way is to REFERENCE their LEGAL objects in any one of the RIRs ( of course if the AS itself agree us to do so ). This is where the GLOBALLY UNIQUE nic-hdl comes in and in a more generic sense, how about GLOBALLY UNIQUE maintainer name ? Does this sound like domain name system ? Sooner or later RR has to face the GLOBAL issue like DNS, IP address and E-MAIL did. We have already seen some of the global issues showed up in the RR domain ( referral, globally unique nic-hdl ) and there will be more and more name-collision in the future. So why not adopt a naming system like DNS or E-MAIL ? Here is my favorite quote from RFC2622 ----------------------------------------------------- <nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information. ----------------------------------------------------- Hmmm! So RPSL already specify the need to use information from OTHER REGISTRIES. I rest my case. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Monday, February 12, 2001 7:32 PM > To: andrei(a)ripe.net; reimp-mig-tf(a)ripe.net; db-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Migration issues: route creation > > > Dear Andrei, > > you wrote that there will be problems creating duplicates of > aut-nums and > routes in other registries if they do not formally belong > there due to the > authorization rules introduced with the RPSL transition at RIPE. You > suggested two solutions: > > > Possible solutions to this problem are: > > > > 1. Send such registration requests to the Database Administration > > (ripe-dbm) who will perform registration by overriding > security (and > > performing necessary checks before). This puts additional load on > > ripe-dbm and creates duplicate objects in the RIPE database and > > "foreign" IRR. > > > > 2. Do not allow such registrations. In this case some ISPs > will need to > > change their peering policy and accept routing information from a > > "foreign" IRR. > > > > Your comments and suggestions are highly appreciated. > > > I did not yet see an answer to your question. However, I > believe that your > first suggestion should *not* be followed. I definitely would > want to avoid > opening "side" paths to enter data into the RIPE database. > Using ripe-dbm > should be the exception for special requirements. For > everything else, the > robots should be used. > > Regarding duplication: this had originally been introduced to > help people > along while mirroring was not working. With RIPE having > transitioned to RPSL, > we will have compatible formats again, and do not need > duplication anymore - > under the prerequisite that you are properly coordinating > with RADB and any > other major IRR. I am inclined to say, that avoiding > duplication is the > purpose of the effort! > > Looking at your second proposal, I believe that you are > saying the right > thing, but phrased it a little different. Peering policy is > probably a term > which may be confused with routing policy - and nobody needs > to change its > routing policy by looking at several IRRs now. Actually, I > believe that there > is not much of an issue: Smaller ISPs have always registered > in only one IRR; > only bigger providers with international reach have entered > their information > into several IRRs and duplicated data, but then also using > data from all IRRs > they registered into. It should not be too much of a pain to use this > information to continue with this practice after the RPSL transition. > > Those parties who do not agree, speak up loudly now! > Thanks > Joachim > > --- JS395-RIPE -- standard disclaimer --- >

1 0

Re: Migration issues: route creation
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

Dear Andrei, you wrote that there will be problems creating duplicates of aut-nums and routes in other registries if they do not formally belong there due to the authorization rules introduced with the RPSL transition at RIPE. You suggested two solutions: > Possible solutions to this problem are: > > 1. Send such registration requests to the Database Administration > (ripe-dbm) who will perform registration by overriding security (and > performing necessary checks before). This puts additional load on > ripe-dbm and creates duplicate objects in the RIPE database and > "foreign" IRR. > > 2. Do not allow such registrations. In this case some ISPs will need to > change their peering policy and accept routing information from a > "foreign" IRR. > > Your comments and suggestions are highly appreciated. > I did not yet see an answer to your question. However, I believe that your first suggestion should *not* be followed. I definitely would want to avoid opening "side" paths to enter data into the RIPE database. Using ripe-dbm should be the exception for special requirements. For everything else, the robots should be used. Regarding duplication: this had originally been introduced to help people along while mirroring was not working. With RIPE having transitioned to RPSL, we will have compatible formats again, and do not need duplication anymore - under the prerequisite that you are properly coordinating with RADB and any other major IRR. I am inclined to say, that avoiding duplication is the purpose of the effort! Looking at your second proposal, I believe that you are saying the right thing, but phrased it a little different. Peering policy is probably a term which may be confused with routing policy - and nobody needs to change its routing policy by looking at several IRRs now. Actually, I believe that there is not much of an issue: Smaller ISPs have always registered in only one IRR; only bigger providers with international reach have entered their information into several IRRs and duplicated data, but then also using data from all IRRs they registered into. It should not be too much of a pain to use this information to continue with this practice after the RPSL transition. Those parties who do not agree, speak up loudly now! Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

1. draft minutes from the RIPE38 Routing WG session
by SchmitzJo＠aol.com 13 Feb '01

13 Feb '01

R I P E 3 8 A M S T E R D A M Routing Working Group Session 24-Jan-2001 Draft Minutes Chair: Joachim Schmitz (JS395-RIPE) Scribe: Engin Gunduz Participants: 97 A. Preliminaries (Joachim Schmitz) The chair man welcomed the participants, and distributed the participants' list to sign in. Engin Gunduz volunteered to take the minutes. The WG agenda was accepted without changes. The minutes of the previous meeting at RIPE37 were accepted by the participants, and are thus declared final. B. The Hermes Project (Giuseppe di Battista, University of Rome) [ The presentation will become available shortly at the RIPE web server ] URL: http://www.dia.uniroma3.it/~hermes The idea of the Hermes project is the integration and visualisation of Routing Registries Information and BGP Routing Data. Consequently, major targets are to o explore the Internet interactions at AS level o visualise interactive maps o show inconsistencies Hermes is based upon a o 3-tier architecture o repository of routing information o mediator for the information integrity. o graph drawing module After presenting the general outline and functionality, Guiseppe showed a demo prerecorded with a screencam from a life example around AS137. This demo included - peering activities (neighbor ASs, and routes) supplemented with more info from the IRR database - in/out routing policies - paths to another AS with routes from that AS and description from the IRR supplemented by AS macros involvede, plus which ASs are part of them Another demo showed more details around routing policies, where the AS was initially selected by its name in the IRR - showing inconsistencies of registered policies of connected ASs The results can be viewed as text and in a graphical map. Guiseppe continued with more details on the internal structure of how Hermes works. In particular he described - three tier architecture - data integration - mediator for data processing - graph drawing around the difficulties introduced by locally sparse and extremely dense parts requiring complex algorithms Eventually, current and future work was summarized: - moving from RIPE-181 to RPSL format (March 2001) - adding new sources of information (RIS project?) - distinguishing between different sources of information (June 2001) - visualisation and animation of route flaps (June 2001) - looking inside an AS: traceoute (June 2001) - looking inside an AS: OSPF (June 2001) Finally, a brief distinction compared to other similar projects was given: o skitter (Caida) [global view of Internet] o ASExplorer (IPMA) [specific view of one single AS] o Hermes [in between] In the brief following discussion, the impression was that Hermes is a useful tool, comprising information from different sources. Q (chair): It is not entirely obvious which data comes from which source. Is this shown in the tool? A: It should be relatively easy, and is actually planned. Q (Ping Lu): What are the means of output? A: So far, the data can only be printed. Since this is a Java applet, it is difficult to produce output in many formats and save them to local disk As final summary, Guiseppe stressed that he welcomes suggestions like this, and asked for any additional input to be sent to him and his group (contact details on the web page http://www.dia.uniroma3.it/~hermes) C. RIS Report (Henk Uijterwaal, Thomas Franchetti, Antony Antony, RIPE NCC) [ Presentation is online at: http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_HU/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_AA/ http://www.ripe.net/ripencc/pub-services/np/Talks/0101_RIPE38_TF/ ] The RIS group gave three presentations 1. Henk Uijterwaal In the introduction, Henk listed a few administrative items - RIS has progressed that for that it will be turned into a regular operational service very soon - To support this move, they are now hiring a 2nd network engineer which will bring the headcount to 2.5 FTE's plus 1 student (from 1-Apr on) - Henk again announced the PAM-2001 workshop Then, a sumamry of the highlights in the past months was given - a new database was introduced to keep up with performance requirements - more powerful hardware was installed, and a scaling analysis will be done with it - currently there are 4 Remote Route Collectors (RRC) at RIPE NCC, LINX, AMS-IX, SFINX; anybody interested in peering to put data into RIS is welcome to contact Antony Antony - two more RRCs are planned, investigating where to place them - work has been done on the user interface, with output on: web, email - vanilla, strawberry, chocolate: which view of the routes do we have in the RIS? The flavors distinguish different amounts of routing info, ranging from filtered and restricted output (vanilla) to the full set of routes (chocolate); RIS prefers to see more - following several requests from different sources (ISMA project, Hermes, ASExplorer,...), the raw data is now available (announced yesterday), check out URL http://abcoude.ripe.net/ris/rawdata During the next months the RIS team plans to - move to production during 2001 - proceed with route collection and expand it - improve and extend the user interface - proceed with network research Henk stressed again that he very much welcomes welcomes input from the community on this project. Joachim reminded Henk of the action, the Routing WG has put on the RIS team, to also implement route flap statistics. Henk confirmed that this is on the list of topics to analyse. 2. Thomas Franchetti In the second part, Thomas presented some results from data collected by RIS - statistics of numbers of prefixes by length show a noticable increase of /24, and /32 - origin ASs announcing only one prefix - distribution of prefix lengths again shows the increase of /24, and /32 - statistics of how many ASs announce certain number of prefixes most ASs announce only very few prefixes, number of announcements per AS is on average decreasing The graphs shown will be made available on the web before RIPE39. Conclusion: - it is necessary to view larger periods to see trends more clearly. - there is a lot of data in RIS, and lots of potential ways to analyze it, but not easy to find ways of presentation; this definitely needs to be explored Joachim finds the parallels interesting between the RIS project results, and other analysis like the one by Philip Smith (distributed on the Routing WG mailing list), or the "standard" CIDR report by Tony Bates. Joachim is eager to see more results at RIPE39, and also welcomes any input from the community; after all these stats are just a glimpse at the wealth of data collected at RIS. 3. Antony Antony In the third part of the presentations on RIS, Antony presented some peculiar RIS observations: - regarding negligence in aggregation, it is amazing how big a number of more specifics is announced from small prefixes (up to several 1000s in a /8) - looking at AS path length, a path with 123 ASs was found, which is very peculiar; this causes several problems, e.g. Cisco actually resets because of missing buffer space; there is also a known Cisco bug where an empty AS path may appear, and thus care must be taken if filtering on AS path length - if AS numbers are considered as such, roughly 82% of RIPE NCC assigned AS numbers are visible by RIS, and the question arises: where are the others? Actually, the RIPE region is still in pretty good shape because the global average is 50%. Following up on this, Daniel Karrenberg added some observations and comments. He noted that the full feed they get from a neighbor consists of 81,272 prefixes, but the maximum number of prefixes from a peer is 100,461. In the beginning, the difference between the extremes was just a couple of thousands, but obviously has expanded tremendously. As Randy Bush has pointed out during the EOF session, it is possible to go down to around 80k prefixes without loosing connectivity. Possibly, people announce redundant data. RIS may be used to catch the source of those redundant data. Daniel was musing whether the NCC should suggest filter lists but would want more discussion on that. D. Routing Registry Consistency Checking (Shane Kerr, RIPE NCC) [ The presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/rrcc-ripe38… dex.html ] Shane reports that the RIPE IRR currently holds around 24k route objects and 4k AS objects. The quality of the contents varies widely, because there are people who really update their objects, and others who don't. To improve data quality, the data in the IRR is compared to what is found on the Internet. However, the goal is not just reporting, but help to improve the IRR and make it more useful. This is the idea behind the Routing Registry Consistency Checking (R2C2). The following slides gave an overview of the approach, the status, progress, and the plans of the project. Besides route objects and AS objects (routing policies), there are also supporting objects like AS macros which form a set of data to be compared to RIS data. Several reports and tools are in the make, like - summary report - specific report - router configuration checker - IRR correction wizard The project has reached a status where comparisons are possible, and mismatches may be identified. Prototype interfaces and a prototype correction wizard are available. A web page for the project exists with a practical example of the prototype interface. The next steps include polishing and finishing current software, publishing a summary of the project as RIPE-201 document, and seeking community input. Potential possible directions include - a view from specific route collector on request - checking aut-num policy with AS paths - a router configuration verification Additional suggestions include working together with other IRRs and on request from the community develop further applications. This was the last topic in the Routing WG session itself. The second slot was dedicated to a joint session of the Routing and Database WGs dealing with RPSL transition issues. Y. Input from other WGs There was no input from other WGs. Z. AOB There was no other business. Summary of Open Action Points from the Routing WG 36.R1 on RIPE NCC During the transition phase to the RPSL software - verify with RADB on their test suites for RPSL implementations - coordinate with RADB on consistent mirroring of databases (NRTM) - coordinate with RADB on consistent whois interface of databases including irrd status: ongoing 37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz Provide updates to RIPE-210 - general editing, review - explanation of damping parameters - examples by implementation - script to determine TLD/root nameservers for "golden network" list status: ongoing 37.R2 on RIS team, Henk Uijterwaal Implement route flap analysis from RIS data status: ongoing Engin Gunduz, Joachim Schmitz, February 2001

1 0

Re: The Cidr Report
by SchmitzJo＠aol.com 12 Feb '01

12 Feb '01

Dear Tony, you wrote: > [...] > 2) It seems folks don't use it as much as they can as I see very little > positive changes anymore. > > However, having said this I would like to understand from folks (reply > directly) if you think I should continue to generate this. > [...] > However, it is > worth having a quick look for config errors and would encourage providers > to do this periodically. > Well, I do include the mailing lists on purpose in my answer... I very much support that you continue to generate the CIDR reports, and distribute them. The reasons are manifold, and go far beyond sentimental feelings about one of the institutional reports on the Internet. Why did we start this in the first place? To put up a flag against exponential routing table growth. And it worked - growth was down to roughly linear for quite some time. However, newer analysis e.g. by Philip Smith or recently by the new RIS project at the RIPE NCC shows that the Internet has again embarked on exponential growth of the routing table (e.g. I still doubt that several *thousand* longer prefixes announced from one /8 make a lot of sense, or the tremendous increase of longer prefixes than /24). Today, the worries are most likely not that much CPU and memory problems of the routers any more, but convergence and stability of BGP tables. Craig Labovitz, Abha Ahuja, et al. show results from their work which are not exactly reassuring... Anybody may improve the situation e.g. by proper filtering (very efficient as proven e.g. by Randy Bush), or correct route flap damping (yes, RIPE-210 needs a brush up badly - it is on our action list). As important as this is: it only helps on symptoms generated by others on the Internet: too many unnecessary routes. I am convinced that it is ever more important today to have a close look at the status of the Internet routing table, and where it may be improved - and your CIDR report is one keystone in it. Thanks a lot for generating these reports during the past years, and please continue to generate them. A review of the prerequisites as you outlined in the first part of your mail does not change anything in the basic statement of the report. Thanks Joachim (chairman RIPE Routing WG) --- JS395-RIPE -- standard disclaimer ---

1 0

The Cidr Report
by Tony Bates 12 Feb '01

12 Feb '01

This is an auto-generated mail on Sun Feb 11 20:37:22 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 11Feb01 0) General Status Table History ------------- Date Prefixes 040201 96815 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 100201 96880 110201 96509 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 103.22.7.0/24 from AS9768 AS Summary ---------- Number of ASes in routing system: 9849 Number of ASes announcing only one prefix: 5760 (3266 cidr, 2494 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1642 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1623 1207 416 25.6% Telstra Pty Ltd AS701 1642 1451 191 11.6% UUNET Technologies, Inc. AS271 280 132 148 52.9% University of British Columbia AS7545 196 71 125 63.8% ASNBLK-APNIC-AS-2-BLOCK AS9269 162 46 116 71.6% ASNBLK-APNIC-AS-3-BLOCK AS6429 221 108 113 51.1% RdC Internet AS6595 163 62 101 62.0% DoD Education Activity Network As AS8013 434 336 98 22.6% PSINet Ltd. Canada AS13999 107 10 97 90.7% Mega Cable S.A. de C.V. AS4293 374 281 93 24.9% Cable & Wireless USA AS7496 104 23 81 77.9% ASNBLK-APNIC-AS-2-BLOCK AS4151 250 169 81 32.4% USDA AS705 312 234 78 25.0% UUNET Technologies, Inc. AS4755 209 137 72 34.4% Videsh Sanchar Nigam Ltd. Autonom AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS7018 615 544 71 11.5% AT&T AS7046 325 255 70 21.5% UUNET Technologies, Inc. AS577 236 167 69 29.2% Bell Advanced Communications Inc. AS174 499 431 68 13.6% PSINet Inc. AS1727 162 94 68 42.0% Commander Naval Surface force US AS9498 88 21 67 76.1% BHARTI BT INTERNET LTD. AS724 219 152 67 30.6% DLA Systems Automation Center AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 185 125 60 32.4% ASNBLK-APNIC-AS-2-BLOCK AS226 155 95 60 38.7% Los Nettos AS3749 115 57 58 50.4% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 131 75 56 42.7% Reseau Interordinateurs Scientiqu 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 1

The Cidr Report
by Tony Bates 09 Feb '01

09 Feb '01

This is an auto-generated mail on Fri Feb 9 12:00:00 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 09Feb01 0) General Status Table History ------------- Date Prefixes 020201 96787 030201 96701 040201 96815 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 103.22.7.0/24 from AS9768 AS Summary ---------- Number of ASes in routing system: 9841 Number of ASes announcing only one prefix: 5753 (3257 cidr, 2496 classful) Largest number of cidr routes: 954 announced by AS701 Largest number of classful routes: 1649 announced by AS701 1) Gains by aggregating at the origin AS level --- 09Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description 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 08 Feb '01

08 Feb '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 09 Feb, 2001 Analysis Summary ---------------- BGP routing table entries examined: 100689 Origin ASes present in the Internet Routing Table: 9892 Origin ASes announcing only one prefix: 3524 Transit ASes present in the Internet Routing Table: 1324 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 15 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 4 Number of addresses announced to Internet: 1207529448 Equivalent to 71 /8s, 249 /16s and 111 /24s Percentage of available address space announced: 32.6 Percentage of allocated address space announced: 63.9 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15740 Prefixes being announced from the APNIC address blocks: 14063 APNIC Region origin ASes present in the Internet Routing Table: 1147 APNIC Region origin ASes announcing only one prefix: 413 APNIC Region transit ASes present in the Internet Routing Table: 190 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 13 Number of APNIC addresses announced to Internet: 69686953 Equivalent to 4 /8s, 39 /16s and 86 /24s Percentage of available APNIC address space announced: 68.5 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: 69573 Prefixes being announced from the ARIN address blocks: 47249 ARIN Region origin ASes present in the Internet Routing Table: 6028 ARIN Region origin ASes announcing only one prefix: 1756 ARIN Region transit ASes present in the Internet Routing Table: 632 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 14 Number of ARIN addresses announced to Internet: 176439809 Equivalent to 10 /8s, 132 /16s and 66 /24s Percentage of available ARIN address space announced: 80.9 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 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15361 Prefixes being announced from the RIPE address blocks: 12117 RIPE Region origin ASes present in the Internet Routing Table: 2715 RIPE Region origin ASes announcing only one prefix: 1353 RIPE Region transit ASes present in the Internet Routing Table: 501 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 89815660 Equivalent to 5 /8s, 90 /16s and 122 /24s Percentage of available RIPE address space announced: 76.5 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2446 1198 Telstra 2764 438 140 connect.com.au pty ltd 703 367 248 UUNET Technologies, Inc. 2907 366 892 SINET Japan 4755 311 112 VSNL India 4740 257 16 Ozemail 7657 215 12 The Internet Group Limited 9269 209 24 Hong Kong CTI 4618 207 56 Internet Thailand 7545 205 7 TPG Internet Pty Ltd 4538 199 972 China Education and Research 4763 190 43 Telstra New Zealand 7474 189 87 Optus Communications 4766 171 619 KORnet Powered BY Korea Telec 4134 169 523 Data Communications Bureau 3462 136 205 Data Communications Institute 7586 135 10 Paradox Digital Pty. Ltd 7539 129 83 Delegated to TWNIC for subseq 4786 128 7 NetConnect Communications Pty 7496 124 9 Power Up RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 391 314 TeliaNet Sweden 702 380 588 UUNET Technologies, Inc. 1257 320 240 Swipnet AB 1270 270 433 UUNET Germany 3215 207 182 RAIN 680 194 856 Deutschef Forschurgsnetz 719 191 146 LANLINK 786 184 960 JANET IP Service 5515 172 326 Sonera Finland 3320 167 462 Deutsche Telekom AG 1849 152 271 UUNET UK (formerly PIPEX) 1942 140 53 GIP Renater 2856 140 394 BTnet UK Regional network 517 134 137 Xlink 3303 128 277 Swisscom 5400 109 31 Concert Internet Plus Europea 1901 104 77 EUnet Austria 1267 98 986 IUnet S.p.A 2830 85 30 UUNET UK (formerly PIPEX) 3269 85 267 TELECOM ITALIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2640 3588 UUNET Technologies, Inc. 1 996 4572 BBN Planet 7018 911 3020 AT&T 7046 735 551 UUNET Technologies, Inc. 1239 697 1580 Sprint ICM-Inria 705 635 39 UUNET Technologies, Inc. 2914 611 1272 Verio, Inc. 174 594 2794 PSINet Inc. 3561 569 1307 Cable & Wireless USA 3549 537 442 Frontier GlobalCenter 8013 521 68 PSINet Ltd. Canada 2551 502 345 NETCOM On-Line Communication 4293 473 58 Cable & Wireless USA 209 438 650 Qwest 2548 398 523 Digital Express Group, Inc. 3908 392 280 Supernet, Inc. 6082 358 63 Management Analysis, Incorpor 8151 358 192 UniNet S.A. de C.V. 271 349 269 BCnet Backbone 11371 324 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2640 3588 UUNET Technologies, Inc. 1221 2446 1198 Telstra 1 996 4572 BBN Planet 7018 911 3020 AT&T 7046 735 551 UUNET Technologies, Inc. 1239 697 1580 Sprint ICM-Inria 705 635 39 UUNET Technologies, Inc. 2914 611 1272 Verio, Inc. 174 594 2794 PSINet Inc. 3561 569 1307 Cable & Wireless USA 3549 537 442 Frontier GlobalCenter 8013 521 68 PSINet Ltd. Canada 2551 502 345 NETCOM On-Line Communication 4293 473 58 Cable & Wireless USA 209 438 650 Qwest 2764 438 140 connect.com.au pty ltd 2548 398 523 Digital Express Group, Inc. 3908 392 280 Supernet, Inc. 3301 391 314 TeliaNet Sweden 702 380 588 UUNET Technologies, Inc. List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 61512 RESERVED 170.224.16.0/20 17232 Enhanced Network Ser 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 17411 UNALLOCATED 202.137.32.0/21 703 UUNET Technologies, 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 50.198.0.0/16 2548 Digital Express Group, Inc. 91.16.23.0/24 11770 Net56 103.22.7.0/24 9768 PubNet (Korea Telecom) Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:4 /10:5 /11:10 /12:32 /13:61 /14:195 /15:307 /16:6859 /17:1040 /18:2041 /19:6339 /20:4637 /21:4310 /22:6515 /23:8469 /24:58457 /25:277 /26:349 /27:132 /28:101 /29:105 /30:291 /31:0 /32:132 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:310 13:10 15:1 24:648 26:1 32:6 38:9 44:3 53:2 55:1 57:9 61:41 62:112 63:1677 64:1263 65:54 66:112 91:1 103:1 128:33 129:233 130:20 131:31 132:10 133:4 134:104 135:8 136:121 137:145 138:192 139:53 140:110 141:43 142:56 143:38 144:188 145:7 146:133 147:54 148:119 149:116 150:24 151:330 152:969 153:35 154:76 155:71 156:15 157:106 158:56 159:60 160:16 161:57 162:60 163:130 164:108 165:102 166:174 167:83 168:74 169:30 170:203 171:2 192:5413 193:1819 194:1996 195:773 196:394 198:3758 199:3459 200:1821 202:2427 203:5259 204:3552 205:2455 206:2799 207:2948 208:2925 209:3374 210:387 211:135 212:800 213:297 214:9 215:11 216:2678 217:105 End of report

1 0

Migration issues: route creation
by Andrei Robachevsky 05 Feb '01

05 Feb '01

Dear Colleagues, You may know that the new version of the RIPE database (v3.0) also supports Routing Policy Security System (RFC2725). One of the implications is that this may prevent registrations of "foreign" routes in the RIPE IRR (that is routes from non RIPE address space and/or non RIPE ASN). According to RFC2725, creation of a route object should be authorized by the "owner" of the respective address space or aggregate route and by the "owner" of the ASN that is specified as route origin. In case of absence of the corresponding objects, creation of the route object will fail. The creation of the corresponding "foreign" objects will not be as easy in the new version as it is in the current one. The ASN space will be protected by as-block object, and IP address space by corresponding top level inetnum object. This makes registration of "foreign" routes almost impossible, which affects current practice when an IPS requests that clients' routes should be registered in the RIPE IRR. Possible solutions to this problem are: 1. Send such registration requests to the Database Administration (ripe-dbm) who will perform registration by overriding security (and performing necessary checks before). This puts additional load on ripe-dbm and creates duplicate objects in the RIPE database and "foreign" IRR. 2. Do not allow such registrations. In this case some ISPs will need to change their peering policy and accept routing information from a "foreign" IRR. Your comments and suggestions are highly appreciated. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

The Cidr Report
by Tony Bates 02 Feb '01

02 Feb '01

This is an auto-generated mail on Fri Feb 2 12:00:00 PST 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 02Feb01 0) General Status Table History ------------- Date Prefixes 260101 96902 270101 96353 280101 96304 290101 96277 300101 96520 310101 96571 010201 96527 020201 96787 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 9790 Number of ASes announcing only one prefix: 5718 (3222 cidr, 2496 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1658 announced by AS701 1) Gains by aggregating at the origin AS level --- 02Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description 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 01 Feb '01

01 Feb '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 02 Feb, 2001 Analysis Summary ---------------- BGP routing table entries examined: 100908 Origin ASes present in the Internet Routing Table: 9827 Origin ASes announcing only one prefix: 3489 Transit ASes present in the Internet Routing Table: 1316 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 18 Illegal AS announcements present in the Routing Table: 17 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 2 Number of addresses announced to Internet: 1202892915 Equivalent to 71 /8s, 178 /16s and 176 /24s Percentage of available address space announced: 32.5 Percentage of allocated address space announced: 63.6 Percentage of available address space allocated: 51.0 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 15560 Prefixes being announced from the APNIC address blocks: 13998 APNIC Region origin ASes present in the Internet Routing Table: 1142 APNIC Region origin ASes announcing only one prefix: 406 APNIC Region transit ASes present in the Internet Routing Table: 187 Average APNIC Region AS path length visible: 5.0 Max APNIC Region AS path length visible: 12 Number of APNIC addresses announced to Internet: 65649152 Equivalent to 3 /8s, 233 /16s and 186 /24s Percentage of available APNIC address space announced: 64.5 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: 69861 Prefixes being announced from the ARIN address blocks: 47377 ARIN Region origin ASes present in the Internet Routing Table: 5985 ARIN Region origin ASes announcing only one prefix: 1732 ARIN Region transit ASes present in the Internet Routing Table: 628 Average ARIN Region AS path length visible: 5.2 Max ARIN Region AS path length visible: 13 Number of ARIN addresses announced to Internet: 175815311 Equivalent to 10 /8s, 122 /16s and 186 /24s Percentage of available ARIN address space announced: 80.6 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 ARIN Address Blocks 63/8, 64/7, 66/8, 199/8, 200/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 15470 Prefixes being announced from the RIPE address blocks: 12207 RIPE Region origin ASes present in the Internet Routing Table: 2698 RIPE Region origin ASes announcing only one prefix: 1349 RIPE Region transit ASes present in the Internet Routing Table: 499 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 89469667 Equivalent to 5 /8s, 85 /16s and 50 /24s Percentage of available RIPE address space announced: 76.2 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /19 equiv Description 1221 2384 1189 Telstra 2764 436 139 connect.com.au pty ltd 703 416 250 UUNET Technologies, Inc. 2907 366 892 SINET Japan 4755 312 110 VSNL India 7657 217 12 The Internet Group Limited 9269 209 24 Hong Kong CTI 4618 207 56 Internet Thailand 4740 207 13 Ozemail 7545 205 7 TPG Internet Pty Ltd 7474 191 90 Optus Communications 4763 190 43 Telstra New Zealand 4766 175 619 KORnet Powered BY Korea Telec 4134 169 523 Data Communications Bureau 7586 135 10 Paradox Digital Pty. Ltd 3462 131 181 Data Communications Institute 4786 129 7 NetConnect Communications Pty 7496 124 9 Power Up 7617 122 46 One.Net Pty Ltd 9797 122 10 Asia Online Australia RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 392 306 TeliaNet Sweden 702 367 490 UUNET Technologies, Inc. 1270 333 432 UUNET Germany 1257 314 240 Swipnet AB 3215 204 180 RAIN 719 193 146 LANLINK 5515 193 359 Sonera Finland 680 188 864 Deutschef Forschurgsnetz 786 184 960 JANET IP Service 3320 166 462 Deutsche Telekom AG 1849 162 280 UUNET UK (formerly PIPEX) 1942 140 53 GIP Renater 2856 138 394 BTnet UK Regional network 517 134 137 Xlink 3303 128 277 Swisscom 5400 110 32 Concert Internet Plus Europea 1901 103 77 EUnet Austria 1267 98 986 IUnet S.p.A 3259 95 88 UUNET FRANCE 2830 83 30 UUNET UK (formerly PIPEX) ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 701 2608 3599 UUNET Technologies, Inc. 1 1009 4612 BBN Planet 7018 913 3017 AT&T 7046 730 542 UUNET Technologies, Inc. 1239 695 1589 Sprint ICM-Inria 2914 614 1289 Verio, Inc. 174 597 2806 PSINet Inc. 705 597 37 UUNET Technologies, Inc. 3561 565 1306 Cable & Wireless USA 2548 543 523 Digital Express Group, Inc. 3549 537 441 Frontier GlobalCenter 8013 523 64 PSINet Ltd. Canada 2551 504 345 NETCOM On-Line Communication 4293 449 57 Cable & Wireless USA 209 433 633 Qwest 271 424 271 BCnet Backbone 3908 386 280 Supernet, Inc. 6082 359 63 Management Analysis, Incorpor 8151 357 192 UniNet S.A. de C.V. 11371 324 49 Rhythms NetConnections Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2608 3599 UUNET Technologies, Inc. 1221 2384 1189 Telstra 1 1009 4612 BBN Planet 7018 913 3017 AT&T 7046 730 542 UUNET Technologies, Inc. 1239 695 1589 Sprint ICM-Inria 2914 614 1289 Verio, Inc. 174 597 2806 PSINet Inc. 705 597 37 UUNET Technologies, Inc. 3561 565 1306 Cable & Wireless USA 2548 543 523 Digital Express Group, Inc. 3549 537 441 Frontier GlobalCenter 8013 523 64 PSINet Ltd. Canada 2551 504 345 NETCOM On-Line Communication 4293 449 57 Cable & Wireless USA 2764 436 139 connect.com.au pty ltd 209 433 633 Qwest 271 424 271 BCnet Backbone 703 416 250 UUNET Technologies, Inc. 3301 392 306 TeliaNet Sweden List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65535 PRIVATE 63.140.210.0/23 5696 WINSTAR 65535 PRIVATE 63.140.240.0/24 5696 WINSTAR 65535 PRIVATE 63.140.241.0/24 5696 WINSTAR 2027 UNALLOCATED 150.185.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.185.128.0/18 8143 Publicom Corp. 2027 UNALLOCATED 150.186.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.187.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.188.0.0/16 10530 Interpacket Group, I 2027 UNALLOCATED 150.189.0.0/16 10530 Interpacket Group, I 1877 UNALLOCATED 192.108.196.0/24 1800 SPRINT 1877 UNALLOCATED 192.108.209.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.210.0/24 1880 Stupi, house man's 1877 UNALLOCATED 192.108.214.0/24 1800 SPRINT 5757 UNALLOCATED 192.239.13.0/24 701 UUNET Technologies, 17411 UNALLOCATED 202.137.32.0/21 703 UUNET Technologies, 65500 PRIVATE 203.166.86.0/24 10084 Western Australian I 5757 UNALLOCATED 207.19.224.0/24 701 UUNET Technologies, Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 39.96.40.224/30 14408 iCAIR 91.16.23.0/24 11770 Net56 Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:4 /10:5 /11:10 /12:32 /13:61 /14:196 /15:306 /16:6807 /17:1025 /18:2025 /19:6319 /20:4543 /21:4291 /22:6497 /23:8428 /24:58495 /25:297 /26:399 /27:230 /28:220 /29:154 /30:321 /31:1 /32:221 Number of /24s announced per /8 block (Global) ---------------------------------------------- 9:3 12:302 15:1 24:625 26:1 32:6 38:9 44:2 53:2 55:1 57:9 61:60 62:126 63:1637 64:1200 65:43 66:111 91:1 128:33 129:231 130:20 131:31 132:9 133:4 134:104 135:8 136:123 137:144 138:189 139:51 140:102 141:138 142:58 143:38 144:126 145:11 146:132 147:90 148:120 149:115 150:23 151:331 152:959 153:62 154:76 155:71 156:15 157:108 158:56 159:56 160:18 161:57 162:61 163:125 164:105 165:101 166:174 167:82 168:69 169:30 170:207 171:2 192:5419 193:1822 194:2013 195:756 196:394 198:3749 199:3419 200:1810 202:2448 203:5211 204:3572 205:2461 206:2817 207:2997 208:2881 209:3419 210:382 211:136 212:817 213:305 214:8 215:11 216:2747 217:97 End of report

1 0