Re: Automatic attack alert to ISPs
There are ISP feedback loops You might also try signing up at http://atlas.arbor.net - see if you can get a sensor deployed in your network. http://atlas.arbor.net/faq/#sensor On Fri, Jun 22, 2012 at 11:21 AM, Ganbold Tsagaankhuu ganb...@gmail.com wrote: Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Automatic attack alert to ISPs
Argus can alert prefix hijacking, in realtime. http://tli.tl/argus Hope to be useful to you. BR. 在 2012年6月22日星期五，Ganbold Tsagaankhuu 写道： Hi, Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. thanks in advance, Ganbold -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Contact from Global Crossing Kindly contact me off list
Hi, Kindly would someone from Global Crossing contact me offlist. Regards, Righa Shake
Re: Automatic attack alert to ISPs
Shadowserver.org has a public benefit notification service. Sent from my iPad On Jun 22, 2012, at 2:46 PM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: Argus can alert prefix hijacking, in realtime. http://tli.tl/argus Hope to be useful to you. BR. 在 2012年6月22日星期五，Ganbold Tsagaankhuu 写道： Hi, Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. thanks in advance, Ganbold -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: LinkedIn password database compromised
Rich Kulawiec r...@gsp.org wrote: On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys) The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now. It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.) The proverbial 'so what' applies? IF the end-user system is compromised, it *doesn't*matter* what kind of security is used, THAT USER is compromised. However, there is a _MASSIVE_ difference with respect to a 'server-side' compromise. One break-in, on *one* machine, can expose tens of millions, (if not hundreds of millions) of user credentials. 2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it. 'male bovine excrement' applies to this strawman argument. Leo made no claim of describing a FUSSP (final ultimate solution to stolen passwords). What he did describe was a methodology that could be fairly easily implemented in the real world, =and= which effectively eliminates the risk of _server-side_ compromise of a master 'password-equivalent' list. Leo's proposal _does_ effectively address the risk of server-side compromise. If implemented, it would effectively eliminate more than half of the
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote privately to me, but as I think I need public responses, I'm Ccing to nanog fairly quoting part of his response: Moreover, it is easy to have a transport protocol with 32bit or 48bit port numbers with the end to end fashion only by modifying end part of the Internet. The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. They still believed the fairy tale even when they designed automated tunneling. But, as most of them have grown up a little not to believe fairly tales, they are trying other possibilities. However, so far, they are not so successful. Masataka Ohta PS Rest of his response is omitted, because I think it is not worth quoting.
Re: How to fix authentication (was LinkedIn)
I used the example I did based on YubiKey, I own one and use it on a regular basis. The real issue I am trying to make is the fact that even in the scenario I placed forward it still requires trust. Trust of a person or trust of a company. This reminds me of a quote: Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein By no means am I saying any of us, or the majority of the world is stupid or uneducated. However, the inherent nature behind trust is just that, relying on some sort of other party is the weak link here. It only takes a single person who has a bad day, or just wants to slack off for that day, to create a vulnerability in any password, key, encryption, or authentication process hundreds if not thousands of people work so hard to solve. While I used YubiKey as my original example, and use it on a regular basis, it still has its downfalls. It cannot be used with Active Sync, so ultimately you can not use it for your Active Directory log in because of a small thing called Exchange. There have been other areas were YubiKey has failed but not by it's design, but by the design of the application itself. How can any of our solutions over come the human factor? -- - Robert Miller (arch3angel) On 6/21/12 10:53 PM, Christopher Morrow wrote: On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush ra...@psg.com wrote: That's basically the Yubikey. It uses a shared key, but since you're relying on a trusted third party anyway there are no trustable third parties note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' -chris
Re: How to fix authentication (was LinkedIn)
In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote: there are no trustable third parties With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :) In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote: note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank. Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk. There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way. The perfect is the enemy of the good. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpSFnXpJbil9.pgp Description: PGP signature
Re: Automatic attack alert to ISPs
+1 - Took the letters right out from under my fingers :-) -- - Robert Miller (arch3angel) On 6/22/12 4:44 AM, Barry Greene wrote: Shadowserver.org has a public benefit notification service. Sent from my iPad On Jun 22, 2012, at 2:46 PM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: Argus can alert prefix hijacking, in realtime. http://tli.tl/argus Hope to be useful to you. BR. 在 2012年6月22日星期五，Ganbold Tsagaankhuu 写道： Hi, Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. thanks in advance, Ganbold -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: LinkedIn password database compromised
Still playing devils advocate here, but does this still not resolve the human factor of Implementation? -- - Robert Miller (arch3angel) On 6/22/12 7:43 AM, Robert Bonomi wrote: Rich Kulawiec r...@gsp.org wrote: On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys) The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now. It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.) The proverbial 'so what' applies? IF the end-user system is compromised, it *doesn't*matter* what kind of security is used, THAT USER is compromised. However, there is a _MASSIVE_ difference with respect to a 'server-side' compromise. One break-in, on *one* machine, can expose tens of millions, (if not hundreds of millions) of user credentials. 2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it. 'male bovine excrement' applies to this strawman argument. Leo made no claim of describing a FUSSP (final ultimate solution to stolen passwords). What he did describe was a methodology that could be fairly easily implemented in the real world, =and= which effectively eliminates the risk of _server-side_ compromise of a master 'password-equivalent' list. Leo's proposal _does_ effectively address the risk of server-side compromise. If implemented, it would effectively eliminate more than half of the
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, Jun 22, 2012 at 8:46 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: MAJOR SNIP The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. Just injecting a real-world comment/observation here: I am sitting at home, on my natively IPv6 connected, Comcast-provided residential service. My phone is sitting next to me, connected to VZW's IPv6-capable LTE network. When I go to one of my client sites, they get IPv6 through a HE.net tunnel. Another client site uses ATT and/or CenturyLink for IPv6 connectivity. *... the list goes on ...* In all cases, IPv6 is alive and well for me. More importantly (even though the last-mile is not ubiquitously IPv6-enabled in all service regions) those five providers have backbones that are 100% up and running, native IPv6 all over the place. So what is the fairy tale?? Am I saying we are all done, and that IPv6 is fully deployed? Of course not, lots of work to do in the enterprise and last-mile areas ... but progress has been noticeable and is accelerating. /TJ
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 23 Jun, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 414975 Prefixes after maximum aggregation: 175345 Deaggregation factor: 2.37 Unique aggregates announced to Internet: 202288 Total ASes present in the Internet Routing Table: 41358 Prefixes per ASN: 10.03 Origin-only ASes present in the Internet Routing Table: 33312 Origin ASes announcing only one prefix: 15660 Transit ASes present in the Internet Routing Table:5532 Transit-only ASes present in the Internet Routing Table:141 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 28 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 392 Unregistered ASNs in the Routing Table: 123 Number of 32-bit ASNs allocated by the RIRs: 2879 Number of 32-bit ASNs visible in the Routing Table:2514 Prefixes from 32-bit ASNs in the Routing Table:6440 Special use prefixes present in the Routing Table:2 Prefixes being announced from unallocated address space:260 Number of addresses announced to Internet: 2568129068 Equivalent to 153 /8s, 18 /16s and 138 /24s Percentage of available address space announced: 69.3 Percentage of allocated address space announced: 69.4 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 93.0 Total number of prefixes smaller than registry allocations: 144378 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 101060 Total APNIC prefixes after maximum aggregation: 32679 APNIC Deaggregation factor:3.09 Prefixes being announced from the APNIC address blocks: 101493 Unique aggregates announced from the APNIC address blocks:41912 APNIC Region origin ASes present in the Internet Routing Table:4708 APNIC Prefixes per ASN: 21.56 APNIC Region origin ASes announcing only one prefix: 1240 APNIC Region transit ASes present in the Internet Routing Table:743 Average APNIC Region AS path length visible:4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table:238 Number of APNIC addresses announced to Internet: 703274368 Equivalent to 41 /8s, 235 /16s and 29 /24s Percentage of available APNIC address space announced: 82.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:152044 Total ARIN prefixes after maximum aggregation:77265 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 152987 Unique aggregates announced from the ARIN address blocks: 68132 ARIN Region origin ASes present in the Internet Routing Table:15172 ARIN Prefixes per ASN:10.08 ARIN Region origin ASes
[MBONED] PIM survey for operators
The IETF pim working group is conducting a survey in order to advance the PIM Sparse Mode spec on the IETF Standards Track, and would like input from operators. The survey ends July 20th. Please see below for more information. thank you, pim chairs Mike Stig Introduction: PIM-SM was first published as RFC 2117 in 1997 and then again as RFC 2362 in 1998. The protocol was classified as Experimental in both of these documents. The PIM-SM protocol specification was then rewritten in whole and advanced to Proposed Standard as RFC 4601 in 2006. Considering the multiple independent implementations developed and the successful operational experience gained, the IETF has decided to advance the PIM-SM routing protocol to Draft Standard. This survey intends to provide supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Proposed Standard to Draft Standard. (Due to RFC 6410, now the intention is to progress it to Internet Standard. Draft Standard is no longer used.) This survey is issued on behalf of the IETF PIM Working Group. The responses will be collected by a neutral third-party and kept strictly confidential; only the final combined results will be published. Marshall Eubanks has agreed to anonymize the response to this Questionnaire. Marshall has a long experience with Multicast but has no direct financial interest in this matter, nor ties to any of the vendors involved. He is also a member of the IAOC, Chair of the IETF Trust and co-chair of the IETF Layer 3 VPN Working Group. Please send Questionnaire responses to his email address, marshall.euba...@gmail.com. He requests that such responses include the string RFC 4601 bis Questionnaire in the subject field. Before answering the questions, please comple the following background information. Name of the Respondent: Affliation/Organization: Contact Email: Provide description of PIM deployment: Do you wish to keep the information provided confidential: Questions: 1 Have you deployed PIM-SM in your network? 2 How long have you had PIM-SM deployed in your network? Do you know if your deployment is based on the most recent RFC4601? 3 Have you deployed PIM-SM for IPv6 in your network? 4 Are you using equipment with different (multi-vendor) PIM-SM implementations for your deployment? 5 Have you encountered any inter-operability or backward- compatibility issues amongst differing implementations? If yes, what are your concerns about these issues? 6 Have you deployed both dense mode and sparse mode in your network? If yes, do you route between these modes using features such as *,*,RP or PMBR? 7 To what extent have you deployed PIM functionality, like BSR, SSM, and Explicit Tracking? 8 Which RP mapping mechanism do you use: Static, AutoRP, or BSR? 9 How many RPs have you deployed in your network? 10 If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446) or Anycast-RP using PIM (RFC 4610)? 11 Do you have any other comments on PIM-SM deployment in your network? ___ MBONED mailing list mbo...@ietf.org https://www.ietf.org/mailman/listinfo/mboned
BGP Update Report
BGP Update Report Interval: 14-Jun-12 -to- 21-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS8452 113559 4.4% 62.4 -- TE-AS TE-AS 2 - AS982950283 2.0% 38.7 -- BSNL-NIB National Internet Backbone 3 - AS840245797 1.8% 23.5 -- CORBINA-AS OJSC Vimpelcom 4 - AS13188 41623 1.6% 79.3 -- BANKINFORM-AS TOV Bank-Inform 5 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 6 - AS12479 28842 1.1% 38.1 -- UNI2-AS France Telecom Espana SA 7 - AS24560 27934 1.1% 26.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS730325098 1.0% 17.4 -- Telecom Argentina S.A. 9 - AS17813 25074 1.0% 188.5 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS580021992 0.9% 83.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 12 - AS28057 18560 0.7%1546.7 -- Contecol 13 - AS26615 16782 0.7% 18.4 -- Tim Celular S.A. 14 - AS17621 16250 0.6% 106.9 -- CNCGROUP-SH China Unicom Shanghai network 15 - AS28573 16052 0.6% 8.1 -- NET Servicos de Comunicao S.A. 16 - AS755214335 0.6% 12.1 -- VIETEL-AS-AP Vietel Corporation 17 - AS702914153 0.6% 4.1 -- WINDSTREAM - Windstream Communications Inc 18 - AS16814 12125 0.5% 17.9 -- NSS S.A. 19 - AS17974 11505 0.5% 5.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS25620 10104 0.4% 53.7 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS452644799 0.2%2399.5 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 2 - AS28057 18560 0.7%1546.7 -- Contecol 3 - AS452861387 0.1%1387.0 -- EDIINDONESIA-AS-ID PT EDI INDONESIA 4 - AS294211371 0.1%1371.0 -- DCI-AS Digital Communications Incorporated Ltd. 5 - AS309441258 0.1%1258.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove DKD 6 - AS29126 972 0.0% 972.0 -- DATIQ-AS Datiq B.V. 7 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 8 - AS40848 911 0.0% 911.0 -- FMFCU - Franklin Mint FCU 9 - AS55665 824 0.0% 824.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS3 635 0.0%1139.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 11 - AS3 555 0.0%1322.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 12 - AS116522517 0.1% 503.4 -- TFCL-2 - TERRA FIRMA COMMUNICATIONS, LLC 13 - AS57201 459 0.0% 459.0 -- EDF-AS Estonian Defence Forces 14 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 15 - AS38857 814 0.0% 407.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 16 - AS194064428 0.2% 402.5 -- TWRS-MA - Towerstream I, Inc. 17 - AS43230 346 0.0% 346.0 -- OMNIPORT-AS OMNIPORT SRL 18 - AS16064 330 0.0% 330.0 -- INFOPAC-AS Joint-Stock Company INFOPAC 19 - AS51624 322 0.0% 322.0 -- ITC21VEK-AS ITC XXI Century Ltd. 20 - AS286664398 0.2% 314.1 -- HOSTLOCATION LTDA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19886 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 220.196.26.0/24 15945 0.6% AS17621 -- CNCGROUP-SH China Unicom Shanghai network 3 - 41.43.147.0/2411685 0.4% AS8452 -- TE-AS TE-AS 4 - 122.161.0.0/1610614 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 62.36.252.0/22 7930 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 182.64.0.0/16 7567 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6595 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 202.56.215.0/246459 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - 62.36.241.0/24 6172 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 59.177.48.0/20 6054 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 11 - 62.36.210.0/24 6021 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 194.63.9.0/24 5263 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 202.159.192.0/19 4837 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 14 - 202.90.40.0/24 4797 0.2% AS45264 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 15 - 69.38.178.0/24 4408 0.2% AS19406 -- TWRS-MA - Towerstream I,
The Cidr Report
This report has been generated at Fri Jun 22 21:12:58 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
15-06-12416421 242407
16-06-12416435 242366
17-06-12416800 242573
18-06-12417057 242604
19-06-12416751 242539
20-06-12416653 242280
21-06-12417133 242084
22-06-12417401 241620
AS Summary
41477 Number of ASes in routing system
17307 Number of ASes announcing only one prefix
3401 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
113213920 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 22Jun12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 417722 241644 17607842.2% All ASes
AS6389 3401 193 320894.3% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3279 1651 162849.6% WINDSTREAM - Windstream
Communications Inc
AS22773 1652 137 151591.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2720 1294 142652.4% KIXS-AS-KR Korea Telecom
AS18566 2091 706 138566.2% COVAD - Covad Communications
Co.
AS28573 1954 581 137370.3% NET Servicos de Comunicao S.A.
AS2118 1255 14 124198.9% RELCOM-AS OOO NPO Relcom
AS7545 1704 503 120170.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4323 1571 386 118575.4% TWTC - tw telecom holdings,
inc.
AS10620 1967 794 117359.6% Telmex Colombia S.A.
AS1785 1925 815 111057.7% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1594 540 105466.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7303 1440 462 97867.9% Telecom Argentina S.A.
AS7552 1100 217 88380.3% VIETEL-AS-AP Vietel
Corporation
AS26615 902 33 86996.3% Tim Celular S.A.
AS17974 1945 1088 85744.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS8151 1490 672 81854.9% Uninet S.A. de C.V.
AS18101 947 160 78783.1% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1107 346 76168.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9394 892 162 73081.8% CRNET CHINA RAILWAY
Internet(CRNET)
AS13977 839 123 71685.3% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS3356 1113 467 64658.0% LEVEL3 Level 3 Communications
AS855690 57 63391.7% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS17676 691 74 61789.3% GIGAINFRA Softbank BB Corp.
AS30036 1439 835 60442.0% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS4780 841 246 59570.7% SEEDNET Digital United Inc.
AS19262 998 405 59359.4% VZGNI-TRANSIT - Verizon Online
LLC
AS22561 1016 424 59258.3% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS9808 593 22 57196.3% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS8452 1275 716 55943.8% TE-AS TE-AS
Total 44431141233030868.2% Top 30 total
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
TJ wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. Am I saying we are all done, and that IPv6 is fully deployed? Of course not, lots of work to do in the enterprise and last-mile areas ... but progress has been noticeable and is accelerating. Owen tried to deny my point that: : Moreover, it is easy to have a transport protocol with : 32bit or 48bit port numbers with the end to end fashion : only by modifying end part of the Internet. As the enterprise and last-mile areas do not need to be modified to accommodate a new transport protocol, they belong to the center part. Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Masataka Ohta Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. QED, your statement does not stand up to current events. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. Remember that you wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 22, 2012, at 6:15 PM, Masataka Ohta wrote: Owen DeLong wrote: Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. Remember that you wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? You redefined center. My definition of center when I claimed 99% was the major backbones and core routers. That is the CENTER of the internet. Different definition of center (yours) where the center includes everything except the edge-most hosts, different metrics for completion and challenges. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Rate of deployment is more inclusive than just the 'center', that would be my guess. Are we really taking this already nearly-pointless conversation to an all new low and arguing semantics? Clearly some of us disagree with each other, perhaps we just hold our tongues ( fingers) and let the real world decide?? /TJ
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On 06/22/2012 08:35 PM, TJ wrote: The center part of the internet is the easiest part of modification for IPv6 and is probably somewhere near 99% complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Rate of deployment is more inclusive than just the 'center', that would be my guess. Are we really taking this already nearly-pointless conversation to an all new low and arguing semantics? Clearly some of us disagree with each other, perhaps we just hold our tongues ( fingers) and let the real world decide?? /TJ There might be good money in a PPV cagematch-style event.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
(2012/06/23 10:35), TJ wrote: Rate of deployment is more inclusive than just the 'center', that would be my guess. But, the context, as you can see, is this: : Even though it may be easy to make end systems and local : LANs v6 capable, rest, the center part, of the Internet : keep causing problems. : : Masataka Ohta : : Those problems are getting solved more and more every day. that the problems are caused by the center part. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 22 Jun 2012, Masataka Ohta wrote: Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. I really don't see where you're getting that from. The biggest consumers of IPv4 space in the US tended to get initial IPv6 blocks from ARIN that were large enough to accommodate their needs for some time. One large v6 prefix in the global routing table is more efficient in terms of the impact on the global routing table than the patchwork of IPv4 blocks those same providers needed to get over time to accommodate growth. Those 'green-field' deployments of IPv6, coupled with the sparse allocation model that the RIRs seem to be using will do a lot to keep v6 routing table growth in check. I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments. If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4. jms
