- Test - lists.nanog.org

Re: private ip addresses from ISP
by Joe Maimon 23 May '06

23 May '06

Robert Bonomi wrote: >>Date: Tue, 23 May 2006 11:14:53 -0400 > > "Translating" those addresses is a *BAD*IDEA*(TM). That obscures who > the reporting machine was _if_ you have to actually communicate with that > network operator. > These are the options: Construct the network so that icmp is never sourced from rfc1918 OR Do either of below: Filter icmp sourced from rfc1918 on egress Dont filter icmp sourced from rfc1918 on egress Translate icmp sourced from rfc1918 on egress Use some feature that translates/replaces rfc1918 sourced icmp with nonrfc1918 identifiable internally. > This is exactly why RFC1918 says that private-addrss source packets _should_ > _not_ be passed across enterprise boundaries. It does _not_ say 'must not', > because there *are* situations where it is necessary. This _is_ one of them. :) You are in favor of: Dont filter icmp sourced from rfc1918 on egress However that leads to a significant hole in "anti spoofing defense sheild" of the net. So it becomes difficult to be in favor of this and also claim that liberal application of anti-spoofing/urpf will solve most of the abuses which depend on spoofing to be effective. > > >>Understandably, translation on providers networks is not always feasible. >> >>A feature on routers that sourced icmp packets to be told specificaly >>which address of the router to source it from would also help. > > > When the router has only RFC1918 addresses (totally internal to the network), > it doesn't matter/help. In this instance they would assign a single or more address nonrfc1918 to leverage this feature. > > Also, the address to use as the source _is_ well-defined. it is the interface > the packet came in on that triggered the ICMP message. The proposed feature would make it configurable, perhaps on a per interface basis. The provider would keep an internal database. It need not even be routed. It would be nice if this was completely an icmp packet field value and not dependant on the ip header to identify the icmp generator.

1 0

Re: private ip addresses from ISP
by Robert Bonomi 23 May '06

23 May '06

> Date: Tue, 23 May 2006 03:33:34 -0400 > From: Richard A Steenbergen <ras(a)e-gerbil.net> > To: nanog(a)nanog.org > Subject: Re: private ip addresses from ISP > > > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote: > > > > > 3) You are seeing packets with source IPs inside private space > > > arriving at > > > your interface from your ISP? > ... > > Sorry to dig this up from last week but I have to strongly disagree with > > point #3. > > >From RFC 1918 > > Because private addresses have no global meaning, routing information > > about private networks shall not be propagated on inter-enterprise > > links, and packets with private source or destination addresses > > should not be forwarded across such links. Routers in networks not > > using private address space, especially those of Internet service > > providers, are expected to be configured to reject (filter out) > > routing information about private networks. > > > > The ISP shouldn't be "leaving" anything to the end-user, these packets > > should be dropped as a matter of course, along with any routing > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space > > into my network piss me off, and get irate phone calls for their > > trouble. > > The section you quoted from RFC1918 specifically addresses routes, not > packets. I quote, from the material cited above: " ..., and packets with private source or destination addresses should not be forwarded across such links. ... " There are some types of packets that can legitimately have RFC1918 source addresses -- 'TTL exceeded' for example -- that one should legitimately allow across network boundaries. > If you're receiving RFC1918 *routes* from anyone, you need to > thwack them over the head with a cluebat a couple of times until the cluey > filling oozes out. If you're receiving RFC1918 sourced packets, for the > most part you really shouldn't care. *I* care. When those packets contain 'malicious' content, for example. When the provider =cannot= tell me which of _their_own_customers_ originated that attack, for example. (This provider has inbound source-filtering on their Internet 'gateway' routers, but *not* on their customer-facing equipment (either inbound or outbound.) It's even more comical when the NSP uses RFC1918 space internally, and does *not* filter those source addresses from their customers. > There are semi-legitimate reasons for > packets with those sources addresses to float around the Internet, and > they don't hurt anything. I guess you don't mind paying for transit of packets that _cannot_possibly_ have any legitimate purpose on your network. Some of us, on the other hand, _do_ object. YMMV

3 2

RE: private ip addresses from ISP
by Andrew Kirch 23 May '06

23 May '06

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Robert Bonomi > Sent: Tuesday, May 23, 2006 9:22 AM > To: nanog(a)nanog.org > Cc: davids(a)webmaster.com > Subject: Re: private ip addresses from ISP > > > > Date: Tue, 23 May 2006 03:33:34 -0400 > > From: Richard A Steenbergen <ras(a)e-gerbil.net> > > To: nanog(a)nanog.org > > Subject: Re: private ip addresses from ISP > > > > > > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch wrote: > > > > > > > 3) You are seeing packets with source IPs inside private space > > > > arriving at > > > > your interface from your ISP? > > ... > > > Sorry to dig this up from last week but I have to strongly disagree > with > > > point #3. > > > >From RFC 1918 > > > Because private addresses have no global meaning, routing > information > > > about private networks shall not be propagated on inter-enterprise > > > links, and packets with private source or destination addresses > > > should not be forwarded across such links. Routers in networks not > > > using private address space, especially those of Internet service > > > providers, are expected to be configured to reject (filter out) > > > routing information about private networks. > > > > > > The ISP shouldn't be "leaving" anything to the end-user, these packets > > > should be dropped as a matter of course, along with any routing > > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space > > > into my network piss me off, and get irate phone calls for their > > > trouble. > > > > The section you quoted from RFC1918 specifically addresses routes, not > > packets. > > I quote, from the material cited above: > " ..., and packets with private source or destination addresses > should not be forwarded across such links. ... " > > There are some types of packets that can legitimately have RFC1918 source > addresses -- 'TTL exceeded' for example -- that one should legitimately > allow across network boundaries. > > If you're receiving RFC1918 *routes* from anyone, you need to > > thwack them over the head with a cluebat a couple of times until the > cluey > > filling oozes out. If you're receiving RFC1918 sourced packets, for the > > most part you really shouldn't care. > > *I* care. > > When those packets contain 'malicious' content, for example. > > When the provider =cannot= tell me which of _their_own_customers_ > originated > that attack, for example. (This provider has inbound source-filtering on > their Internet 'gateway' routers, but *not* on their customer-facing > equipment > (either inbound or outbound.) > > It's even more comical when the NSP uses RFC1918 space internally, and > does > *not* filter those source addresses from their customers. > > > There are semi-legitimate reasons > for > > packets with those sources addresses to float around the Internet, and > > they don't hurt anything. > > I guess you don't mind paying for transit of packets that > _cannot_possibly_ > have any legitimate purpose on your network. > > Some of us, on the other hand, _do_ object. > > YMMV > Well said, I think that Robert has done a phenomenal job of summing up my point. I don't want this trash on my network. The pertinent RFC says it shouldn't be entering my network from *your* network (for varying values of your). I don't buy the argue that the end user should decide what traffic they do and don't want when the RFC states unequivocally that the traffic shouldn't be there. Even reasonably large networks are often run by people with no appreciable networking experience, MCSE, MCP MCP+I etc. This is a simple fact of life. Andrew

1 0

AS9132 filtering my traffic (41.220.0.0/20)
by Richard Mikisa 22 May '06

22 May '06

Hi all, Anyone from AS9132 - Broadnet mediascape communications AG, Hamburg on this list? Please get back offline. Seems like you are blocking all traffic from 41.220.0.0/20 - AS29032. All attempts for help via email and phone have failed. -- Richard

1 0

snfc21 sniffer docs
by John Kinsella 22 May '06

22 May '06

Wired posted what are suppossedly the docs Mark Klein wrote 'bout the NSA sniffing project. Interesting read... http://blog.wired.com/27BStroke6/att_klein_wired.pdf John

1 0

RFC: public efforts in the botnets realm
by Gadi Evron 22 May '06

22 May '06

Hi, this is an FYI. A discussion will now commense on the DA list to try and measure if public efforts are indeed a good idea, and how much good vs. bad they cause in the fight against botnets, distributed denial of service attacks, Internet survivability and online crime, as it can indeed be measured. I would also like the community's opinion on the subject at hand, so that we can relay it and make a more client-oriented decision (take the needs of the community into consideration as well). Thanks, Gadi. ---------- Forwarded message ---------- Date: Mon, 22 May 2006 02:02:48 -0500 (CDT) From: Gadi Evron <ge(a)linuxbox.org> To: <closed botnets list> Subject: public efforts Hi guys. our public efforts in the botnet realm thus far consist of *mainly*: 1. The monthly C&C report. 2. Public botnet reporting to us. 3. Public discussion list. The monthly report is now largely accepted by most in the net-ops community as reliable, and it meets the test of scrutiny. We had some early bumps on how we represent data, what data we want to show and what information we want to deduce from it - but I think we are there now. Public botnet reporting to us is going great. I stopped relaying them to the list is it is extremely time consuming for me, but they are dealt with. As soon as a volunteer who doesn't just want to talk to the press and take them off my back but also do this work comes along, we will get these again here too. The public discussion list has in my opinion brought an immense public awareness, law enforcement interest and industry work. Little to no new information was divulged there that the Bad Guys would not already know with their gigs of bot sources and exchange networks (not to mention support web forums). That's just my opinion, feel free to chime in. The monthly reports are great, as is getting data from the public of net-ops and sys-admins. The discussion list is on a tight leash, but I would like those of you who have been monitoring it and disagree with me to do so here and tell us why we failed there. If we indeed see the botnets@ list as a success, I would like us to move forward and divulge more redundant already public information to the public, and help move the cause along further than by classifying every bit of useless information as top secret. Thanks, I am looking forward to your input, Gadi. -- "In a good cause, there are no failures, only delayed successes". ~Isaac Asimov, "In a Good Cause".

1 0

Mail delivery problem to AOL for Cloud 9
by Mark Hennessy 20 May '06

20 May '06

I'm seeing a problem with mail delivery to AOL subscribers for e-mails originating from my network. If someone from AOL is monitoring this list could you please contact me off-list about this? I have tried many times to contact members of your organization by phone but have not been able to get this matter resolved through the usual channels. You may contact me at mhennessy(a)cloud9.net or hostmaster(a)cloud9.net . -- Mark Hennessy Cloud 9 Internet +1 914 696-4000 http://www.cloud9.net

2 1

Weekly Routing Table Report
by Routing Analysis Role Account 19 May '06

19 May '06

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 20 May, 2006 Analysis Summary ---------------- BGP routing table entries examined: 188610 Prefixes after maximum aggregation: 104284 Unique aggregates announced to Internet: 92582 Total ASes present in the Internet Routing Table: 22230 Origin-only ASes present in the Internet Routing Table: 19345 Origin ASes announcing only one prefix: 9245 Transit ASes present in the Internet Routing Table: 2885 Transit-only ASes present in the Internet Routing Table: 64 Average AS path length visible in the Internet Routing Table: 3.5 Max AS path length visible: 20 Max AS path prepend of ASN (34527) 16 Prefixes from unregistered ASNs in the Routing Table: 8 Unregistered ASNs in the Routing Table: 6 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 10 Number of addresses announced to Internet: 1538347176 Equivalent to 91 /8s, 177 /16s and 80 /24s Percentage of available address space announced: 41.5 Percentage of allocated address space announced: 60.0 Percentage of available address space allocated: 69.1 Total number of prefixes smaller than registry allocations: 93291 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 39800 Total APNIC prefixes after maximum aggregation: 16690 Prefixes being announced from the APNIC address blocks: 37504 Unique aggregates announced from the APNIC address blocks: 18371 APNIC Region origin ASes present in the Internet Routing Table: 2561 APNIC Region origin ASes announcing only one prefix: 733 APNIC Region transit ASes present in the Internet Routing Table: 386 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 225925856 Equivalent to 13 /8s, 119 /16s and 90 /24s Percentage of available APNIC address space announced: 70.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 97594 Total ARIN prefixes after maximum aggregation: 57782 Prefixes being announced from the ARIN address blocks: 71589 Unique aggregates announced from the ARIN address blocks: 26499 ARIN Region origin ASes present in the Internet Routing Table: 10721 ARIN Region origin ASes announcing only one prefix: 4019 ARIN Region transit ASes present in the Internet Routing Table: 988 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 292645120 Equivalent to 17 /8s, 113 /16s and 105 /24s Percentage of available ARIN address space announced: 75.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks 24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 37713 Total RIPE prefixes after maximum aggregation: 25238 Prefixes being announced from the RIPE address blocks: 34722 Unique aggregates announced from the RIPE address blocks: 23499 RIPE Region origin ASes present in the Internet Routing Table: 8039 RIPE Region origin ASes announcing only one prefix: 4217 RIPE Region transit ASes present in the Internet Routing Table: 1319 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 249979076 Equivalent to 14 /8s, 230 /16s and 96 /24s Percentage of available RIPE address space announced: 78.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 RIPE Address Blocks 62/8, 80/5, 88/6, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 11361 Total LACNIC prefixes after maximum aggregation: 3680 Prefixes being announced from the LACNIC address blocks: 9450 Unique aggregates announced from the LACNIC address blocks: 5513 LACNIC Region origin ASes present in the Internet Routing Table: 689 LACNIC Region origin ASes announcing only one prefix: 227 LACNIC Region transit ASes present in the Internet Routing Table: 131 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 16 Number of LACNIC addresses announced to Internet: 26970112 Equivalent to 1 /8s, 155 /16s and 136 /24s Percentage of available LACNIC address space announced: 40.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 189/8, 190/8, 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 2134 Total AfriNIC prefixes after maximum aggregation: 894 Prefixes being announced from the AfriNIC address blocks: 1472 Unique aggregates announced from the AfriNIC address blocks: 970 AfriNIC Region origin ASes present in the Internet Routing Table: 156 AfriNIC Region origin ASes announcing only one prefix: 49 AfriNIC Region transit ASes present in the Internet Routing Table: 25 Average AfriNIC Region AS path length visible: 3.4 Max AfriNIC Region AS path length visible: 13 Number of AfriNIC addresses announced to Internet: 4080640 Equivalent to 0 /8s, 62 /16s and 68 /24s Percentage of available AfriNIC address space announced: 12.2 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 1146 7080 217 CHINANET-BACKBONE 9583 903 109 16 Sify Limited 4755 897 259 72 Videsh Sanchar Nigam Ltd. Aut 4766 685 4435 304 Korea Telecom (KIX) 1221 615 1556 471 Telstra Pty Ltd 9498 557 211 66 BHARTI BT INTERNET LTD. 7545 529 124 70 TPG Internet Pty Ltd 17488 518 32 9 Hathway IP Over Cable Interne 17676 485 7029 109 Softbank BB Corp. 9443 450 110 81 Primus Telecommunications 4802 380 80 173 Wantree Development 18101 359 85 23 Reliance Infocom Ltd Internet 17557 358 28 165 Pakistan Telecom 17849 351 22 113 Telecommunications Technology 17974 338 135 19 PT TELEKOMUNIKASI INDONESIA 2907 336 1749 312 SINET Japan 9929 326 221 57 China Netcom Corp. 7474 299 211 229 SingTel Optus Pty Ltd 9800 273 410 67 CHINA UNICOM 9837 266 78 159 Powertel Ltd ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1505 6225 965 AT&T WorldNet Services 4323 1293 734 254 Time Warner Telecom 6197 1006 622 472 BellSouth Network Solutions, 721 994 21945 303 DLA Systems Automation Center 174 953 5786 897 Cogent Communications 19029 949 151 109 New Edge Networks 18566 939 272 8 Covad Communications 701 932 6780 769 UUNET Technologies, Inc. 2386 877 522 675 AT&T Data Communications Serv 1239 845 2805 599 Sprint 209 708 3689 553 Qwest 19262 702 2101 184 Verizon Global Networks 20115 694 609 375 Charter Communications 22773 663 1745 45 Cox Communications, Inc. 7011 635 218 413 Citizens Utilities 11492 621 87 21 Cable One 852 582 1084 383 Telus Advanced Communications 6478 571 1523 337 AT&T Worldnet Services 19916 563 49 54 OLM LLC 855 545 244 64 Canadian Research Network RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 578 1952 456 UUNET - Commercial IP service 3301 307 1071 293 TeliaNet Sweden 3352 297 1644 30 Ibernet, Internet Access Netw 8220 294 472 267 COLT Telecommunications 3320 287 3989 240 Deutsche Telekom AG 680 245 2025 242 DFN-IP service G-WiN 3246 235 504 225 Song Networks 6746 232 89 208 Dynamic Network Technologies, 8708 219 276 202 Romania Data Systems S.A. 24863 212 42 10 LINKdotNET AS number 8551 202 198 24 Bezeq International 3215 199 1664 94 France Telecom Transpac 3269 198 2134 72 TELECOM ITALIA 1257 190 740 165 SWIPnet Swedish IP Network 30890 183 16 68 SC Kappa Invexim SRL 8866 179 37 15 Bulgarian Telecommunication C 786 171 1778 171 The JANET IP Service 5400 171 348 140 BT Ignite European Backbone 6830 169 765 35 UPC Distribution Services 3300 167 171 96 AUCS Communications Services LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 706 1083 226 UniNet S.A. de C.V. 22047 417 158 11 VTR PUNTO NET S.A. 16814 330 20 8 NSS, S.A. 11172 324 110 87 Servicios Alestra S.A de C.V 6147 262 126 22 Telefonica Del Peru 14117 205 12 6 Telefonica del Sur S.A. 10481 181 72 8 Prima S.A. 7303 169 79 24 Telecom Argentina Stet-France 11556 132 80 4 Cable-Wireless Panama 21826 132 16 23 INTERCABLE 6503 129 149 77 AVANTEL, S.A. 19169 129 8 21 Telconet 14259 116 10 12 GTD Internet S.A. 23216 113 21 9 RAMtelecom Telecomunicaciones 6505 109 88 79 Global One Communicaoes Ltda 7910 105 7 10 ANDINET ON LINE 5639 103 12 9 Telecommunications Services o 19429 103 58 44 E.T.B. 18822 98 7 9 TELEFONICA MANQUEHUE 14571 97 25 3 Internet Group do Brasil AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 282 803 233 The Internet Solution 8452 168 60 7 TEDATA 6713 137 135 11 Itissalat Al-MAGHRIB 2018 130 314 105 Tertiary Education Network 5536 121 8 18 Internet Egypt Network 24835 117 50 7 RAYA Telecom - Egypt 33783 105 6 2 EEPAD TISP TELECOM & INTERNET 2905 73 155 66 The Internetworking Company o 20928 58 16 2 Noor Advanced Technologies AS 15475 53 84 4 Nile Online 5713 39 294 35 Telkom SA Ltd 15706 31 8 3 Sudatel Internet Exchange Aut 33774 30 7 20 AS Number for Telecom Algeria 12455 27 6 3 Jambonet Autonomous system 23889 26 8 11 MAURITIUS TELECOM 8524 24 1 4 AUCEGYPT Autonomous System 16637 24 14 22 Johnnic e-Ventures 10798 22 1 13 Standard Bank of South Africa 2561 19 6 2 Egyptian Universities Network 21491 19 17 2 UTL On-line is RF broadband I Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 1293 1039 Time Warner Telecom 18566 939 931 Covad Communications 4134 1146 929 CHINANET-BACKBONE 9583 903 887 Sify Limited 19029 949 840 New Edge Networks 4755 897 825 Videsh Sanchar Nigam Ltd. Aut 721 994 691 DLA Systems Automation Center 22773 663 618 Cox Communications, Inc. 11492 621 600 Cable One 6197 1006 534 BellSouth Network Solutions, 19262 702 518 Verizon Global Networks 19916 563 509 OLM LLC 17488 518 509 Hathway IP Over Cable Interne 5668 525 502 CenturyTel Internet Holdings, 9498 557 491 BHARTI BT INTERNET LTD. 855 545 481 Canadian Research Network 8151 706 480 UniNet S.A. de C.V. 7545 529 459 TPG Internet Pty Ltd 3602 539 429 Sprint Canada, Inc. 22047 417 406 VTR PUNTO NET S.A. List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65289 PRIVATE 148.164.1.0/24 4755 Videsh Sanchar Nigam 65128 PRIVATE 193.110.50.0/24 24652 Juniper Networks, Eu 24409 UNALLOCATED 203.119.29.0/24 9808 Guangdong Mobile Com 64515 PRIVATE 203.126.13.0/25 7610 SINGAPORE ADVANCE RE 64515 PRIVATE 203.126.13.128/26 7610 SINGAPORE ADVANCE RE 65280 PRIVATE 203.197.161.0/24 4755 Videsh Sanchar Nigam 65280 PRIVATE 203.200.14.0/24 4755 Videsh Sanchar Nigam 65280 PRIVATE 203.200.21.0/24 4755 Videsh Sanchar Nigam Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 183.206.196.0/24 2188 FR-RENATER-ASTER 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.84.205.0/24 719 LANLINK autonomous system 192.119.135.0/24 270 NASA 192.172.0.0/19 721 DLA Systems Automation Center Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:9 /11:27 /12:91 /13:200 /14:361 /15:703 /16:8809 /17:3213 /18:5312 /19:11653 /20:13118 /21:11365 /22:14645 /23:15812 /24:102224 /25:379 /26:250 /27:192 /28:64 /29:70 /30:50 /31:0 /32:36 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 922 939 Covad Communications 19029 880 949 New Edge Networks 6197 795 1006 BellSouth Network Solutions, 7018 793 1505 AT&T WorldNet Services 9583 732 903 Sify Limited 4323 637 1293 Time Warner Telecom 11492 612 621 Cable One 2386 605 877 AT&T Data Communications Serv 19916 557 563 OLM LLC 7011 544 635 Citizens Utilities 4766 495 685 Korea Telecom (KIX) 855 426 545 Canadian Research Network 5668 408 525 CenturyTel Internet Holdings, 15270 396 427 PaeTec.net -a division of Pae 1239 387 845 Sprint 702 359 578 UUNET - Commercial IP service 6517 357 388 Yipes Communications, Inc. 6198 356 508 BellSouth Network Solutions, 17849 351 351 Telecommunications Technology 8151 349 706 UniNet S.A. de C.V. Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:42 12:1630 13:1 15:14 16:3 17:3 18:4 20:43 24:737 25:1 30:2 32:58 38:216 40:54 41:3 44:3 47:6 52:4 55:1 56:3 57:25 58:153 59:189 60:181 61:861 62:759 63:1931 64:3185 65:2259 66:3011 67:609 68:675 69:1512 70:361 71:85 72:713 73:23 74:36 80:775 81:646 82:600 83:398 84:389 85:533 86:395 87:353 88:90 89:196 124:279 125:407 128:154 129:190 130:109 131:317 132:33 133:8 134:159 135:46 136:178 137:75 138:207 139:68 140:468 141:136 142:380 143:165 144:224 145:39 146:330 147:136 148:331 149:186 150:114 151:90 152:68 153:107 154:6 155:202 156:100 157:149 158:166 159:168 160:87 161:76 162:247 163:147 164:180 165:203 166:166 167:242 168:489 169:128 170:335 171:14 183:1 190:72 192:5761 193:3365 194:2619 195:1836 196:846 198:3911 199:3217 200:4430 201:945 202:6636 203:6871 204:3894 205:2072 206:2410 207:2879 208:2088 209:3782 210:1957 211:691 212:1231 213:1474 214:363 215:41 216:4144 217:1145 218:273 219:199 220:659 221:362 222:162 End of report

1 0

Re: FCC Issues Second Order Mandating Internet Wiretapping Standards
by Fergie 19 May '06

19 May '06

Sorry, mea culpa. Below: s/EPIC/CDT/ Thanks, - ferg -- "Fergie" <fergdawg(a)netzero.net> wrote: Pardon the interruption, but I thought this might be slightly interesting to the list. EPIC.org: [snip] The Federal Communications Commission (FCC) has released a second order reaffirming its decision to require that broadband and certain VoIP services be designed to make government wiretapping easier. This new order was issued despite the fact that a federal appeals court is considering a legal challenge to the FCC's initial decision to extend the "Communications Assistance for Law Enforcement Act" (CALEA) to the Internet. In its second order, the FCC imposed new compliance deadlines, but refused to clarify exactly what service providers must do. CDT has led the appeals court challenge, which if successful will overrule the FCC order. [snip] EPIC statement: http://www.cdt.org/headlines/891 Second FCC CALEA order: http://www.cdt.org/digi_tele/20060512calea.pdf Now, back to your regularly scheduled programming. Cheers, - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

NANOG 37 San Jose - Hotel Reservations
by Carol Wadsworth 19 May '06

19 May '06

If you are planning to attend NANOG 37 in San Jose, please note the NANOG room rate at the San Jose Hilton expires this Monday, May 22. For additional meeting details, please see www.nanog.org. See you there!

1 0