- Test - lists.nanog.org

NTP/THunderbolt (was Re: strat-1 gps)
by Hal Murray 26 Jun '12

26 Jun '12

> Thing with the Thunderbolts is not all revisions of the firmware seem to > play nice with ntpd. Would anybody with more info please contact me off-list. We should be able to fix that, or at least document it. -- These are my opinions. I hate spam.

1 0

Collecting flows at an IXP
by Graham Beneke 26 Jun '12

26 Jun '12

Hi All I'm busy doing some digging to find a solution for collecting layer-2 flows data on a medium sized IXP. All we have at the moment is some MRTG graphs and we're trying to get a better view into IPv4 vs IPv6, src and dst MACs, packet sizes and also perhaps port & protocol trends. I found Richard A. Steenbergen's NANOG 39 presentation and not much since then. Is it still correct that Cisco does not support sFlow? Are you able to get the same kind of useful data using Netflow v9? Which FOSS flow collectors do an decent/adequate job at crunching about 10Gbps worth of flows and presenting it in a useful way? Thanks -- Graham Beneke

4 4

[NANOG-announce] Board Member Replacement Announcement - Dan Golding
by Sylvie LaPerriere 26 Jun '12

26 Jun '12

NANOG * How is the selection made? The Board will review the candidacies and appoint. Decision will be final and announced on June 22 to nanog-announce(a)nanog.org. There is more than the replacement position. Bear in mind that the election process will be initiated in early August when we will have 3 vacant boardpositions to fill. Check http://www.nanog.org/governance/elections/ late July and we will communicate the elections process via nanog-announce(a)nanog.org. We trust this answers your questions about the replacement and thank you for your consideration and interest for NANOG. * -- Sylvie LaPerriere NANOG Chair - www.nanog.org _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Cisco ASR router performance specs
by Andrey Khomyakov 26 Jun '12

26 Jun '12

Hi all, Could you point me into the right direction, please, on where one would find different performance ratings for Cisco routers other than talking to my SE (who is on PTO right now). My understanding is that Cisco does not publish this info. How do folks research that kind of stuff? For example, right now I want to find out how many DMVPN tunnels a given model of an ASR will support and what kind of throughput I can count on with that enabled. Thanks in advance for answers --Andrey

2 1

Net::Perl::SSH for MRLG
by Peter Ehiwe 26 Jun '12

26 Jun '12

Hello All , Has anyone successfully implemented Net::perl::ssh with mrlg . If yes please unicast me. The Perl module works fine but mrlg dosent seem to be able to connect to the routers using that module . .

3 2

Feedback on Entrasys Switching
by Darrell Hyde 26 Jun '12

26 Jun '12

Was hoping that anyone with experience with the Entrasys K or S series switches would be willing to offer any feedback on the platform, organization, support, software, etc. Interested in fairly vanilla L2 and L3 functionality and performance at high 1 and 10G interface density. Considering an evaluation and would value some informed argument for or against. Happy to take replies offline. Will be glad to summarize for anyone interested. Thanks! - Darrell

1 0

inquire
by Hadi Salem 25 Jun '12

25 Jun '12

Hi, I have inquire regard how to setup pop for terminating voice to telecom carries around the global. May scenario is, Telecom companies will connect to us thru VoIP. And we would like to terminate these voice calls to telecom carrier around the global... At best price. How can I accomplish this? I have read many article to host my equipment’s in co-location provider, where all carries well meet there. Like meet-me-room I’m confused here, is all carriers will be hosting there equipment’s in ixp? Or data center? What equipment’s do I need is Multiplexer and media gateway and Softswitch and patch panel? I need to make 30000 calls do I need 1000xE1 lines from the Multiplexer? What in my mind this picture Softswitch will connect media gateway. Media gateway will connect Multiplexer at DS3. Multiplexer will produce E1line to patch panel and from patch panel will connect cross connect to others telecom carrier Is this right?? Do I have to host my equipment’s at each ixp ? or data center where meet-me-room available Thanks and regards Mike

1 0

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