June 2012 - Test - lists.nanog.org

Re: NANOG Digest, Vol 53, Issue 105
by Gregg 25 Jun '12

25 Jun '12

It really is possible to have a secure society that does not require identification and authentication at every turn and for every move. We the people will have to demand such freedom in order that it come to pass, however, because it is at odds with what money and power want. And where those go, sex follows. So, you could say, we have ourselves in a bit of a bind at the moment. Gregg Squires Consultant Unimatics, Inc NV Sent from my mobile fruit device. On Jun 25, 2012, at 7:30 AM, nanog-request(a)nanog.org wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: LinkedIn password database compromised (Keith Medcalf) > 2. RE: LinkedIn password database compromised (Keith Medcalf) > 3. Re: LinkedIn password database compromised (Michael Thomas) > 4. Re: How to fix authentication (was LinkedIn) (Kyle Creyts) > 5. EULAs (James Smith) > 6. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Masataka Ohta) > 7. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 8. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 9. Re: How to fix authentication (was LinkedIn) (AP NANOG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 23 Jun 2012 18:52:10 -0600 > From: "Keith Medcalf" <kmedcalf(a)dessus.com> > To: "Leo Bicknell" <bicknell(a)ufp.org> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: LinkedIn password database compromised > Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3(a)mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > Leo, > > This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. > > Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. > > If it does not use self-generated unsigned keys, it will never fly. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell@ufp.org] >> Sent: Wednesday, 20 June, 2012 15:39 >> To: nanog(a)nanog.org >> Subject: Re: LinkedIn password database compromised >> >> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda >> wrote: >>> Key management: doing it right is hard and probably beyond most end users. >> >> I could not be in more violent disagreement. >> >> First time a user goes to sign up on a web page, the browser should >> detect it wants a key uploaded and do a simple wizard. >> >> - Would you like to create an online identity for logging into web >> sites? Yes, No, Import >> >> User says yes, it creates a key, asking for an e-mail address to >> identify it. Import to drag it in from some other program/format, >> No and you can't sign up. >> >> Browser now says "would you like to sign up for website 'foobar.com'", >> and if the user says "yes" it submits their public key including the >> e-mail they are going to use to log on. User doesn't even fill out >> a form at all. >> >> Web site still does the usual e-mail the user, click this link to verify >> you want to sign up thing. >> >> User goes back to web site later, browser detects "auth needed" and >> "public key foo" accepted, presents the cert, and the user is logged in. >> >> Notice that these steps _remove_ the user filling out forms to sign up >> for simple web sites, and filling out forms to log in. Anyone who's >> used cert-based auth at work is already familiar, the web site >> "magically" knows you. This is MUCH more user friendly. >> >> So the big magic here is the user has to click on "yes" to create a key >> and type in an e-mail once. That's it. There's no web of trust. No >> identity verification (a-la ssl). I'm talking a very SSH like system, >> but with more polish. >> >> Users would find it much more convenient and wonder why we ever used >> passwords, I think... >> >> -- >> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 23 Jun 2012 19:14:31 -0600 > From: "Keith Medcalf" <kmedcalf(a)dessus.com> > To: "Rich Kulawiec" <rsk(a)gsp.org> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: LinkedIn password database compromised > Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5(a)mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > >> 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. This can be done, therefore it will be done, and when >> some security researcher discovers it, the usual excuses and justifications >> will be made by the designated spokesliars for the companies involved... >> which will of course keep right on doing it, albeit perhaps with more >> subterfuge. > >> Problem #2 is newer, but I'm willing to bet that it will also last >> at least a decade and that it will get worse, since there are >> substantial economic incentives to make it so. > > This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 23 Jun 2012 19:09:32 -0700 > From: Michael Thomas <mike(a)mtcc.com> > To: Keith Medcalf <kmedcalf(a)dessus.com> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Re: LinkedIn password database compromised > Message-ID: <4FE676DC.9000108(a)mtcc.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/23/2012 05:52 PM, Keith Medcalf wrote: >> Leo, >> >> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). > > What is their leverage to extort? A web site just needs to make the > client and server end agree on a scheme, and they control both ends. > They can't force me to use their scheme any more than they can force > me to not use Basic and use their scheme instead. Keep in mind that > asymmetric keys do not imply certification, and asymmetric keys are > cheap and plentiful -- as in a modest amount of CPU time these days. > > Mike > >> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. >> >> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. >> >> If it does not use self-generated unsigned keys, it will never fly. >> >> --- >> () ascii ribbon campaign against html e-mail >> /\ www.asciiribbon.org >> >> >>> -----Original Message----- >>> From: Leo Bicknell [mailto:bicknell@ufp.org] >>> Sent: Wednesday, 20 June, 2012 15:39 >>> To: nanog(a)nanog.org >>> Subject: Re: LinkedIn password database compromised >>> >>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda >>> wrote: >>>> Key management: doing it right is hard and probably beyond most end users. >>> I could not be in more violent disagreement. >>> >>> First time a user goes to sign up on a web page, the browser should >>> detect it wants a key uploaded and do a simple wizard. >>> >>> - Would you like to create an online identity for logging into web >>> sites? Yes, No, Import >>> >>> User says yes, it creates a key, asking for an e-mail address to >>> identify it. Import to drag it in from some other program/format, >>> No and you can't sign up. >>> >>> Browser now says "would you like to sign up for website 'foobar.com'", >>> and if the user says "yes" it submits their public key including the >>> e-mail they are going to use to log on. User doesn't even fill out >>> a form at all. >>> >>> Web site still does the usual e-mail the user, click this link to verify >>> you want to sign up thing. >>> >>> User goes back to web site later, browser detects "auth needed" and >>> "public key foo" accepted, presents the cert, and the user is logged in. >>> >>> Notice that these steps _remove_ the user filling out forms to sign up >>> for simple web sites, and filling out forms to log in. Anyone who's >>> used cert-based auth at work is already familiar, the web site >>> "magically" knows you. This is MUCH more user friendly. >>> >>> So the big magic here is the user has to click on "yes" to create a key >>> and type in an e-mail once. That's it. There's no web of trust. No >>> identity verification (a-la ssl). I'm talking a very SSH like system, >>> but with more polish. >>> >>> Users would find it much more convenient and wonder why we ever used >>> passwords, I think... >>> >>> -- >>> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >> >> > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 23 Jun 2012 22:02:25 -0700 > From: Kyle Creyts <kyle.creyts(a)gmail.com> > To: nanog(a)nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: > <CA+TcGd_uhe5s161umexuC=3v2vaC31zFqV+aqEqjP0zYunab-g(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I would suggest that multiple models be pursued (since each appears to have > a champion) and that the market/drafting process will resolve the issue of > which is better (which is okay by me: widespread adoption of any of the > proposed models would advance the state of the norm; progress beats the > snot out of stagnation in my book) > > My earlier replies were reprehensible. This is not a thread that should > just be laughed off. Real progress may be occurring here, and at the least, > good knowledge and discussion is accumulating in a way which may serve as a > resource for the curious or concerned. > On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell(a)ufp.org> wrote: > >> 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 - bicknell(a)ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Jun 2012 00:41:26 -0300 > From: James Smith <james(a)smithwaysecurity.com> > To: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: EULAs > Message-ID: <4FE7DDE6.7070606(a)smithwaysecurity.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I was wondering if some one could contact me with regards to ISP's who > share data to private companies if stated in their EULAs . > > -- > Sincerely; > > > James Smith > CEO, Security Analyst > > > > ------------------------------ > > Message: 6 > Date: Mon, 25 Jun 2012 16:06:50 +0900 > From: Masataka Ohta <mohta(a)necom830.hpcl.titech.ac.jp> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <4FE80E0A.5020906(a)necom830.hpcl.titech.ac.jp> > Content-Type: text/plain; charset=ISO-2022-JP > > Justin M. Streiner wrote: > >> 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. > > As I already wrote: > > : That's not the point. The problem is that SRAMs scale well but > : CAMs do not. > > it is a lot more difficult to quickly look up 1M routes > with /48 than 2M routes with /24. > >> 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. > > The routing table grows mostly because of multihoming, > regardless of whether it is v4 or v6. > > The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. > > Masataka Ohta > > > > ------------------------------ > > Message: 7 > Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST) > From: Tim Franklin <tim(a)pelican.org> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <f3cc4bae-f05b-4320-82d0-191f4f6721ff(a)mail.pelican.org> > Content-Type: text/plain; charset=utf-8 > >> 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. > > Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. > > Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. > > But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. > > Regards, > Tim. > > > > ------------------------------ > > Message: 8 > Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST) > From: Tim Franklin <tim(a)pelican.org> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <d76090e9-983b-420d-beb4-818ff97abdae(a)mail.pelican.org> > Content-Type: text/plain; charset=utf-8 > >> The only solution is, IMO, to let multihomed sites have >> multiple prefixes inherited from their upper ISPs, still >> keeping the sites' ability to control loads between incoming >> multiple links. > > And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse). > > Regards, > Tim. > > > > ------------------------------ > > Message: 9 > Date: Mon, 25 Jun 2012 09:30:02 -0400 > From: AP NANOG <nanog(a)armoredpackets.com> > To: nanog(a)nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: <4FE867DA.8050400(a)armoredpackets.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Kyle, > > I may be mistaken here, but I don't believe anyone is truly laughing the > matter off. > > There may have been some remarks about second or third parties, but the > fact does remain these are the areas which current concerns still lay. > > -- > > Robert Miller > (arch3angel) > > On 6/24/12 1:02 AM, Kyle Creyts wrote: >> I would suggest that multiple models be pursued (since each appears to have >> a champion) and that the market/drafting process will resolve the issue of >> which is better (which is okay by me: widespread adoption of any of the >> proposed models would advance the state of the norm; progress beats the >> snot out of stagnation in my book) >> >> My earlier replies were reprehensible. This is not a thread that should >> just be laughed off. Real progress may be occurring here, and at the least, >> good knowledge and discussion is accumulating in a way which may serve as a >> resource for the curious or concerned. >> On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell(a)ufp.org> wrote: >> >>> 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 - bicknell(a)ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >>> > > > > End of NANOG Digest, Vol 53, Issue 105 > **************************************

1 0

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
by Masataka Ohta 25 Jun '12

25 Jun '12

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.

5 11

LinkedIn password database compromised
by Lynda 25 Jun '12

25 Jun '12

Sorry to be the bearer of such bad tidings. Please note that I'm doing a quick copy/paste from a notification I received. I've edited it a bit. Please note that LinkedIn has weighed in with a carefully worded blog post: http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ Further details: 1. The leak took place on June 4 2. LinkedIn was using unsalted SHA-1 for their password store. 3. FYI, there are two lists. The second one appears to be from eHarmony. Unsalted MD5 used there. 4. The posted passwords are believed to be ones the cracker wanted help with, i.e., they have significantly more already cracked. Apparently phishing emails are already active in the wild based on the crack: http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-li… In other words, if you have a LinkedIn account, expect that the password has been stolen. Go change your password now. If you used that password elsewhere, you know the routine. In addition, as has been pointed out elsewhere, there's no sign LI has fixed the problem. Expect that the password you change it to will also be compromised. :-( -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

43 97

EULAs
by James Smith 25 Jun '12

25 Jun '12

Hello, I was wondering if some one could contact me with regards to ISP's who share data to private companies if stated in their EULAs . -- Sincerely; James Smith CEO, Security Analyst

1 0

NYC to DEU packet loss
by Tim Durack 24 Jun '12

24 Jun '12

Trying to troubleshoot packet loss from NYC to DEU. Traceroute shows: tdurack@2ua82715mg:~$ traceroute -I 194.25.250.73 traceroute to 194.25.250.73 (194.25.250.73), 30 hops max, 60 byte packets <snip> 4 216.55.2.85 (216.55.2.85) 1.694 ms 1.698 ms 1.698 ms 5 vb1010.rar3.nyc-ny.us.xo.net (216.156.0.17) 4.788 ms 4.792 ms 4.791 ms 6 207.88.14.178.ptr.us.xo.net (207.88.14.178) 1.684 ms 1.461 ms 1.452 ms 7 62.157.250.245 (62.157.250.245) 40.457 ms 42.980 ms 42.982 ms 8 hh-eb3-i.HH.DE.NET.DTAG.DE (62.154.32.134) 129.417 ms * 129.422 ms 9 194.25.250.73 (194.25.250.73) 139.501 ms 136.192 ms 139.236 ms Packet loss of approx. 20% affects hops 7 and 8, along with end host 9. Loss appears to be data-plane, not control-plane rate limiting. Affected customer confirms this too :-) 62.157.250.245 is in Deutsche Telekom address spaces, so I'm guessing this is either a DTAG problem or an issue between XO and DTAG. I have a ticket open with XO, but I'm having a hard time figuring out what is ~40ms away from NYC on a path to DEU. Any idea what the physical path is? -- Tim:>

2 2

Cogent DNS Contact
by Garret Picchioni 23 Jun '12

23 Jun '12

Hi All, If anyone has a contact at Cogent, who might be able to solve a reverse DNS issue, could they contact me offline? Thanks! Garret

2 1

BGP Update Report
by cidr-report＠potaroo.net 23 Jun '12

23 Jun '12

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 ASN Upds % Upds/Pfx AS-Name 1 - AS8452 113559 4.4% 62.4 -- TE-AS TE-AS 2 - AS9829 50283 2.0% 38.7 -- BSNL-NIB National Internet Backbone 3 - AS8402 45797 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 - AS7303 25098 1.0% 17.4 -- Telecom Argentina S.A. 9 - AS17813 25074 1.0% 188.5 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS5800 21992 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 - AS7552 14335 0.6% 12.1 -- VIETEL-AS-AP Vietel Corporation 17 - AS7029 14153 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 ASN Upds % Upds/Pfx AS-Name 1 - AS45264 4799 0.2% 2399.5 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 2 - AS28057 18560 0.7% 1546.7 -- Contecol 3 - AS45286 1387 0.1% 1387.0 -- EDIINDONESIA-AS-ID PT EDI INDONESIA 4 - AS29421 1371 0.1% 1371.0 -- DCI-AS Digital Communications Incorporated Ltd. 5 - AS30944 1258 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 - AS11652 2517 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 - AS19406 4428 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 - AS28666 4398 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/24 11685 0.4% AS8452 -- TE-AS TE-AS 4 - 122.161.0.0/16 10614 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/24 6459 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, Inc. 16 - 59.177.64.0/18 3362 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - 59.177.144.0/20 3097 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 18 - 115.170.128.0/17 2206 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 19 - 215.65.61.0/24 1889 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 190.9.120.0/24 1720 0.1% AS11581 -- TRANSTEL S.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

The Cidr Report
by cidr-report＠potaroo.net 23 Jun '12

23 Jun '12

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 Prefixes CIDR Agg 15-06-12 416421 242407 16-06-12 416435 242366 17-06-12 416800 242573 18-06-12 417057 242604 19-06-12 416751 242539 20-06-12 416653 242280 21-06-12 417133 242084 22-06-12 417401 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 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 417722 241644 176078 42.2% All ASes AS6389 3401 193 3208 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3279 1651 1628 49.6% WINDSTREAM - Windstream Communications Inc AS22773 1652 137 1515 91.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2720 1294 1426 52.4% KIXS-AS-KR Korea Telecom AS18566 2091 706 1385 66.2% COVAD - Covad Communications Co. AS28573 1954 581 1373 70.3% NET Servicos de Comunicao S.A. AS2118 1255 14 1241 98.9% RELCOM-AS OOO "NPO Relcom" AS7545 1704 503 1201 70.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS4323 1571 386 1185 75.4% TWTC - tw telecom holdings, inc. AS10620 1967 794 1173 59.6% Telmex Colombia S.A. AS1785 1925 815 1110 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1594 540 1054 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1440 462 978 67.9% Telecom Argentina S.A. AS7552 1100 217 883 80.3% VIETEL-AS-AP Vietel Corporation AS26615 902 33 869 96.3% Tim Celular S.A. AS17974 1945 1088 857 44.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS8151 1490 672 818 54.9% Uninet S.A. de C.V. AS18101 947 160 787 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1107 346 761 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 892 162 730 81.8% CRNET CHINA RAILWAY Internet(CRNET) AS13977 839 123 716 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1113 467 646 58.0% LEVEL3 Level 3 Communications AS855 690 57 633 91.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 691 74 617 89.3% GIGAINFRA Softbank BB Corp. AS30036 1439 835 604 42.0% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4780 841 246 595 70.7% SEEDNET Digital United Inc. AS19262 998 405 593 59.4% VZGNI-TRANSIT - Verizon Online LLC AS22561 1016 424 592 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS9808 593 22 571 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS8452 1275 716 559 43.8% TE-AS TE-AS Total 44431 14123 30308 68.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 46.96.0.0/22 AS31733 46.96.4.0/22 AS31733 46.96.8.0/22 AS31733 46.96.12.0/22 AS31733 46.96.16.0/22 AS31733 46.96.20.0/22 AS31733 46.96.24.0/22 AS31733 46.96.28.0/22 AS31733 46.96.32.0/22 AS31733 46.96.36.0/22 AS31733 46.96.40.0/22 AS31733 46.96.44.0/22 AS31733 46.96.48.0/22 AS31733 46.96.52.0/22 AS31733 46.96.56.0/22 AS31733 46.96.60.0/22 AS31733 46.96.64.0/22 AS31733 46.96.68.0/22 AS31733 46.96.72.0/22 AS31733 46.96.76.0/22 AS31733 46.96.80.0/22 AS31733 46.96.84.0/22 AS31733 46.96.88.0/22 AS31733 46.96.92.0/22 AS31733 46.96.96.0/22 AS31733 46.96.100.0/22 AS31733 46.96.104.0/22 AS31733 46.96.108.0/22 AS31733 46.96.112.0/22 AS31733 46.96.116.0/22 AS31733 46.96.120.0/22 AS31733 46.96.124.0/22 AS31733 46.96.128.0/22 AS31733 46.96.132.0/22 AS31733 46.96.136.0/22 AS31733 46.96.140.0/22 AS31733 46.96.144.0/22 AS31733 46.96.148.0/22 AS31733 46.96.152.0/22 AS31733 46.96.156.0/22 AS31733 46.96.160.0/22 AS31733 46.96.164.0/22 AS31733 46.96.168.0/22 AS31733 46.96.172.0/22 AS31733 46.96.176.0/22 AS31733 46.96.180.0/22 AS31733 46.96.184.0/22 AS31733 46.96.188.0/22 AS31733 46.96.192.0/22 AS31733 46.96.196.0/22 AS31733 46.96.200.0/22 AS31733 46.96.204.0/22 AS31733 46.96.208.0/22 AS31733 46.96.212.0/22 AS31733 46.96.216.0/22 AS31733 46.96.220.0/22 AS31733 46.96.224.0/22 AS31733 46.96.228.0/22 AS31733 46.96.232.0/22 AS31733 46.96.236.0/22 AS31733 46.96.240.0/22 AS31733 46.96.244.0/22 AS31733 46.96.248.0/22 AS31733 46.96.252.0/22 AS31733 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 83.223.224.0/22 AS31733 83.223.228.0/22 AS31733 83.223.232.0/22 AS31733 83.223.236.0/22 AS31733 83.223.240.0/22 AS31733 83.223.244.0/22 AS31733 83.223.248.0/22 AS31733 83.223.252.0/22 AS31733 94.250.128.0/22 AS31733 94.250.132.0/22 AS31733 94.250.136.0/22 AS31733 94.250.140.0/22 AS31733 94.250.144.0/22 AS31733 94.250.148.0/22 AS31733 94.250.152.0/22 AS31733 94.250.156.0/22 AS31733 94.250.160.0/22 AS31733 94.250.164.0/22 AS31733 94.250.168.0/22 AS31733 94.250.172.0/22 AS31733 94.250.176.0/22 AS31733 94.250.180.0/22 AS31733 94.250.184.0/22 AS31733 94.250.188.0/22 AS31733 94.250.192.0/22 AS31733 94.250.196.0/22 AS31733 94.250.200.0/22 AS31733 94.250.204.0/22 AS31733 94.250.208.0/22 AS31733 94.250.212.0/22 AS31733 94.250.216.0/22 AS31733 94.250.220.0/22 AS31733 94.250.224.0/22 AS31733 94.250.228.0/22 AS31733 94.250.232.0/22 AS31733 94.250.236.0/22 AS31733 94.250.240.0/22 AS31733 94.250.244.0/22 AS31733 94.250.248.0/22 AS31733 94.250.252.0/22 AS31733 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnológico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

[MBONED] PIM survey for operators
by Stig Venaas 22 Jun '12

22 Jun '12

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.eubanks(a)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 MBONED(a)ietf.org https://www.ietf.org/mailman/listinfo/mboned

1 0

Weekly Routing Table Report
by Routing Analysis Role Account 22 Jun '12

22 Jun '12

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-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)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 Blocks 4608-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 announcing only one prefix: 5752 ARIN Region transit ASes present in the Internet Routing Table: 1601 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 1080985216 Equivalent to 64 /8s, 110 /16s and 134 /24s Percentage of available ARIN address space announced: 57.2 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, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 103551 Total RIPE prefixes after maximum aggregation: 54846 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 105587 Unique aggregates announced from the RIPE address blocks: 66781 RIPE Region origin ASes present in the Internet Routing Table: 16640 RIPE Prefixes per ASN: 6.35 RIPE Region origin ASes announcing only one prefix: 8070 RIPE Region transit ASes present in the Internet Routing Table: 2666 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1654 Number of RIPE addresses announced to Internet: 631874948 Equivalent to 37 /8s, 169 /16s and 165 /24s Percentage of available RIPE address space announced: 91.9 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 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 42327 Total LACNIC prefixes after maximum aggregation: 8320 LACNIC Deaggregation factor: 5.09 Prefixes being announced from the LACNIC address blocks: 44845 Unique aggregates announced from the LACNIC address blocks: 21926 LACNIC Region origin ASes present in the Internet Routing Table: 1600 LACNIC Prefixes per ASN: 28.03 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 308 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 600 Number of LACNIC addresses announced to Internet: 111077288 Equivalent to 6 /8s, 158 /16s and 231 /24s Percentage of available LACNIC address space announced: 66.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9352 Total AfriNIC prefixes after maximum aggregation: 2173 AfriNIC Deaggregation factor: 4.30 Prefixes being announced from the AfriNIC address blocks: 9803 Unique aggregates announced from the AfriNIC address blocks: 3304 AfriNIC Region origin ASes present in the Internet Routing Table: 548 AfriNIC Prefixes per ASN: 17.89 AfriNIC Region origin ASes announcing only one prefix: 167 AfriNIC Region transit ASes present in the Internet Routing Table: 125 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 40527872 Equivalent to 2 /8s, 106 /16s and 104 /24s Percentage of available AfriNIC address space announced: 40.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2704 11117 1196 Korea Telecom (KIX) 17974 1945 533 80 PT TELEKOMUNIKASI INDONESIA 7545 1689 301 87 TPG Internet Pty Ltd 4755 1594 385 154 TATA Communications formerly 9829 1300 1085 28 BSNL National Internet Backbo 9583 1173 89 511 Sify Limited 4808 1107 2054 313 CNCGROUP IP network: China169 7552 1100 1062 11 Vietel Corporation 24560 1034 385 165 Bharti Airtel Ltd., Telemedia 9498 966 291 63 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3401 3791 190 bellsouth.net, inc. 7029 3238 986 157 Windstream Communications Inc 18566 2091 382 181 Covad Communications 1785 1925 681 132 PaeTec Communications, Inc. 22773 1650 2911 121 Cox Communications, Inc. 20115 1645 1570 613 Charter Communications 4323 1571 1043 385 Time Warner Telecom 30036 1439 269 763 Mediacom Communications Corp 7018 1225 10013 823 AT&T WorldNet Services 11492 1189 216 356 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1690 544 16 Corbina telecom 2118 1255 97 14 EUnet/RELCOM Autonomous Syste 12479 757 721 93 Uni2 Autonomous System 34984 710 188 173 BILISIM TELEKOM 31148 686 37 9 FreeNet ISP 6830 685 2234 437 UPC Distribution Services 20940 664 215 520 Akamai Technologies European 8551 577 364 61 Bezeq International 3320 490 8442 403 Deutsche Telekom AG 13188 476 100 10 Educational Network Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1967 342 205 TVCABLE BOGOTA 28573 1942 1211 54 NET Servicos de Comunicao S.A 6503 1530 418 65 AVANTEL, S.A. 8151 1491 3068 336 UniNet S.A. de C.V. 7303 1440 901 195 Telecom Argentina Stet-France 26615 903 728 33 Tim Brasil S.A. 27947 705 73 93 Telconet S.A 11172 646 91 74 Servicios Alestra S.A de C.V 3816 586 247 89 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1275 958 13 TEDATA 24863 860 274 35 LINKdotNET AS number 6713 499 649 18 Itissalat Al-MAGHRIB 24835 321 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 209 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 16637 172 664 87 MTN Network Solutions 29975 167 571 19 Vodacom 29571 157 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3401 3791 190 bellsouth.net, inc. 7029 3238 986 157 Windstream Communications Inc 4766 2704 11117 1196 Korea Telecom (KIX) 18566 2091 382 181 Covad Communications 10620 1967 342 205 TVCABLE BOGOTA 17974 1945 533 80 PT TELEKOMUNIKASI INDONESIA 28573 1942 1211 54 NET Servicos de Comunicao S.A 1785 1925 681 132 PaeTec Communications, Inc. 8402 1690 544 16 Corbina telecom 7545 1689 301 87 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3238 3081 Windstream Communications Inc 18566 2091 1910 Covad Communications 28573 1942 1888 NET Servicos de Comunicao S.A 17974 1945 1865 PT TELEKOMUNIKASI INDONESIA 1785 1925 1793 PaeTec Communications, Inc. 10620 1967 1762 TVCABLE BOGOTA 8402 1690 1674 Corbina telecom 7545 1689 1602 TPG Internet Pty Ltd 22773 1650 1529 Cox Communications, Inc. 4766 2704 1508 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 32873 UNALLOCATED 12.46.102.0/24 10912 InterNAP Network Ser 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 46.96.0.0/22 31733 Link Telecom PJSC Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:13 /10:28 /11:83 /12:236 /13:462 /14:832 /15:1508 /16:12291 /17:6333 /18:10725 /19:20814 /20:29569 /21:31283 /22:40922 /23:38788 /24:217227 /25:1238 /26:1460 /27:866 /28:171 /29:66 /30:18 /31:0 /32:23 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2636 3238 Windstream Communications Inc 18566 2040 2091 Covad Communications 6389 1874 3401 bellsouth.net, inc. 8402 1389 1690 Corbina telecom 30036 1378 1439 Mediacom Communications Corp 11492 1152 1189 Cable One 22773 1082 1650 Cox Communications, Inc. 6503 1061 1530 AVANTEL, S.A. 8452 1040 1275 TEDATA 1785 1036 1925 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:563 2:712 3:1 4:13 5:62 6:3 8:429 12:2014 13:1 14:630 15:12 16:3 17:5 20:24 23:185 24:1784 27:1311 31:984 32:56 33:2 34:2 36:9 37:582 38:814 39:1 40:127 41:3147 42:139 44:3 46:1448 47:2 49:415 50:559 52:13 54:12 55:7 56:1 57:34 58:976 59:504 60:259 61:1227 62:997 63:2040 64:4251 65:2254 66:4460 67:2022 68:1155 69:3194 70:982 71:503 72:1829 74:2601 75:477 76:330 77:951 78:968 79:493 80:1216 81:943 82:653 83:526 84:498 85:1191 86:420 87:936 88:331 89:1721 90:298 91:4956 92:573 93:1402 94:1595 95:1230 96:371 97:316 98:893 99:38 100:17 101:251 103:1200 106:103 107:186 108:340 109:1411 110:785 111:925 112:419 113:623 114:642 115:822 116:949 117:730 118:899 119:1233 120:348 121:694 122:1673 123:1097 124:1400 125:1255 128:560 129:198 130:254 131:633 132:289 133:22 134:244 135:61 136:215 137:239 138:334 139:185 140:491 141:253 142:437 143:372 144:516 145:76 146:510 147:292 148:775 149:314 150:163 151:182 152:473 153:175 154:17 155:420 156:225 157:381 158:190 159:619 160:342 161:269 162:352 163:192 164:643 165:413 166:587 167:475 168:912 169:127 170:885 171:137 172:5 173:1779 174:615 175:436 176:545 177:842 178:1517 180:1264 181:97 182:1020 183:232 184:517 185:1 186:2375 187:1133 188:1349 189:1852 190:5635 192:6005 193:5539 194:4542 195:3430 196:1220 197:161 198:3666 199:4796 200:5897 201:1967 202:8667 203:8580 204:4337 205:2542 206:2805 207:2798 208:4042 209:3608 210:2786 211:1552 212:2032 213:1925 214:874 215:83 216:5102 217:1566 218:555 219:312 220:1241 221:574 222:315 223:354 End of report

1 0